8.3 Communication Security

Author: Zhang Hongyuan · © 2016–2026 · All Rights Reserved · Copyright & License

8.3.1 Network Transport Encryption

Reading note: The mechanisms of MQTT, CoAP, and the other protocols themselves are developed in Chapter 9, and unified secure device access was already introduced in Chapter 4. This section takes the security perspective — it discusses transport-encryption engineering from the angles of threat model, certificate management, and key rotation, rather than the protocols themselves. The complete sequence of the TLS 1.3 handshake is shown in Figure 8-6 in this section; the Nginx configuration below is a TLS-termination-layer example for MQTT over TLS, and for the broker-side mutual-authentication configuration and end-to-end verification see experiment card EXP-8-COMSEC-01.

A pressure sensor deployed at a wellhead in an oil field reports field oil-pressure data to a cloud control platform over MQTT every few seconds. If this link is not encrypted, an attacker only needs to set up a spoofed receiving device within signal range to intercept the wireless traffic — oil pressure, valve states, even control commands, all in plain view. Swap the setting for a water-supply network or a chemical plant, and the consequence is no longer a privacy leak but a safety incident.

Network transport encryption solves exactly this problem: over an untrusted link, it ensures that data in transit from sender to receiver can be neither "seen" nor "altered." This subsection starts from the two protocols, TLS and DTLS — how they work, how to configure them in IoT scenarios, and the link most often forgotten: key management.

The TLS Handshake: Certificates, Key Exchange, and Session Establishment

Note: the figures in this chapter's example scenarios serve to illustrate engineering judgment; they are not general statistical conclusions.

TLS (Transport Layer Security) is the most widely used standard for protecting TCP communication today. Two versions are in broad use: TLS 1.2 (RFC 5246, finalized in 2008) and TLS 1.3 (RFC 8446, finalized in 2018). TLS 1.3 cuts the handshake from two round trips to one and removes the insecure cipher suites (such as RSA key exchange and CBC mode), and it is being adopted step by step by mainstream cloud platforms and newer MQTT brokers. In the embedded world, however, TLS 1.2 stack implementations are more mature and their libraries are smaller; many vendors still baseline on 1.2, with only some high-end devices supporting 1.3.

A complete TLS 1.2 handshake goes through four steps:

1. ClientHello: the client (device or application) sends the TLS versions it supports, a list of cipher suites, and a random value (the Client Random).
2. ServerHello + Certificate: the server selects a cipher suite and sends back its digital certificate plus another random value (the Server Random). The certificate carries the server's public key and the signature issued by a certificate authority.
3. Key exchange: the client verifies that the server certificate is valid (checking the signature, the validity period, and the domain match), then generates a pre-master secret, encrypts it with the server's public key, and sends it back. Both sides independently derive the same session key from the three random values.
4. Finished: both sides encrypt a "handshake complete" message with the session key, confirming that key negotiation succeeded. From then on, all application data is encrypted and transmitted with this session key.

TLS 1.3 merges steps 2 and 3 and uses ECDHE key exchange by default, providing forward secrecy — even if the server's private key leaks later, past session records cannot be decrypted.

The sequence diagram below shows the main flow of the TLS 1.3 handshake.

Figure 8-6 TLS 1.3 Handshake

DTLS: How Do You Encrypt a UDP Link?

Many IoT devices use UDP instead of TCP in order to skip the overhead of TCP's three-way handshake and reduce latency and power consumption. CoAP (Constrained Application Protocol) was designed for exactly this: its minimal message header is only 4 bytes and its typical request header is tiny, fitting low-power, low-bandwidth networks. But UDP guarantees neither ordering nor retransmission, so TLS cannot simply be carried over — TLS's sequence-number machinery depends on TCP.

DTLS (Datagram Transport Layer Security) resolves this contradiction. It is based on TLS but adds a layer of logic that tolerates datagram reordering and loss. DTLS 1.2 stays in version sync with TLS 1.2 (RFC 6347, finalized in 2012), and CoAP's secure layer, CoAPS, runs on top of DTLS. LwM2M (Lightweight Machine-to-Machine) defines a complete security scheme for CoAP; at its core is DTLS 1.2, providing integrity, authentication, and confidentiality services on par with TLS.

