Register for part 2 of our Device Identity Webinar Series!

Prepare your device identity infrastructure for post-quantum cryptography

NIST deprecates RSA and elliptic-curve algorithms after 2030 and disallows them after 2035. What makes that migration hard is operational: manual renewal, incomplete inventory, unverified hardware, relying parties with unknown requirements. Smallstep automates device certificate lifecycles, anchors identity in hardware where supported, and builds the inventory a plan starts from. Hybrid post-quantum key exchange is shipped on supported connections to its services; post-quantum device authentication still depends on platform and relying-party readiness.

Get a demo
background gradientbackground texture
Hybrid ML-KEM key exchange, shipped
Short-lived certificates shrink the migration window
Device inventory that feeds your cryptographic inventory
Hardware-backed identity, attested where supported
Deprecated after 2030, disallowed after 2035
Capability status stated plainly

Harvest now, decrypt later is a key exchange problem, and that part is shipped

Recorded TLS sessions can be decrypted later if the key exchange falls to a quantum computer. step-ca, the step CLI, and the commercial platform support the X25519MLKEM768 hybrid key exchange in TLS 1.3, safe while either share holds. It protects connections to Smallstep services when the client negotiates it. EAP-TLS, VPN, and ZTNA sessions are covered only when those products negotiate their own.

Signatures are the long pole: the chain, the relying parties, and the hardware

End-to-end post-quantum authentication needs every signature up to the trust anchor to be post-quantum and every RADIUS server, VPN, and identity provider able to verify it; partial migration moves one relying party at a time. Go 1.27 added ML-DSA to X.509 and TLS in August 2026; Smallstep has not yet shipped ML-DSA or hybrid certificates. Hardware lags further: TPM 2.0 v1.85 specifies ML-DSA attestation keys, but deployed TPMs are classical.

Short-lived certificates shrink the migration window

Smallstep device certificates are short-lived and renew automatically through the agent or your MDM, with key type set by authority policy, so a fleet turns over in weeks. Where client, hardware, and relying party all support a post-quantum algorithm, automated issuance carries the change with little manual work. Other devices need upgrades, re-enrollment, or replacement; a new algorithm needs a new key, and a classical TPM cannot be changed by policy. Dual authorities let you move in phases.

Know what you have before you plan the move

A migration plan starts with knowing which devices hold which keys in which hardware. Smallstep's inventory and certificate records, device, enrollment method, attestation, certificates issued, contribute to the cryptographic inventory NIST and OMB expect. Readiness also needs what the inventory does not hold: whether a TPM or Secure Enclave implements ML-DSA, whether its firmware can be upgraded, whether the OS exposes it. Ask us which fields and exports exist today.

Plan the network path before the certificates grow

Post-quantum certificate chains are several times larger, and EAP-TLS carries them in fragments through the access point and RADIUS. RFC 9191 already flags round-trip limits with large certificates; an IETF draft proposes fetching intermediates through EST to keep them out of the handshake. Hybrid key exchange on Wi-Fi depends on the supplicant and RADIUS negotiating it. Test access points, supplicants, and RADIUS with larger chains before anything reaches production.

Key benefits for NIST-aligned access design

Hybrid key exchange today

X25519MLKEM768 in step-ca, the step CLI, and the commercial platform, protecting enrollment and management traffic from harvest-now, decrypt-later collection.

Automated certificate lifecycle

Short-lived certificates renewed by the agent or your MDM, with key type set by authority policy, so a fleet turns over in weeks and a phased migration is possible.

Hardware-backed device identity

Keys generated in TPM 2.0 or Secure Enclave on supported platforms, with attestation at enrollment, so the hardware side of the migration starts from verified ground.

Inventory that feeds the plan

Device, enrollment method, attestation, and issued certificates on record, contributing to the cryptographic inventory your migration plan and your auditors expect.

Phased migration by authority

Separate authorities and policies per device class and relying party, so one path moves when it is ready and the rest stay classical until theirs is.

Capability status, stated

What is shipped, what is not, and what depends on your hardware and relying parties, listed in the FAQ so your migration plan can rely on it.

Start with a post-quantum readiness conversation about your device identity.

