TL;DR: Quantum-safe migration is already a live planning problem because data with long confidentiality lifetimes may be harvested now and decrypted later, and the article argues that inventorying cryptographic assets, mapping protocol use, and aligning vendors and standards are now prerequisite steps, according to SSH Communications Security. The real challenge is governance: PQC migration exposes where infrastructure, firmware, and embedded encryption assumptions outlast the controls meant to manage them.
At a glance
What this is: This webinar argues that post-quantum cryptography migration is already a planning problem because cryptographic use is distributed across systems, firmware and protocols, making inventory the first control gap.
Why it matters: IAM, NHI and platform teams need to know where encryption and trust are embedded today, because quantum-safe migration fails when cryptographic dependencies are invisible to governance.
Context
Post-quantum cryptography migration is an identity and governance problem because cryptographic trust is embedded across systems, protocols, firmware and vendor-managed components, not just in one TLS configuration. If teams cannot map where encryption is used, they cannot decide what needs to change, what can be upgraded, and what must be replaced.
The article’s core concern is not abstract quantum risk alone. It is the operational gap between where cryptography exists and how organisations govern it, especially when some assets use hard-coded algorithms or embedded hardware that may be difficult or impossible to retrofit.
Key questions
A: Start with the links that carry long-lived sensitive data and high-value administrative traffic, then use hybrid cryptography where classical and post-quantum methods can coexist. This lets teams gain quantum-safe exposure reduction while preserving compatibility. The key is to treat PQC as a staged architecture change, not a single cutover event.
Q: Why do embedded systems make PQC migration harder?
A: Embedded systems are difficult because their encryption may be hard-coded into firmware or hardware, leaving no simple patch path. In those cases, migration becomes an asset-lifecycle problem, and some components may need replacement rather than reconfiguration.
Q: When should security teams prioritise PQC work over other cryptographic projects?
A: Prioritise PQC when the organisation holds data that must stay confidential for years or decades, or when critical systems depend on encryption that cannot be easily upgraded. Those conditions create the greatest future exposure and the longest remediation lead time.
Q: What are the signs that an organisation is not ready for quantum-safe encryption migration?
A: A common warning sign is that the organisation cannot say where encryption is used, which assets depend on it, or which systems would break if algorithms changed. Another indicator is the absence of a migration roadmap, test plan, or maintenance cycle for cryptographic updates. If discovery is incomplete, readiness is still mostly aspirational.
Technical breakdown
Cryptographic inventory is the first control boundary
PQC migration starts with knowing where cryptography exists, because encryption is not a single control point. It lives in application code, web servers, certificates, protocols, embedded firmware and hardware-level implementations. Centralised systems are easier to modify, but distributed dependencies create hidden blast radius. In governance terms, inventory is the prerequisite for impact analysis: without it, organisations cannot tell which identities, services or devices depend on current algorithms. That makes cryptographic discovery a lifecycle exercise as much as a technical one.
Practical implication: build an inventory of cryptographic assets, protocols and embedded dependencies before selecting any migration path.
Embedded firmware and hard-coded algorithms resist retrofit
The hardest part of PQC migration is not algorithm choice, but replacement friction. When encryption is baked into hardware, firmware or fixed libraries, a simple software update may not be enough. That creates a class of systems where quantum-safe change is constrained by device lifecycle, vendor support and operational downtime. For identity practitioners, this matters because machine trust often depends on assets that cannot be rotated or reconfigured on demand. The migration problem therefore extends into asset retirement and procurement, not just crypto engineering.
Practical implication: identify systems that cannot support cryptographic upgrade in place and treat them as replacement candidates in migration planning.
PQC turns vendor assurance into a governance dependency
No single organisation will solve PQC migration in isolation because the change depends on vendors, standards bodies and implementation partners moving in step. That means vendor roadmaps become part of security governance, not procurement trivia. If a supplier’s components, appliances or embedded libraries lag behind standards adoption, the organisation inherits the delay. For IAM and security leaders, this is a lifecycle assurance problem across service providers, not only a technical migration programme.
Practical implication: assess vendor PQC roadmaps and contract expectations as part of cryptographic governance and third-party risk management.
Breaches seen in the wild
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
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
Cryptographic migration is an asset-governance problem before it is an algorithm problem: organisations fail when they treat PQC as a standards swap instead of a discovery exercise. Encryption exists in protocols, code, embedded devices and vendor systems, which means the real control boundary is inventory and dependency mapping. The practitioner conclusion is simple: if you cannot locate the cryptographic estate, you cannot govern the migration.
Hard-coded encryption assumptions are the most durable failure mode in this transition: centralised systems can usually be adapted, but embedded firmware and fixed algorithms create migration dead-ends. That is not just technical debt, it is governance debt because the organisation may be unable to change controls without replacing assets. The implication is that lifecycle planning must include retirement paths for systems that cannot be upgraded.
PQC exposes where third-party assurance and standards adoption become part of identity governance: the article makes clear that no organisation migrates alone. Vendor roadmaps, implementation partners and standards bodies all shape the achievable timeline, which means cryptographic readiness is now a supplier-management issue as much as an internal security issue. The practitioner conclusion is to treat PQC as a governed dependency chain.
Long-confidentiality data creates a retention-risk model that most identity programmes do not yet operationalise: data harvested today may be decrypted later, so the control question is not only who can read it now, but how long its confidentiality must survive. That changes prioritisation across identity, key management and data classification. The practitioner conclusion is to align cryptographic protection with information lifespan, not just system ownership.
What this signals
Cryptographic estate visibility will become a governance baseline: the organisations that move first will be the ones that can answer where encryption lives, who owns it and which assets cannot be changed in place. That is not a crypto-only task, because identity, infrastructure and procurement teams all influence the migration path.
Long-lived confidentiality changes the prioritisation model: data with decade-scale sensitivity cannot wait for generic refresh cycles, especially when harvest-now-decrypt-later risk is already part of the threat model. The practical shift is to align protection strength with information lifespan, not with the age of the control stack.
For practitioners
- Build a cryptographic asset inventory Catalogue where encryption is used across applications, protocols, certificates, devices and firmware so migration scope is visible before any algorithm change is planned.
- Map hard-coded and embedded dependencies Identify hardware-level encryption, embedded firmware and fixed libraries that cannot be upgraded in place, then separate them from software-only remediation paths.
- Review vendor PQC roadmaps Check whether critical suppliers, managed platforms and appliance vendors have credible post-quantum plans, because their readiness becomes part of your own control timeline.
- Prioritise long-lived confidentiality data Focus first on data that must remain confidential for years or decades, since those assets carry the greatest harvest-now-decrypt-later risk.
Key takeaways
- Post-quantum migration is not only a cryptography upgrade. It is a governance exercise in finding every place where identity, trust and encryption intersect.
- The hardest blockers are the systems that cannot be changed easily, especially embedded firmware and hard-coded algorithms.
- Teams should inventory cryptographic assets now and use data lifespan, vendor readiness and replacement constraints to set migration order.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Hidden cryptographic dependencies create ungoverned trust and access scope across machine assets. |
| NHI-07 — Long-Lived Secrets | Legacy encryption can persist for years, mirroring long-lived credential risk in NHI estates. | |
| Recommendation — Map cryptographic dependencies to NHI-05 and reduce unseen trust paths across systems and devices. Inventory long-lived cryptographic dependencies and plan replacement for assets that cannot be rotated. | ||
| NIST CSF 2.0 | ID.AM-02 — Assets are inventoried | PQC migration depends on knowing where cryptographic assets and dependencies actually reside. |
| Recommendation — Inventory cryptographic assets and dependencies before sequencing any PQC migration work. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Cryptographic lifecycle governance maps to managed credentials, keys and rotation-dependent trust. |
| Recommendation — Apply IA-5 discipline to the lifecycle of cryptographic authenticators and replace unmanageable dependencies. | ||
| NIST Zero Trust (SP 800-207) | Supply Chain / Continuous Verification — Supply Chain / Continuous Verification | Vendor readiness and third-party components shape the trust boundary for PQC migration. |
| Recommendation — Extend zero trust verification to suppliers whose cryptographic roadmaps affect your migration timeline. | ||
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.
- Cryptographic Inventory: A cryptographic inventory is a continuously updated record of keys, certificates, algorithms, libraries and trust anchors across an organisation. It is not a spreadsheet or one-time audit output. In practice, it links each asset to ownership, usage, lifecycle state and risk so teams can make remediation decisions.
- Device Encryption: A safeguard that protects data stored on an endpoint by making it unreadable without the correct authorization. In BYOD programs, encryption reduces exposure if a device is lost or stolen, but it must be paired with access controls, policy enforcement, and user training to be effective.
- 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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org