The DTLS handshake is roughly the same as TLS, with two additions:

• epoch counter: every successfully completed handshake or renegotiation increments the epoch value by one. The receiver uses (epoch, sequence_number) to uniquely identify a message, so it can reassemble correctly even when datagrams arrive out of order.
• Fragmentation and reassembly: a handshake message can exceed the UDP MTU (typically 1500 bytes); DTLS splits it into multiple datagrams sent separately, and the receiver buffers the pieces and reassembles the message once all fragments have arrived.

The price is a larger protocol stack — DTLS code is generally bigger than plain TLS, and because handshake messages themselves may be fragmented, they can be retried again and again on links with high packet loss. Some ultra-low-end MCUs (models with only tens of KB of memory) cannot run full DTLS and fall back to a scheme of PSK (Pre-Shared Key) plus a custom MAC — losing the flexibility of a certificate chain.

Choosing Cryptographic Algorithms

With cipher suites, more is not better. Each suite is a packaged combination of an encryption algorithm, a key-exchange algorithm, and a message authentication code. When an IoT platform makes its selection, security, performance, and power consumption all have to be weighed at once.

Table 8-6 Suitability comparison of typical cryptographic algorithms

Algorithm category	Typical algorithm	Suitability on embedded devices	Notes
Symmetric encryption	AES-CCM	High (most MCUs have built-in AES instructions)	One of DTLS's default suites; CCM mode provides both encryption and authentication. Defined in RFC 6655 (TLS) and RFC 3610 (CCM)
Symmetric encryption	ChaCha20 + Poly1305	High (efficient in software; outperforms AES when there is no hardware acceleration)	Suits endpoints without AES-NI; RFC 7905 defines its use in TLS
Key exchange	ECDHE	Medium (ECC point multiplication is feasible on low-end MCUs)	Provides forward secrecy; the default in TLS 1.3
Key exchange	RSA	Medium (big-number modular exponentiation is slow on low-end MCUs)	No forward secrecy; in TLS 1.3 used only for signature verification
Message authentication	SHA-256	High (most MCUs have hardware SHA-256)	Record-layer authentication in TLS 1.2; TLS 1.3 switches to AEAD
Message authentication	SHA-1	Not recommended (collision risk demonstrated)	Should not be used in new systems

In engineering practice, the recommended suites are TLS_ECDHE_ECDSA_WITH_AES_128_CCM (RFC 6655) or TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (the official registered name in RFC 7905; its OpenSSL short name is ECDHE-ECDSA-CHACHA20-POLY1305, as used in the Nginx configuration below). Keep the certificate chain no deeper than two levels — every extra certificate the device transmits during the handshake adds several hundred bytes of traffic, which on extremely low-bandwidth links such as LoRaWAN or NB-IoT can blow past the MTU or visibly extend the time to complete the handshake.

An Nginx Configuration Example

Below is a typical Nginx Layer-4 proxy configuration providing TLS termination for an MQTT broker. Because MQTT is a binary TCP protocol, Nginx must terminate TLS in the stream module and pass the traffic through at the transport layer — the HTTP module's proxy_pass cannot carry it. The paths and cipher suites in the example must be adjusted to the actual security baseline. ssl_verify_client on means mutual authentication is enforced at the termination layer: a client that does not present a trusted certificate is rejected at the TLS handshake stage. If the broker terminates TLS directly, the corresponding certificate enforcement and topic authorization configuration are shown in experiment card EXP-8-COMSEC-01 below.

