TL;DR: ML-KEM, ML-DSA and SLH-DSA form the first NIST post-quantum standards, according to Fortanix, but the real migration blocker is visibility into where RSA and elliptic-curve cryptography still protects key exchange, signatures and certificates. The work starts with a crypto inventory, because harvest-now, decrypt-later risk already exists and crypto-agility only matters once dependencies are mapped.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Fortanix's blog post: Migration planning for the first three NIST post-quantum cryptography algorithms starts with inventory, not algorithm selection.
Why it matters: Identity, PKI, and platform teams need to know where RSA, elliptic-curve cryptography, certificates, and signing workflows still exist before quantum-risk migration can be governed credibly.
Context
Post-quantum cryptography is the shift from today’s public-key algorithms to new standards that can survive quantum attacks. The governance gap is not only technical. Most organisations do not know every place cryptography is embedded across systems, applications, data flows, certificates, and signing workflows, which makes migration planning incomplete from the start.
This article sits at the intersection of cryptography, certificate lifecycle, and machine identity and PKI governance. The strongest practical lesson is that the migration problem is as much about discovery and ownership as it is about the new algorithms themselves.
Key questions
Q: How should teams prioritise data for post-quantum cryptography migration?
A: Prioritise data by confidentiality lifetime, replaceability, and exposure spread. The most urgent datasets are those that remain harmful if disclosed for years, cannot be reissued easily, and already exist in multiple copies across backups, analytics, email, and cloud services. That gives you a practical queue for migration and compensating controls.
Q: Why does quantum risk matter before quantum computers can actually break RSA?
A: Quantum risk matters early because attackers can record encrypted traffic today and decrypt it later once enough quantum capability exists. That makes long term secrets vulnerable long before Q-Day arrives. Organisations that protect sensitive data with long retention periods should treat confidentiality as a current planning problem, not a distant theoretical one, because exposure can happen retroactively after interception.
Q: What breaks when organisations delay post-quantum migration for sovereign certificate authorities?
A: Delaying migration leaves the certificate authority hierarchy dependent on algorithms that may not survive future quantum attacks. Because the CA is the root of trust, any weakness can undermine issuance, signatures, and trust validation across the estate. The risk extends to electronic identities, document signing, and timestamping if those services are not planned with the CA transition.
Q: What is the difference between ML-KEM and ML-DSA in PQC planning?
A: ML-KEM is for key establishment, where two parties derive a shared secret over a public channel. ML-DSA is for signatures, where systems need authentication, integrity, and non-repudiation. Teams should not treat them as substitutes, because they protect different trust functions in the cryptographic stack.
Technical breakdown
What ML-KEM changes for key establishment
ML-KEM is the NIST-standardised post-quantum algorithm for key establishment. It replaces the RSA and elliptic-curve key transport patterns that today underpin many secure sessions, while still relying on a public-channel exchange that produces a shared secret for symmetric encryption. That makes it the first building block for moving data-in-transit protections away from vulnerable public-key schemes. In practice, the main challenge is not the math alone but where key establishment is embedded in product stacks, PKI flows, and service-to-service trust paths. Mixed estates will need transitional designs, not a single cutover. Practical implication: map every dependency on RSA or ECDH before choosing a migration sequence. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Map every dependency on RSA or ECDH before choosing a migration sequence.
Why ML-DSA and SLH-DSA matter for signatures and trust
ML-DSA is the primary post-quantum signature standard, designed for authentication, integrity, and non-repudiation. SLH-DSA is the hash-based alternative, and the article correctly notes the trade-offs: larger signatures and slower signing, but strong fit for long-lived roots of trust such as firmware and code signing. That distinction matters because signatures govern software provenance, certificate trust, and document authenticity, not just encryption. Teams should expect operational trade-offs in size, latency, and tooling compatibility when replacing ECDSA or RSA signatures. Practical implication: separate short-lived transaction signing from long-lived trust anchors in your migration plan. Read Post-Quantum Readiness for Identity and PKI.
Practical implication: Separate short-lived transaction signing from long-lived trust anchors in your migration plan.
How crypto-agility turns PQC into a governance problem
Crypto-agility is the ability to switch cryptographic algorithms without rebuilding applications or disrupting services. The article makes clear that this is the real objective, because standards will change, implementations will vary, and not every workload can move at the same pace. Discovery tooling, key metadata, and vendor readiness are therefore governance inputs, not optional extras. For identity teams, this is especially important where certificates, tokens, databases, and signing workflows intersect with machine identity and trust chains. Practical implication: treat cryptographic inventory as a control objective, not a one-time assessment.
Practical implication: Treat cryptographic inventory as a control objective, not a one-time assessment.
Threat narrative
Attacker objective: Preserve access to encrypted information until decryption becomes possible, then recover data, signatures, or trust material that was assumed to be safe.
- Entry occurs when adversaries collect encrypted traffic or stored data now, even though they cannot decrypt it yet.
- Escalation happens later if the organisation is still using RSA or elliptic-curve cryptography when quantum-capable decryption becomes practical.
- Impact is delayed exposure of previously protected data, signatures, certificates, or documents after the underlying algorithms fail.
Breaches seen in the wild
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Crypto migration is an identity governance problem, not just a cryptography refresh. The article shows that PQC readiness depends on knowing where certificates, signatures, and key exchange are used across systems. That is governance work because ownership, dependency mapping, and lifecycle control determine whether migration can happen at all. Where machine identity and PKI are involved, discovery has to cover service accounts, certificates, and signing flows together. Practitioners should treat cryptographic inventory as part of identity governance, not a side exercise.
Harvest-now, decrypt-later changes the risk model for long-lived data. The key point is that secrecy can fail before the migration project is even finished. That shifts attention from hypothetical future compromise to current exposure windows created by old cryptography still embedded in enterprise systems. The first named concept here is cryptographic exposure debt: the accumulated risk created when organisations continue relying on RSA and elliptic-curve dependencies they cannot fully inventory or replace. Practitioners should prioritise the oldest and most sensitive cryptographic dependencies first.
Signature migration will be harder than many teams expect because signatures carry business meaning, not just security control. ML-DSA and SLH-DSA are not interchangeable in practice, especially where code signing, firmware trust, and document authenticity are involved. Larger signatures and slower signing can change storage, latency, and integration assumptions. That means migration plans must separate high-volume authentication paths from long-lived roots of trust. Practitioners should classify signature use cases by operational tolerance before choosing a replacement pattern.
Vendor readiness is now part of cryptographic control design. The article is right to stress that organisations must hold vendors accountable for PQC readiness, because dependency chains extend beyond internal infrastructure. If a platform, PKI, or data service cannot support algorithm transitions, crypto-agility stops at the enterprise boundary. That makes procurement, contract language, and assurance evidence part of the control surface. Practitioners should add PQC readiness to third-party risk and renewal reviews.
Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Cryptographic exposure debt: post-quantum readiness will be decided by what organisations cannot yet see in their crypto estate, not by algorithm naming alone. Inventory depth, certificate ownership, and signing workflow mapping will determine how quickly migration can move from theory to execution.
The next governance step is to tie cryptographic inventory to PKI lifecycle control, because algorithm change without lifecycle ownership creates the illusion of progress. For identity and platform teams, PQC becomes a programme for dependency visibility, vendor assurance, and staged replacement rather than a single technical upgrade.
For practitioners
- Map every RSA and elliptic-curve dependency Inventory systems, applications, data stores, certificates, and signing workflows so you know where vulnerable public-key cryptography remains in use.
- Classify cryptographic use by business criticality Rank high-value data, long-lived trust anchors, and externally exposed services first so migration work follows exposure, not convenience.
- Build a crypto-agility roadmap Plan for algorithm substitution without rebuilding applications, and require vendors to explain how they will support transitions to NIST-approved PQC standards.
- Separate signature use cases by operational tolerance Treat firmware, code signing, and document authenticity differently from short-lived authentication flows because SLH-DSA and ML-DSA impose different trade-offs.
Key takeaways
- The central risk is not only future quantum capability but the current inability to map where vulnerable public-key cryptography still protects trust and data.
- The article shows that ML-KEM secures key establishment, while ML-DSA and SLH-DSA cover signature use cases with different operational trade-offs.
- The practical control is crypto inventory plus crypto-agility, because migration cannot succeed until teams know what to replace and in what order.
Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · Post-Quantum Cryptography Migration Guide · Post-Quantum Readiness for Identity and PKI
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-57 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article centres on migrating cryptographic algorithms and managing their lifecycle. |
| Recommendation — Inventory, rotate, and retire cryptographic dependencies through a controlled key management lifecycle. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | The post focuses on protecting communications as public-key algorithms age out. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cryptographic trust paths govern service-to-service and certificate-based access decisions. | |
| Recommendation — Review data-in-transit controls for algorithm agility and plan transitions away from vulnerable public-key schemes. Align certificate and token trust decisions with least-privilege access boundaries. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The article highlights long-lived cryptographic trust material that persists across systems and migrations. |
| Recommendation — Find and retire long-lived cryptographic dependencies before they become unmanageable exposure points. | ||
| MITRE ATT&CK | TA0010 — Exfiltration | The harvest-now, decrypt-later model is an exfiltration-at-rest threat pattern. |
| Recommendation — Hunt for long-term collection of encrypted data that could be decrypted later. | ||
Key terms
- Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
- Harvest now, decrypt later: An attacker strategy where encrypted traffic or stored data is collected today and decrypted later when better computing power becomes available. It matters to NHI governance because machine identities often protect the data paths and secrets most worth preserving over time.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the broader security and trust problems that underpin modern programmes.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org