Constrained stacks reduce overhead with choices such as CoAP over UDP/DTLS and IPv6 over 6LoWPAN/802.15.4; MQTT usually uses TCP/TLS. The layers adapt to the message and energy budget.

* Protocol choices follow the endpoint budget. MQTT normally uses TCP; 6LoWPAN adapts IPv6 to a constrained link. *

There are really three stacks in play, and the useful insight is that they form a gradient rather than a binary:

Reading it left to right, the backhaul — the stretch from gateway to cloud — can keep ordinary IP and Ethernet/WiFi while choosing application and transport protocols to fit the workload. The constrained endpoint may additionally use 802.15.4 with 6LoWPAN header compression and fragmentation. 6LoWPAN adapts IPv6; it does not replace it. The byte counts are illustrative payload scales, not protocol limits.

The bottom row explains all the rest. When a message is a few dozen bytes, an HTTP header alone would dwarf the payload, and a TCP handshake would cost more than the data. So:

• CoAP is essentially "REST in a handful of bytes" — the same request/response and resource ideas as HTTP, in a compact binary encoding over UDP; MQTT takes the other route, a publish/subscribe broker model with a tiny fixed header.
• DTLS is TLS adapted to run over an unreliable, connectionless transport.
• 6LoWPAN ("IPv6 over Low-power Wireless Personal Area Networks") is an adaptation layer that compresses IPv6 headers and fragments packets so IPv6 fits inside 802.15.4's very small frames.
• IEEE 802.15.4 is the low-rate, low-power radio standard underneath — the link layer that ZigBee and Thread are built on.

Tip: remember the stack by its budget, not its names. Thousands of bytes → hundreds → tens, and at each step something gets thrown overboard.

Go deeper:

• Wikipedia — Constrained Application Protocol — CoAP in detail: how it maps onto HTTP for web integration, and its default binding to UDP with optional DTLS.
• Wikipedia — MQTT — the other application-layer route: publish/subscribe through a broker, with control messages as small as two bytes.
• Wikipedia — 6LoWPAN — the adaptation layer in mechanism: compressing a 40-byte IPv6 header down to 2, and fragmenting to fit 127-octet frames.

Because IoT runs on trust in data that comes from devices nobody is watching — and without that trust the deployments simply do not get built.

The argument runs in four steps:

1. Security is one of the biggest obstacles to making IoT real. Not a finishing touch — a precondition for adoption.
2. Billions of edge devices are sold and deployed across many areas, at a rate that outpaces secure-engineering practice.
3. Those devices may not include sufficient security features — cost pressure on a cheap sensor is relentless, and security is the easiest line item to leave out.
4. Providing genuine data from edge devices is critical. This is the crux: if a reading might be forged, then every decision built on it is worthless. An analytics pipeline is only as trustworthy as its least trustworthy sensor.

The breach statistics quoted alongside are general rather than IoT-specific, but they set the scene: 83% of breaches involved external actors (mostly financially motivated) and 74% involved a human element such as social engineering or error, with a global average breach cost of $4.5 million in 2023 — a 15% rise over three years. Older figures from 2017 add that 90% of exploits targeted software defects, 81% of breaches involved stolen or weak passwords, and new malware counts grew from 21 to 31 million in a single quarter.

A typical attack cycle is drawn in four stages: identity breach → plant malware → gather data → steal or lock data, which maps directly onto the four defences worth building: identity protection, data protection, threat detection, and recovery from breaches.

Tip: the "genuine data" point is the one to carry forward. Confidentiality gets the attention, but for most IoT systems integrity and authenticity of the readings is the property that the whole business case rests on.

Go deeper:

• Wikipedia — Internet of things — its security and privacy sections gather the structural reasons cheap connected devices keep shipping insecure.