# Illustrative configuration — adjust certificate paths and cipher suites to your environment
# The stream block must be at the top level of nginx.conf (outside the http block) to pass MQTT through at Layer 4
stream {
    server {
        listen 8883 ssl;                  # Default port for MQTT over TLS
        ssl_certificate         /path/to/iot-server.crt;
        ssl_certificate_key     /path/to/iot-server.key;
        ssl_protocols           TLSv1.2 TLSv1.3;
        ssl_ciphers             ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-CHACHA20-POLY1305;
        ssl_prefer_server_ciphers on;

        # Mutual TLS: force clients to present a certificate, verified by the termination layer against the CA root certificate
        ssl_client_certificate  /path/to/ca-cert.crt;
        ssl_verify_client       on;

        # In the stream module, proxy_pass takes the backend address directly, without the http:// scheme prefix
        proxy_pass          127.0.0.1:1883;   # Plaintext port of the internal MQTT broker
    }
}

Experiment EXP-8-COMSEC-01: Verifying MQTT Mutual Authentication and Topic Authorization

The Nginx example puts client-certificate checking at the termination layer; if the broker terminates TLS directly (both Mosquitto and EMQX support this), the same constraints must land in the broker configuration. The steps below use Mosquitto 2.x and a set of "positive and negative verifications" to confirm that two hard constraints really take effect: a client without a certificate cannot connect, and a client holding a certificate cannot exceed its authority. The corresponding approach on EMQX is to set verify to verify_peer and fail_if_no_peer_cert to true in the listener's TLS options, and to configure topic authorization in its built-in authorization database instead; the verification approach is exactly the same.

Step 1: generate the root CA, the server certificate, and the client certificate.

# Root CA: self-signed; in production the private key should be protected by an HSM or a signing service
openssl genrsa -out ca.key 2048
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
  -subj "/CN=IoT Lab Root CA" -out ca.crt

# Server certificate: the CN is the broker's domain name
openssl genrsa -out server.key 2048
openssl req -new -key server.key -subj "/CN=broker.iot.local" -out server.csr
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 825 -sha256 -out server.crt

# Device certificate: device-001 as an example; its CN becomes the username on the broker side
openssl genrsa -out device-001.key 2048
openssl req -new -key device-001.key -subj "/CN=device-001" -out device-001.csr
openssl x509 -req -in device-001.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 825 -sha256 -out device-001.crt

openssl verify -CAfile ca.crt server.crt device-001.crt

Expected result: the last command prints server.crt: OK and device-001.crt: OK — both certificates chain to the root CA.

Step 2: configure Mosquitto. In /etc/mosquitto/conf.d/mtls.conf:

listener 8883
cafile                    /etc/mosquitto/ca.crt
certfile                  /etc/mosquitto/server.crt
keyfile                   /etc/mosquitto/server.key
require_certificate        true
use_identity_as_username   true
allow_anonymous            false
acl_file                   /etc/mosquitto/acl

require_certificate true enforces mutual authentication; use_identity_as_username true maps the client certificate's CN to the authenticated username, which the ACL then confines to its read/write scope. The content of /etc/mosquitto/acl is as follows — device-001 may read and write only its own topic prefix:

user device-001
topic readwrite device/001/#

Restart the service (systemctl restart mosquitto). Expected result: the service is listening normally on port 8883, with no certificate-loading errors in the log.

Step 3: positive and negative verification.

# Positive: a client holding a certificate publishes to its own topic
mosquitto_pub -h broker.iot.local -p 8883 \
  --cafile ca.crt --cert device-001.crt --key device-001.key \
  -t device/001/temperature -m "23.5"

# Negative 1: no client certificate
mosquitto_pub -h broker.iot.local -p 8883 \
  --cafile ca.crt \
  -t device/001/temperature -m "23.5"

# Negative 2: a client holding a certificate publishes to an unauthorized topic
mosquitto_pub -h broker.iot.local -p 8883 \
  --cafile ca.crt --cert device-001.crt --key device-001.key \
  -t device/002/temperature -m "99.9"

Expected result: the positive command exits normally, and the subscriber (which also carries the certificate, running mosquitto_sub -t 'device/001/#' -v) receives the message; in negative case 1 the client is rejected at the TLS handshake stage with an error of the tlsv1 alert certificate required kind, and the broker log records the failed handshake; in negative case 2 the handshake completes but the publish is refused — the broker disconnects and logs Denied PUBLISH (reason not authorized), and the subscriber never receives the message.

