Summary

  • On 3 September 2026, the IESG approved TLS/DTLS 1.3 Profiles for the Internet of Things as a Proposed Standard. The profile recognizes that long-lived, hard-to-reach devices need changeable trust anchors; approval does not prove that any device fleet can perform the change.
  • A trustworthy transition needs a per-device ledger linking authorized distribution, durable installation, active anchor generation, usable certificate chain, observed handshake, rollback state, old-authority retirement and application receipt. A successful TLS connection proves only the path used at that moment.

The IESG announcement approved draft-ietf-uta-tls13-iot-profile-25 as a Proposed Standard. It is a companion to RFC 7925, which profiled TLS and DTLS 1.2 for constrained devices, and it updates that document's X.509 certificate and ciphersuite requirements. The Datatracker record shows version 25 and “Approved-announcement sent.” The reviewed record did not yet assign a final RFC number.

The profile's value is broader than a list of algorithms. Its approved text joins the handshake to the realities of small memories, intermittent links, credentials installed away from the network and devices expected to remain in service for years. It also says plainly that a static trust anchor across a device's whole lifetime makes algorithm transitions, CA rollover, manufacturer changes and incident response much harder.

That sentence identifies an operating system of authority. A trust anchor is not merely another certificate sent by a server. It is a local decision about where chain validation may begin. A device that receives a root inside a TLS Certificate message cannot assume that the received root is trustworthy; the profile's preferred baseline is to provision anchors outside the handshake and omit them from the transmitted chain.

Profile conformance can therefore be true while a fleet transition fails. The standard defines interoperable behaviour. It does not know which unit was asleep, which update root it accepts, whether flash write completed, whether the new anchor became active, which service chain it selected, or whether the old authority can still authenticate a peer.

Three credential modes create three different custody problems

The profile considers X.509 certificates, raw public keys and external pre-shared keys. It does not mandate one choice for all IoT systems.

An X.509 path separates a trust anchor, possible subordinate CAs and an end-entity certificate. A raw public key removes certificate structure from the TLS exchange, but it does not bind itself to the intended peer. A deployment still needs a protected association between that key and the device or service identity. A self-signed X.509 certificate remains X.509; calling it “raw” does not change the validation model.

External PSKs move authority again. RFC 9257 explains their entropy, identity and deployment risks. RFC 9258 binds imported PSKs to the relevant TLS 1.3 KDF and hash context. Neither provision proves who generated the secret, who copied it, whether devices share it, when it rotates or which service may use it.

The ledger must therefore name the credential mode before it records “TLS enabled.” The receipts for a CA path, a pinned RPK and an external PSK are not interchangeable.

Distribution is not durable installation

The profile points to secure firmware update as a way to distribute new trust anchors. RFC 9019 defines an architecture with distinct firmware authors, distributors, devices and trust relationships. Yet distribution ends before several decisive facts: package verification, durable write, activation, reboot, trust-store readback and a connection that actually uses the new anchor.

The profile also draws a scope boundary. Firmware-based anchor distribution does not by itself cover end-entity certificates or subordinate-CA certificates. Those objects may follow different enrollment, issuance and renewal systems. RFC 7030 provides EST mechanisms for obtaining CA certificates; support and successful use remain local facts.

A fleet percentage such as “98 per cent updated” is not enough. The missing two per cent may be disposable sensors, or they may control the only remote valves in a plant. Evidence needs device identity, hardware and firmware generation, accepted anchor fingerprints and roles, update result, activation time, last contact and exception owner.

A cross-certificate is a bridge, not the destination

During a CA transition, devices may carry different old and new anchors. The server can use the certificate_authorities extension to learn which CAs a peer says it supports and choose a compatible chain. That helps interoperability; it does not prove why the device trusts the anchor or whether the trust state is current.

The profile cites the newWithOld and oldWithNew transitional certificates described by RFC 9810. They can bridge validation between generations. They do not replace out-of-band provisioning of the new anchor.

This distinction matters because a bridge can quietly become permanent. If services keep presenting old-compatible paths, dormant devices continue to work and the migration dashboard looks healthy. The old authority also remains useful. If it was meant to be retired after a compromise or supplier exit, indefinite compatibility preserves precisely the power leadership intended to remove.

The opposite mistake is irreversible in another direction. Retire the old path before an isolated device installs the new anchor and the device may lose the only authenticated channel through which it could recover. The transition plan needs a last safe point, not merely a date.

Handshake efficiency can move dependency rather than remove it

Constrained devices pay for every byte and buffer. The profile requires Record Size Limit where the default record-size requirement—roughly 18 KB including processing buffers—is unacceptable. RFC 8449 lets a peer state the largest record it accepts. That statement is not a measurement of total RAM, flash, energy or certificate-processing time.

Session resumption can avoid repeating certificate authentication. Ticket count, lifetime and reuse policy trade bandwidth and latency against server state, privacy and replay control. RFC 9846 defines the TLS 1.3 mechanics. The IoT profile does not enable 0-RTT for CoAP, MQTT or another application lacking its own safe-use profile.

Certificate compression, cached certificate information and certificate URLs can reduce bytes on the primary handshake. They may add a cache, retrieval service, stable identifier or availability dependency. A smaller handshake is not automatically a smaller authority surface.

The decision record should therefore say which cost moved where: bytes, state, privacy, fetch availability, update code or chain ambiguity. Optimization without dependency accounting can make a constrained device cheaper to connect and harder to recover.

The trust-generation ledger

For each device, record the hardware generation, firmware and secure-boot generation, update root, credential mode, accepted trust-anchor fingerprints, anchor role and validation policy. Record every transition step: authorized package, delivery, verification, durable write, activation, restart and readback.

Then record what the service presented and what the device accepted. Name the end-entity certificate, subordinate path, anchor generation, negotiated protocol and observed time. Attach an application receipt separately. A TLS handshake authenticates a protocol peer under one path; it does not prove that a command was authorized, committed or physically executed.

Use Lu Heng's reality-layer discipline to keep the claims apart. Proposed Standard is symbolic status. A trust store is configured state. Package installation and chain validation are executed events. Device control and service continuity are outcomes. None should borrow another layer's authority.

Running-Code Primacy places the device's observed trust state above a product sheet. Minimum Initial Specification explains why the profile need not prescribe one CA or update topology. Interoperability can be common while lifecycle responsibility stays local.

Sources