Bring your certificate inventory, renewal process, hardware mix, and RADIUS, VPN, and identity provider dependencies. We will go through them against the 2030 and 2035 dates and show which parts Smallstep can fix now.

Book a readiness conversation

FAQs Smallstep for post-quantum readiness

NIST finalized IR 8547, Transition to Post-Quantum Cryptography Standards, on October 27, 2026: quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, ECDH, finite-field DH) are deprecated after 2030 and disallowed after 2035, regardless of key size, and TLS 1.3 is required by January 2, 2030. For US federal systems, Executive Order 14412 (June 2026) sets post-quantum key establishment on high value assets by the end of 2030 and digital signatures by the end of 2031, and OMB M-26-15 ties agency plans to IR 8547. Outside federal scope these are references, not mandates, but auditors and customers use them as the baseline. Check the NIST CSRC for the current text.

Hybrid TLS 1.3 key exchange with X25519MLKEM768 (ML-KEM-768 from FIPS 203 combined with X25519), in step-ca and the step CLI and in the commercial platform, so connections to the CA and platform are protected against harvest-now, decrypt-later collection when the client offers it. Smallstep has not shipped ML-DSA or hybrid X.509 certificates, a post-quantum CA, or post-quantum attestation. See the Preparing for Q-Day post for the background.

Smallstep's CA and agent are written in Go, and until August 2026 the Go standard library had no ML-DSA support for X.509 or TLS; Smallstep sponsors a maintainer of that library. Go 1.27 added ML-DSA-44, -65, and -87 to crypto/x509 and crypto/tls, so the library constraint is gone. Issuing post-quantum device certificates still depends on relying parties that can verify them and on hardware that can hold the keys. Ask us for the current roadmap rather than relying on a date on this page.

A composite certificate combines a classical and a post-quantum signature in one construction, as RFC 10073 specifies for composite ML-DSA. It is not automatically backward compatible: a relying party that has not been updated does not recognize the composite algorithm identifier, so transitional compatibility usually means parallel certificate paths, separate credentials, or protocol-specific mechanisms rather than one certificate that works everywhere. IR 8547 allows hybrid key establishment, with FIPS validation preserved when one component is approved, and is more cautious about hybrid signatures. Smallstep intends to support a hybrid step; which form ships first is a roadmap question.

Mostly not yet, and the answer has layers. The specification: TCG's TPM 2.0 Library v1.85 and PTP 1.07 (2026) add ML-KEM endorsement keys and ML-DSA attestation keys. The vendor implementation: a TPM is PQC-ready only if its maker has implemented that revision, and TCG's PQC-ready and PQC-upgradable labels are vendor claims, not yet certification. The firmware: an upgradable TPM needs a secure field update that may or may not be offered for your models. The operating system: Windows, Linux, or macOS must expose the capability to applications. TPMs in deployed laptops are classical unless the vendor states otherwise, and Apple has not documented post-quantum signing in the Secure Enclave. Verify each layer with your hardware vendor rather than reading it off a model name.

The attestation model does: a key generated in the secure element, proven to the inventory, then a certificate issued to it. What changes is the algorithms in each step. Today the attestation keys and the issued certificates are classical; post-quantum attestation needs a TPM with ML-DSA attestation keys and a CA that can verify them, and on Apple platforms depends on Apple's attestation service. The connection the attestation travels over can use the hybrid key exchange now.

Being able to change algorithms without rebuilding your device identity infrastructure. Short-lived certificates give frequent opportunities to replace credentials. Centralized authority policy and automated enrollment reduce manual work where the devices, enrollment clients, cryptographic providers, and relying parties support the new algorithm; other devices need software upgrades, re-enrollment, or replacement. Migration also means generating a new key of the supported type: the Smallstep agent reuses hardware-bound keys across certificate orders on Windows and Linux, and renewing a certificate on an existing key cannot change its algorithm. A phased migration lets classical and post-quantum authorities coexist while dependencies are upgraded. Long-lived certificates and manual enrollment turn the same migration into a device-by-device project.