Experiment Card EXP-8-COMSEC-01

• Subject: end-to-end verification of MQTT over TLS mutual authentication and topic-level authorization;
• Fixed items: Mosquitto 2.x, OpenSSL 3.x, server/device certificates issued by the same root CA, ACL file version;
• Criteria: the certificate-less client is rejected at the handshake stage (certificate required); the client holding a certificate can publish and subscribe to device/001/# normally; a publish to device/002/# is refused and the connection closed;
• Evidence retention: the complete output of the three commands, excerpts of the broker log, and the certificate fingerprints (openssl x509 -noout -fingerprint -in device-001.crt);
• Extensions: revoke or rotate the device-001 certificate and re-run the positive case, confirming that the old certificate becomes invalid after the rotation window; re-test the same set of criteria on EMQX with verify_peer + fail_if_no_peer_cert.

Certificate Revocation and Key Rotation: The Most Overlooked Step

Certificate revocation is the most easily forgotten step in IoT security. Once a device's private key leaks or the device is decommissioned, its certificate must promptly be removed from the trusted list. The traditional approach maintains a CRL (Certificate Revocation List), but CRL files are large, and IoT devices routinely run offline for months — the download simply never completes.

There are three engineering alternatives:

• OCSP Stapling: the server periodically fetches an OCSP (Online Certificate Status Protocol) response from the CA and carries the response to the client inside the TLS handshake, so the client needs no extra request. Well suited to a cloud platform authenticating devices.
• Short-lived certificates + automatic renewal: platform-issued certificates get shortened validity periods (for example 7–30 days), and the device periodically requests a new certificate from the certificate-management service. The window of impact from a leak is extremely short. It requires the device to come online regularly and run an automatic rotation script.
• Hardware key generation in secure chips: some secure chips support internal key generation, with data flowing out only and never in. Rotation swaps only the certificate file; the private key itself never leaves the chip. No private key is ever transmitted over OTA, which raises the security level. Resource-constrained devices can also degrade to PSK — a PSK is pre-provisioned by hand or through an out-of-band channel before the handshake, saving the computational cost of certificate authentication.

The engineering essentials of key rotation: old and new keys must transition smoothly. The device encrypts the new key package with the old key, and the platform decrypts with the old key before writing it in; alternatively, signatures from both key sets, old and new, are accepted within a defined time window, after which the old key expires. If a device misses the switchover because it lost connectivity, an "offline emergency key" must be pre-provisioned, allowing the device to fall back to that key for a one-time renewal when authentication fails.

Engineering Checklist

Deploying transport encryption in an IoT project admits no one-size-fits-all recipe, but the baseline is clear. The list below can be checked item by item during selection and before going live:

1. Minimum TLS version: forbid enabling TLS 1.0/1.1; TLS 1.3 is recommended, TLS 1.2 at minimum.
2. Cipher suites: remove weak suites, for example old suites using CBC mode; prefer AEAD modes (such as CCM, GCM, ChaCha20-Poly1305).
3. Mutual authentication: the server certificate must be verified; verifying the client (device-side) certificate is recommended — at minimum, bind identity with a token or PSK.
4. Firewall UDP ports: if CoAP/DTLS is used, confirm that the non-secure port (5683) and the secure port (5684) are open on every network segment between devices and the platform.
5. Session resumption: allow session tickets or session IDs to be resumed to cut down handshakes, but set a sensible expiry (6–12 hours recommended) and force a fresh handshake once it passes.
6. Certificate revocation: enable OCSP Stapling or deploy short-lived certificates; do not rely on passively pulling CRLs.
7. Logging and monitoring: record TLS handshake failures, certificate-expiry warnings, and key-rotation logs, and connect them to the platform's alarm channel.

In most IoT platform security incidents, the root cause is not a broken encryption algorithm but misconfiguration or sloppy key management. Encryption itself is a shield, but real defense comes from wielding it with care.

