Much of identity security rests on public-key cryptography that a large enough quantum computer could break. TLS and mTLS certificates, code signing, SAML assertions, JWT access tokens, SSH keys, smart cards, passkeys and device identities all depend on RSA or elliptic curve algorithms. NIST published its first post-quantum cryptography (PQC) standards in August 2024 and, in a draft transition plan, proposes removing quantum-vulnerable algorithms from its standards by 2035. This guide is for identity, PKI and platform teams: it explains what is at risk in certificates, signing keys, tokens and authentication, where the identity protocols stand, and how to inventory, prioritise and make identity systems crypto-agile. For the wider, organisation-wide programme, see the Post-Quantum Cryptography Migration Guide.
Key takeaways
- Encryption and signatures run on different clocks. Encrypted traffic can be recorded now and decrypted later; according to NIST's draft IR 8547, authentication stays secure as long as the algorithms are unbroken at the moment it happens.
- The core standards exist. FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures, with X.509 identifiers for ML-DSA published as RFC 9881 in October 2025.
- Identity protocols lag the algorithms. NIST IR 8587 notes that OIDC, OAuth, JOSE, COSE, SAML and X.509 are still being updated, and that some SAML deployments may never be.
- Larger keys and signatures break assumptions. ML-DSA signatures are thousands of bytes, which strains signed JWTs in cookies and headers, constrained devices and HSMs.
- Trust anchors and inventory come first. Long-lived roots, firmware signing keys and token signing keys need the longest lead time; the UK NCSC expects discovery to be complete by 2028.
What is at risk in identity
NIST IR 8547 states that ECDSA, RSA and EdDSA signatures are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer, and lists the Diffie-Hellman and RSA key establishment schemes behind TLS for deprecation too. Symmetric algorithms and hash functions are much less exposed: NIST does not expect to need to transition away from its symmetric standards.
| Identity use | Algorithms today | Quantum risk | Clock |
|---|---|---|---|
| TLS and mTLS key exchange | ECDHE, RSA | Recorded sessions decrypted later, exposing tokens, passwords and secrets carried inside them | Now (harvest now, decrypt later) |
| Certificates and PKI | RSA, ECDSA signatures | Forged certificates and revocation data once signatures can be broken | Before forgery is possible; roots take years to replace |
| Token and assertion signing | RS256, ES256 (JWT); RSA (SAML) | Forged ID tokens, access tokens and SAML assertions | Before forgery is possible |
| Code and firmware signing | RSA, ECDSA | Forged updates; devices that cannot change their verification code stay exposed | Decided at manufacture |
| SSH | Ed25519, ECDSA, RSA, curve25519 key exchange | Forged host or user authentication; recorded sessions decrypted | Both |
| Passkeys, smart cards, TPMs and device identity | ECDSA, RSA | Authenticator keys forged in future; hardware may need replacing | Hardware refresh cycle |
Why the two clocks matter
For confidentiality, NIST IR 8547 warns that data captured today is at risk if it still matters when a quantum computer arrives, so key exchange moves first. For authentication, the draft says systems "may continue to use quantum-vulnerable algorithms" until such computers exist. The catch is lead time: quantum-resistant authentication needs upgrades to both sides of the exchange and to infrastructure such as PKI, and may need new hardware tokens. A root certificate issued today may still be in service when the risk becomes real.
Incidents show what a forged signature means. In the Microsoft Storm-0558 Key Breach 2023 a stolen signing key let attackers forge tokens and read mail at 22 organisations, and in the SolarWinds Supply Chain Compromise attackers stole a SAML token-signing certificate to forge tokens. A quantum attacker who can derive private keys from public ones would gain that power without stealing anything.
The standards and timelines
The algorithms are settled for most uses. NIST's August 2024 announcement describes FIPS 203 as the primary standard for general encryption, FIPS 204 as the primary standard for digital signatures, and FIPS 205 as a backup signature method based on different mathematics in case ML-DSA proves vulnerable. Falcon (to be called FN-DSA) and HQC, a backup for ML-KEM whose final standard NIST expects in 2027, are in standardisation. NIST's Dustin Moody said at the 2024 release: "There is no need to wait for future standards."
| Source | Status | What it says for identity teams |
|---|---|---|
| FIPS 203, 204, 205 | Final, August 2024 | ML-KEM for key establishment; ML-DSA and SLH-DSA for certificates, tokens and code signing |
| NIST IR 8547 | Initial public draft, November 2024 | 112-bit RSA and ECDSA deprecated after 2030; RSA, ECDSA and EdDSA disallowed after 2035 |
| NIST SP 800-208 | Published 2020 (as cited in IR 8547) | Stateful hash-based signatures (LMS, XMSS) for niche uses such as firmware; "not intended for general use" |
| UK NCSC migration timelines | Guidance, March 2025 | Discovery and initial plan by 2028; highest-priority migrations by 2031; full migration by 2035 |
| NIST IR 8587 | Final, September 2026 | Inventory public-key use in token and assertion ecosystems; plan for larger tokens |
| IETF RFC 9881 | Proposed Standard, October 2025 | How to use ML-DSA in X.509 certificates and CRLs |
IR 8547 is still a draft, so its dates may change; treat them as planning dates. It notes that moving from algorithm standardisation to full integration has historically taken 10 to 20 years. The NCSC dates are aimed at large organisations, critical infrastructure and companies with bespoke IT; it expects small firms on commodity IT to migrate largely through vendor updates. Check the current versions before you set internal deadlines.
Where identity protocols stand
The algorithms are standardised, but identity runs on protocols, and those move at different speeds. The NCSC says new PQC standards are still needed for TPMs, X.509 certificates and UEFI Secure Boot, and that it is reasonable to expect some by 2028.
| Protocol or component | Position (as of October 2026) | Source |
|---|---|---|
| TLS key exchange in browsers | Several popular browsers agree keys with a hybrid of traditional key exchange and ML-KEM; the exact mechanism was not yet standardised industry-wide when the NCSC wrote its guidance | UK NCSC |
| SSH key exchange | OpenSSH 9.9 (September 2024) added hybrid mlkem768x25519-sha256; OpenSSH 10.0 (April 2025) made it the default | OpenSSH release notes |
| SSH authentication | OpenSSH 10.6 (October 2026) enables a hybrid ssh-mldsa44-ed25519 signature algorithm; keys from earlier experimental support must be regenerated | OpenSSH release notes |
| X.509 certificates | RFC 9881 defines ML-DSA algorithm identifiers for certificates and CRLs | IETF |
| WebPKI | No agreement yet on adding post-quantum signatures while keeping compatibility with CAs, Certificate Transparency logs and CRLs | UK NCSC |
| OIDC, OAuth, JOSE, COSE, SAML | Standards and discovery metadata still being updated; some legacy SAML deployments may not be updated at all | NIST IR 8587 |
| FIDO and passkeys | The FIDO Alliance has committed to a seamless transition to PQC for its authentication solutions | UK NCSC |
In practice, key exchange can be protected now where platforms support hybrid ML-KEM. Post-quantum authentication depends on standards and products still arriving, so today's work is inventory, agility, trust anchor planning and vendor pressure. See the SSH Key Management Guide and the Passwordless and Passkeys Guide.
Tokens, assertions and larger signatures
NIST IR 8587, published in September 2026, notes that PQC migration affects both the systems that sign tokens and the relying parties, gateways and clients that validate or route them. ML-KEM and ML-DSA have larger public keys, signatures and ciphertexts than today's mechanisms, which "affect protocol design, token size, certificate and metadata handling, storage, transmission, and hardware-backed key protection".
| ML-DSA parameter set | Security category | Signature (bytes) | Public key (bytes) |
|---|---|---|---|
| ML-DSA-44 | 2 | 2,420 | 1,312 |
| ML-DSA-65 | 3 | 3,309 | 1,952 |
| ML-DSA-87 | 5 | 4,627 | 2,592 |
Sizes are the raw values from RFC 9881, Table 2, without ASN.1 encoding overhead; security categories are from NIST IR 8547. IR 8587 points out that browser cookies are commonly limited to about 4 kb and HTTP headers to about 8 kb, making cookies "increasingly unsuitable" for PQC-signed JWT access tokens. Where those limits bite, it suggests compact token formats, back-channel presentation, reference tokens with introspection or session-state designs. Certificate chains face the same pressure, since each certificate carries a public key and a signature.
Hardware-backed keys
IR 8587 warns that HSMs, secure elements and embedded processors may need firmware, product, validation or architecture changes before they can use PQC keys; IR 8547 says the same of HSMs and TPMs. Because IR 8587 requires identity provider signing keys to be generated in FIPS 140 validated modules, IdP migration timing depends on HSM vendor roadmaps. See the Token and Session Security Guide and the Identity Provider and SSO Security Guide.
Non-human identities and AI agents
Machine identities carry most of the quantum exposure. Workload certificates for mTLS, SPIFFE SVIDs (short-lived X.509 or JWT identity documents), OAuth client assertions and the access tokens AI agents present to tools and APIs all use the same signature algorithms. Short-lived workload identity is an advantage: credentials that are reissued automatically can change algorithm at the next issuance. See the Workload Identity Federation Guide and the Zero Trust for AI Agents Guide.
Building a cryptographic inventory
The NCSC's first milestone is discovery. It stresses that this is not a formal asset register at first: the nature, scale, versions and dependencies of each system matter more. For identity, cover:
- PKI: root and issuing CAs, certificate templates, issued certificates and their algorithms, revocation infrastructure. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Token and assertion signing: signing keys at identity providers, authorisation servers and applications, with algorithm, purpose, storage and planned lifetime. IR 8587 says organisations should keep an inventory recording "the type and purpose of each key, where it will be used and stored, and the expected lifetime".
- Relying parties: every service, gateway and library that validates those tokens.
- SSH, code signing, firmware signing and device identity keys. See the Cryptographic Key Management Guide.
- Authenticators: smart cards, hardware security keys and other "devices and tokens issued to end users", which the NCSC lists explicitly. See the Hardware Security Keys Guide.
- Providers: the libraries, HSMs, KMS services and SaaS identity platforms that supply the cryptography, with their PQC roadmaps. The NCSC expects managed service providers to carry out the same assessment for the services they run.
A cryptographic bill of materials (CBOM) can sit alongside software and AI bills of materials; see the AI Supply Chain and AI-BOM Guide. Combine top-down analysis of core services with bottom-up scanning, as the NCSC recommends.
Prioritising migration
NIST IR 8547 cites Mosca's theorem: if the years data must stay secure plus the years needed to migrate exceed the time until a quantum computer exists, migration is already late. For authentication, the equivalent question is how long the trust you issue today will stay in service. Rank identity systems in this order, then adjust for your own estate:
- Long-lived trust anchors: root and intermediate CAs, and device and firmware roots. NIST IR 8547 says devices that cannot update their signature verification code should require quantum-resistant signatures if they may outlive the arrival of quantum computers; the NCSC wants long-lived hardware roots of trust in the 2028 plan.
- Key exchange protecting credentials in transit: enable hybrid ML-KEM in TLS and SSH where supported.
- Token signing at identity providers: central and high impact; clients that read published key metadata can follow a change once their libraries support the algorithm.
- Code signing: signatures must stay verifiable for the life of the software. See the Software Supply Chain Security Guide.
- Everything else, in line with vendor support and normal refresh cycles, which the NCSC recommends aligning with where possible.
Migrating an enterprise PKI
The NCSC describes enterprise PKI migration as creating a new PQC root of trust and issuing PQC certificates to every entity, usually through a parallel PKI run alongside the traditional one for a staged migration. It warns that a system "will not provide quantum-secure authentication until migration of your PKI is complete, and traditional certificates have expired or been revoked". Some devices may need physical intervention; see the Device and IoT Identity Guide and the OT and ICS Identity and Access Guide. The NCSC notes that industrial IoT devices may be resource-constrained or not upgradeable.
Crypto-agility for identity systems
The NCSC advises choosing solutions with cryptographic agility, because traditional and post-quantum algorithms will coexist for a while. NIST IR 8547 adds that hybrid solutions hedge against weaknesses but add complexity and are expected to be temporary. In identity systems, agility means:
- Algorithms as configuration: no hard-coded algorithm names in token validation, certificate profiles or SSH configuration.
- Multiple keys side by side: publish keys in formats such as JWKS where each key carries a key ID, so relying parties can accept old and new keys during a change. IR 8587's rotation sequence (publish new keys, switch signing, keep accepting prior keys until issued tokens expire, then remove them) is the same sequence an algorithm change needs.
- Automated issuance and renewal: public TLS certificate lifetimes fall to 47 days by March 2029 under CA/Browser Forum ballot SC081, so automation is needed anyway. See the CLM Buyer's Guide.
- Trusted implementations: the NCSC says most organisations and suppliers should not write their own PQC implementations, but use certified implementations and trusted libraries.
Detection and monitoring
The NCSC warns that misconfigured cryptography can weaken security without an outage, and advises testing that systems actually use PQC cipher suites "and not falling back to traditional cryptography". Useful signals for identity teams:
- Negotiated key exchange: log the key exchange group on TLS terminators and SSH servers. OpenSSH 10.6 added a server-side WarnWeakCrypto option, enabled by default, that logs when a client uses key agreement that is not post-quantum safe.
- Certificate algorithms: report issuance by signature algorithm and flag long-lived RSA or ECDSA certificates issued after your cut-off.
- Token algorithms: record the signing algorithm and key ID of tokens accepted by gateways and APIs.
- Forgery indicators: keep the detections you already need for stolen signing keys. NIST IR 8587 says organisations should monitor for references to retired key identifiers as a signal of misconfiguration or attempted misuse.
Framework mapping
None of these frameworks has a PQC-specific control. This is an indicative NHI Mgmt Group alignment of PQC identity activities to existing controls, checked against the framework texts; it is not an official mapping.
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 |
|---|---|---|---|---|---|
| Cryptographic inventory of PKI, keys and tokens | ID.AM-02, ID.AM-08 | CM-8, PM-5 | A.5.9 | 1, 2 | - |
| Risk assessment and prioritisation | ID.AM-05, ID.RA-04, ID.RA-06 | RA-3, RA-7 | A.8.8 | - | - |
| Algorithm selection and key management | PR.DS-02 | SC-12, SC-12(3), SC-13 | A.8.24 | 3 | NHI7 |
| PKI certificates and public-key authentication | PR.AA-01, PR.AA-03 | SC-17, IA-5(2), IA-7 | A.8.5, A.8.24 | 4 | NHI4 |
| Token and assertion signing at IdPs | PR.AA-04 | IA-13, IA-13(1) | A.8.5 | - | NHI4 |
| Code and firmware signing | ID.RA-09, PR.PS-02 | CM-14, SI-7, SI-7(15) | A.8.25, A.8.32 | 2, 16 | - |
| Supplier PQC roadmaps and procurement | GV.SC-05, GV.SC-07 | SA-4, SR-3, SR-5 | A.5.19, A.5.21 | 15 | - |
| Legacy and unsupported crypto components | PR.PS-03 | SA-22 | A.8.8 | 2 | - |
Common failure patterns
- Treating a vendor scan as the whole inventory. Network scans see TLS endpoints, not IdP signing keys, SAML federations, firmware roots or smart cards.
- Waiting for certainty about quantum timelines. Discovery and planning cost little and take years; the NCSC sets 2028 for completing them regardless of when a quantum computer appears.
- Migrating issuers before relying parties. A new signing algorithm is useless if half the validators reject it. Inventory and upgrade consumers first.
- Swapping algorithms without automation. The next change stays just as hard. The Storm-0558 signing key stayed active because manual rotation had stopped, according to the CSRB as reported by BleepingComputer.
- Ignoring keys that cannot be changed in the field. The MSI Signing Keys Leak 2023 showed the cost of a firmware root of trust that devices cannot replace; the same applies to roots that a future quantum computer could break.
- No tested path for replacing a host or service key. In the GitHub RSA SSH Host Key Exposure 2023, rotating one host key caused warnings for SSH users and some failed workflows. An algorithm change across many keys is a larger version of the same event.
- Assuming hybrid means finished. Hybrid key exchange protects confidentiality only; authentication stays classical.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Share of identity systems with a completed cryptographic inventory entry | Discovery coverage against the NCSC 2028 milestone | Up, to 100% |
| Share of TLS and SSH connections using hybrid post-quantum key exchange | Harvest-now exposure of credentials in transit | Up |
| Number of trust anchors (roots, firmware keys) without a PQC migration plan | Long-lead risk | Down, to zero |
| Share of relying parties able to validate an ML-DSA signed token or certificate | Readiness to switch issuers | Up |
| Share of certificates and keys issued and renewed automatically | Crypto-agility | Up |
| Share of critical identity suppliers with a published PQC roadmap | Supply chain dependency | Up |
See the Identity Security Metrics Guide.
Implementation roadmap
| Phase | Identity and PKI actions | Output |
|---|---|---|
| First 30 days | Name an owner; list CAs, IdP signing keys and SSH host key types; ask critical identity suppliers for PQC roadmaps | Owner, scope, supplier questions sent |
| Days 31-90 | Extend the inventory to relying parties, code signing, firmware and authenticators; enable hybrid ML-KEM where TLS and SSH platforms already support it; find hard-coded algorithms | First cryptographic inventory; hybrid key exchange in place where supported |
| Days 91-180 | Rank systems by trust lifetime and impact; design the parallel PQC PKI; lab-test ML-DSA certificates and larger tokens; add PQC to procurement | Prioritised migration plan; test results |
| To 2028 | Complete discovery and the migration plan, including long-lived hardware roots, as the NCSC sets out; tell suppliers what you need | Plan aligned with NCSC 2028 milestone |
| To 2031 and 2035 | Migrate trust anchors and token signing first, then the rest; retire classical certificates and keys | Quantum-resistant authentication end to end |
Practitioner checklist
- Assign an owner for PQC readiness in identity and link it to key and certificate management.
- Build a cryptographic inventory covering PKI, token signing, relying parties, SSH, code signing, firmware and authenticators.
- Record each signing key's algorithm, purpose, storage and planned lifetime, as NIST IR 8587 recommends.
- Enable hybrid post-quantum key exchange for TLS and SSH where your platforms support it, and log what is negotiated.
- Make algorithms configurable and automate certificate and key rotation.
- Test ML-DSA certificates and PQC-signed tokens against cookie, header, chain and device size limits.
- Plan trust anchor, firmware root and long-lived device migrations first, using a parallel PQC PKI.
- Ask identity, HSM and PKI suppliers for PQC roadmaps and add PQC to procurement requirements.
- Upgrade relying parties to accept new algorithms before switching issuers.
- Track NIST's draft 2030 and 2035 dates and the NCSC's 2028, 2031 and 2035 milestones, and recheck them when IR 8547 is finalised.
Standards and references
- NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST: FIPS 204, Module-Lattice-Based Digital Signature Standard
- NIST: FIPS 205, Stateless Hash-Based Digital Signature Standard
- NIST: IR 8547, Transition to Post-Quantum Cryptography Standards (initial public draft)
- NIST: IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse
- NIST: Post-Quantum Cryptography project
- NIST: NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption
- UK NCSC: Timelines for migration to post-quantum cryptography
- IETF: RFC 9881, Algorithm Identifiers for ML-DSA in Internet X.509 PKI
- OpenSSH: Release notes
- CA/Browser Forum: Ballot SC081v3, schedule of reducing validity and data reuse periods
Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Cryptographic Key Management Guide · CLM Buyer's Guide · SSH Key Management Guide