Post-quantum certificate chains are several times larger than ECDSA chains, and EAP-TLS carries the handshake in fragments through the access point to RADIUS. RFC 9191 already documents handshake failures from large certificates and round-trip limits, and the IETF EMU working group's post-quantum EAP-TLS draft (draft-ietf-emu-pqc-eap-tls, revision 04, October 2026) proposes fetching intermediate chains out of band through EST so they are omitted from the handshake; it is a working draft, not finished interoperability. Hybrid key exchange on EAP-TLS depends on your supplicants and RADIUS server negotiating it, which is separate from Smallstep's services doing so. Before any post-quantum signature reaches the network, test your access points, controllers, supplicants, and RADIUS with the larger chains, and confirm with Smallstep what its RADIUS services negotiate.

Each relying party moves on its own schedule. Hybrid key exchange is already in browsers and in many TLS stacks, so a ZTNA relay or identity provider may support it today. Verifying a post-quantum client certificate is a separate capability that your VPN concentrator, relay, and identity provider each have to add; until they do, the device certificate stays classical for that path. The inventory and per-authority policy let you move one relying party at a time.

Microsoft added ML-DSA-44, -65, and -87 to AD CS on Windows Server 2025 in the May 2026 update, so AD CS can issue post-quantum certificates. Two documented constraints matter: an ML-DSA CA has to be a newly installed hierarchy, existing CAs cannot be migrated in place, and ML-DSA enrollment through NDES, the SCEP path Intune and most MDMs use, is not supported. Early reports also show HTTPS bindings, RDP, and SSTP not yet accepting the certificates. The migration problem for most AD CS estates is long-lived certificates, enrollment on shared SCEP challenges, and no inventory of what holds which key. Smallstep can issue short-lived device certificates under your existing classical root today, which gives you the renewal cadence and inventory the transition needs; a post-quantum chain would need a post-quantum root and intermediate, which is a separate step for both products.

Prioritize hybrid post-quantum key establishment now on supported connections that carry long-lived sensitive data; it is standardized and shipped, and it addresses the risk that recorded classical key exchanges become readable later. Build the inventory now; IR 8547 and OMB expect one and it decides the plan. Make certificates short-lived and automate their lifecycle now, which shortens how long any credential stays deployed and creates the openings for a phased algorithm migration, provided the enrollment clients, hardware, and relying parties support the change. Then adopt post-quantum signatures when the chain, the relying parties, and the hardware in your fleet can all verify or hold them. Signatures are not exposed to harvest-now, decrypt-later, so the threat timing differs, but they protect authentication, code signing, and software updates, and the chain, hardware, and relying parties have to move together, so inventory, testing, and planning for them start now; only deployment waits for support.

Separately from readiness. The Go Cryptographic Module v1.0.0 holds FIPS 140-3 certificate 5247; v1.26.0, which implements ML-DSA, is on the Modules in Process list, which is not a validation. Whether a given Smallstep build runs the validated module in its approved operating conditions is a statement Smallstep has to make for that build and deployment, so confirm it before writing anything into an SSP. TPMs and Secure Enclaves are validated separately by their vendors.

Shipped: hybrid ML-KEM TLS 1.3 key exchange (X25519MLKEM768) on supported connections to Smallstep services, when the client negotiates it. Shipped: automated classical device certificate lifecycle through the agent and supported MDMs, scope by platform. Shipped: hardware-backed device identity with attestation on supported platforms. Not shipped: ML-DSA or hybrid certificate issuance, a post-quantum CA, or post-quantum attestation. Not established: automated classical-to-post-quantum credential migration, which depends on client, hardware, and relying-party support. Not verified publicly: a complete per-device post-quantum hardware readiness inventory. Requires interoperability validation: post-quantum EAP-TLS, VPN, and ZTNA end to end. Depends on platform vendors: post-quantum device attestation. Ask for the current roadmap before planning around any of these.

Device inventory and certificate lifecycle records: which device, how it enrolled, whether it attested, which certificates it holds and their lifetimes, and the authority policies that set the key types. Confirm with Smallstep the exact fields and export formats available in your deployment before promising them to an auditor. Those records support the cryptographic inventory and migration plan IR 8547 asks for; they do not demonstrate post-quantum authentication, which depends on the relying parties.