From physical security to transport encryption, the chain of trust now extends from the root into the communication link. But encryption only solves the "cannot be seen" problem — if an attacker captures a legitimate message and replays it verbatim a few minutes later, the encrypted channel will not reject it, because it is itself a legitimate ciphertext. The next section discusses message integrity verification and anti-replay protection, completing the last two legs of communication security.

8.3.2 Message Integrity Verification and Replay-Attack Protection

Encryption solves the problem of "others cannot see the link," but it does not solve "was the message tampered with in transit," nor "someone recorded the message and replays it later."

Take the oil-field scenario from the start of Section 8.3.1: even with a TLS encrypted channel established between the pressure sensor and the platform, if an attacker implants malicious code on the device and tampers with the payload before encryption, what the platform finally decrypts is data that looks legitimate but is false. The more common mode of operation: the attacker cannot decrypt the content, but can record an encrypted message in full — say, the encrypted ciphertext of a "close valve" command — and replay it to the platform verbatim hours later. The platform decrypts it, takes it for a legitimate close-valve request, and the valve closes. Encryption stopped eavesdropping, but it did not stop replay.

Integrity verification and replay protection must therefore stand as independent security mechanisms, used alongside encryption. They answer different questions: integrity verification answers "has the data been altered," while replay protection answers "is this a legitimate request from this very moment."

Message Authentication Codes (HMAC)

HMAC (Hash-based Message Authentication Code) is the most widely deployed message-integrity verification mechanism today. The sender uses a shared key together with the message to compute, through a hash function, a fixed-length authentication code (MAC), then sends the message and the MAC together; the receiver recomputes with the same shared key and checks whether the MAC matches. A mismatch means the message was altered in transit. Its core computation structure is defined in RFC 2104 and is widely used in MQTT, in CoAP's security extensions, and in API signature verification between devices and platforms.

HMAC rests on two security preconditions: the secrecy of the shared key and the collision resistance of the chosen hash function (such as SHA-256). Compared with digital signatures, HMAC's advantage is its tiny computational overhead — it needs no public-key infrastructure (PKI), which makes it well suited to MCU nodes clocked at only tens of MHz with memory measured in KB.

Engineering-wise, key distribution and rotation deserve attention. HMAC's "shared key" means every device must negotiate a unique key with the platform in advance. If all devices share the same key, one compromised device collapses the entire line of defense. On IoT DC3's multi-tenant platform, device keys are usually bound to the tenant ID and support scheduled automatic rotation, ensuring that a single device leak does not widen the blast radius.

Where Digital Signatures Fit

The digital signature is another integrity-verification scheme; the difference is that it uses an asymmetric key pair: the sender signs with the private key, and the receiver verifies with the corresponding public key. The public key can be distributed openly, with no secret shared in advance, so it naturally solves the key-distribution problem.

But the cost is equally clear: asymmetric signing is one to two orders of magnitude slower than HMAC, and the signature data is longer. With ECDSA (Elliptic Curve Digital Signature Algorithm), for example, the signature is typically several tens of bytes longer than an HMAC output. For high-frequency telemetry, signing every frame is unrealistic.

The engineering dividing line is clear: high-value, low-frequency, high-consequence control commands (such as remote firmware updates and emergency shutdowns) should use digital signatures — a signature provides credible non-repudiation. High-frequency telemetry uses HMAC to keep computational cost down. The two mechanisms are not mutually exclusive and can be mixed.

Anti-Replay: Timestamps, Sequence Numbers, and Nonces

Integrity verification guarantees a message was not altered in transit, but it cannot distinguish "a new message with identical content" from "an old message being replayed." Anti-replay requires every message to carry a "one-time identifier" by which the receiver judges whether it has already been processed.

The three common schemes each have their emphasis. The timestamp scheme is simple to implement and needs no state, but depends on clock synchronization — too wide a window invites replay, too narrow a one rejects legitimate messages. Monotonically increasing sequence numbers need no clock and can be precise down to the individual message, but they require persistent state; how to continue numbering after a device reboot and how to handle sequence-number jumps are the engineering difficulties. One-time random numbers (nonces) give the most thorough replay protection but require an extra round trip (challenge–response), adding latency.

In practice, the three schemes are often mixed. The MQTT 5.0 specification carries a "session expiry" in the CONNECT message which, combined with the maximum processed sequence number maintained at the broker, is one such hybrid of timestamp and sequence number. A clarification is in order: session expiry itself is only a mechanism for cleaning up session state and does not equal replay protection; replay protection still depends on message-level timestamp, sequence-number, or nonce checks. For CoAP (Constrained Application Protocol), the IETF standardized OSCORE (Object Security for Constrained RESTful Environments), which encrypts and wraps CoAP messages at the application layer and achieves message-level replay protection with an integrity-protected monotonically increasing sequence number; the mechanism is described below.

Do not rely solely on the session lifetime of the transport layer (TLS/DTLS) for replay protection. A TLS session can last minutes or even hours, and an attacker can perfectly well capture and replay messages within the session's validity. Real replay protection must be implemented at the application layer or the security layer (such as OSCORE). State-constrained devices must also handle the loss of sequence numbers across reboots — the usual practice is to persist the increasing sequence number periodically in non-volatile memory (NVM), or to adopt a "sequence number + timestamp" hybrid in which the timestamp serves as the initial alignment point after a reboot.

The OSCORE Mechanism for CoAP

OSCORE is an application-layer security protocol designed specifically for constrained devices and constrained networks, defined in RFC 8613. Its key difference from DTLS: DTLS establishes a bidirectional secure tunnel at the transport layer and requires a handshake, whereas OSCORE completes encryption and authentication directly inside the CoAP message, without depending on transport-layer state. For battery-powered devices that sleep frequently and sit on extremely unstable links, this fits better — the device can emit a self-contained secure message at any time. Anti-replay is a built-in capability: the sender writes a monotonically increasing sequence number into the Partial IV field of a CoAP option, integrity-protected together with the ciphertext under AEAD; the receiver maintains a replay window and drops outright any Partial IV that is repeated or too old. An attacker can neither tamper with this sequence number (any change fails the integrity check) nor replay an old message verbatim into the window. Why stress this "freshness"? Because encryption protects only the unreadability of content, not its timeliness: an encrypted message from three years ago still decrypts to the correct content, but it has long been void; if the receiver does not check the sequence number, the attacker can "capture offline and replay at a chosen moment."

Figure 8-7 OSCORE Security Processing for CoAP

---

In an IoT system, integrity verification and replay protection form the indispensable line of defense beyond encryption. HMAC answers "has the data been altered" at low overhead; digital signatures provide non-repudiation in critical control scenarios; and the combination of timestamps, sequence numbers, and nonces answers "is this data a legitimate request from this moment." Application-layer security protocols such as OSCORE wrap these mechanisms together, letting even a constrained device send a self-contained, verifiably secure message without a handshake. When selecting, evaluate the device's computing power, communication frequency, and network stability first, then decide which combination to adopt — rather than blindly chasing the "strongest" encryption scheme.

8.3.3 Network Segmentation and Micro-Segmentation

The previous two subsections focused on the link: data must be encrypted in transit and protected against tampering and replay. But holding the link alone is still not enough. Once an attacker breaks through a single device, or gains network-layer access, they can move freely and laterally inside the intranet, "hopping" from one machine to the next toward critical systems. In IoT environments this is especially lethal — sensors, cameras, and gateways mingle in the same flat network, and one commandeered device can become the stepping stone to the core database.

Lateral movement is the technique by which an attacker gradually penetrates from the initial breach point toward high-value targets. Imagine a smart office building: the attacker first enters the intranet through an unpatched IP camera, then scans the other devices on the same subnet, discovers a gateway connected to the building-control system, and from that gateway controls the air conditioning, the elevators, even the access control. If every device in the building sits on the same subnet, the attacker can map out the building's entire digital system almost without crossing any defense.

Network segmentation solves exactly this problem: divide devices into separate isolated zones, so that once one zone is breached the attacker cannot directly reach the others. The traditional approach splits the Layer-2 network with VLANs (Virtual Local Area Networks) or enforces access-control policy with firewalls at Layer 3. But in IoT scenarios this has two shortcomings. First, IoT devices are numerous in kind and differ in ownership (some belong to the property manager, some to tenants, some to the operator), and a VLAN's static configuration cannot keep up with the churn. Second, even with VLANs in place, devices inside the same VLAN can still reach each other by default — a VLAN only blocks cross-subnet access; it does nothing about lateral movement between devices in the same subnet.

Hence the concept of micro-segmentation was brought into IoT security architectures. Its granularity is finer than a VLAN's: the question is no longer "which subnet may access which subnet" but "which device may access which device, which service." Micro-segmentation typically relies on software-defined networking (SDN): a centralized controller pushes fine-grained traffic policy, and communication between two devices must be allowed rule by rule, otherwise it is blocked by default. Flow-table rules can be written on the five-tuple (source IP, destination IP, source port, destination port, protocol), and can additionally factor in device identity (device-certificate serial number, thing-model type).

The micro-segmentation architecture below shows one common layered isolation model.

Figure 8-8 IoT Micro-Segmentation Architecture

The hard part of landing micro-segmentation is policy orchestration. If operators had to configure rules by hand for every possible device pair, a mid-sized campus could rack up tens of thousands of rules and quickly descend into a tangle. Real projects usually bind policy orchestration to the thing model (as described in Chapter 3) — at registration a device declares its "type" (temperature sensor, camera, actuator), its "security level" (low, medium, high), and its "tenant," and the policy engine generates rules automatically from these declarations. For example, all "low-level sensors" may only send data to the designated port of the data-collection service and may not initiate connections to any other device.

The Zero Trust architecture goes further than network segmentation. The zero-trust architecture published by NIST defines the core principles: never trust the origin of any request, whether inside or outside the network; every access must pass identity authentication, authorization, and cryptographic verification, with least privilege continuously in force. SP 800-207 also splits "decision" from "enforcement": the Policy Decision Point (PDP) performs a trust evaluation for each access and grants or denies it, and the Policy Enforcement Point (PEP) enforces that decision on the data path; in the IoT variant of the model, device identity — certificates, keys, behavioral baselines — is among the most essential inputs to the trust evaluation. Practicing zero trust in IoT means that even a device once legitimately admitted to the network must prove itself again at the next communication — through certificate-validity checks, behavioral-baseline comparison, or automatic transfer into a degraded network after repeated anomalies, where it may send only basic telemetry and control commands are forbidden. That said, deploying zero trust wholesale onto resource-constrained devices is not realistic. The full device–policy-engine–controller three-way authentication loop is hard to run on low-power devices. A pragmatic compromise is to enforce zero-trust decisions only on "control commands" while keeping lightweight authentication for read-only data streams such as sensors.

In actual engineering, placing IoT traffic in a dedicated VPC (Virtual Private Cloud) or tenant-level network space is already standard practice for public-cloud IoT PaaS. In the field-side device networks, however, micro-segmentation is far less widespread than on the cloud side. The root cause is uneven support for SDN and micro-segmentation among field network equipment (industrial switches, wireless access points) — many older models speak only VLAN and know nothing of dynamic flow tables. One pragmatic recommendation: in new projects, prefer switching equipment that supports OpenFlow or a vendor-proprietary micro-segmentation API; for existing networks already in place, at minimum split the devices into several VLANs by security level and then enforce a strict whitelist policy between VLANs with firewalls. This falls short of per-device isolation, but it at least blocks large-scale lateral movement across VLANs.

Micro-segmentation has another important role — limiting lateral worm propagation. Mirai showed how default passwords and internet-accessible management planes can turn large fleets of devices into attack resources. Network segmentation, east-west access controls, and egress restrictions can reduce the set of systems an infected device can reach, but they cannot guarantee that a worm will be "stuck on a single device": shared credentials, management planes, jump hosts, and faulty rules may still create a path. These measures therefore need to be combined with unique credentials, patching, asset discovery, and anomalous-traffic monitoring.

← 8.2 Device Security and Authentication8.4 Data Security and Privacy Protection →