What do organisations get wrong about post-quantum risk?

They often treat it as a future cryptography upgrade instead of a present-day data prioritisation problem. If a dataset would still matter in five or ten years, it already belongs in the migration plan, even if the algorithm protecting it has not yet been broken.

Why This Matters for Security Teams

Post-quantum risk is easy to misunderstand because it is not only a cryptography problem. It is a governance, data-lifespan, and migration-priority problem. Security teams that wait for a visible break in classical encryption may miss the larger issue: adversaries can already collect protected data now and decrypt it later, making long-lived records, sensitive communications, and regulated archives immediate candidates for review. The NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations to treat risk management as a continuous business function rather than a one-time technical refresh.

What teams often get wrong is assuming that inventorying algorithms is enough. In practice, the real exposure sits in where cryptography is used, how long protected data must remain confidential, and which systems can be changed without breaking service dependencies. That means PKI, code-signing, VPNs, backup archives, identity tokens, firmware trust chains, and API trust decisions all need classification. Where identity and NHI governance intersect, post-quantum planning also has to consider machine identities and automated systems that depend on long-lived certificates or signing keys. In practice, many security teams encounter post-quantum risk only after sensitive data has already been retained for too long, rather than through intentional lifecycle-based planning.

How It Works in Practice

A practical programme starts by ranking data and trust paths by confidentiality lifespan, not just by system criticality. If information must remain secret for years, it should be treated as post-quantum sensitive even when the current algorithm is still acceptable. That changes the migration order. High-value archives, healthcare records, legal files, source code, intellectual property, and operational secrets should be reviewed before low-lifespan workloads.

Security architecture also matters. Current guidance suggests organisations should map where public-key cryptography is embedded, then identify which dependencies are externally visible and which are hidden in middleware, embedded devices, or third-party services. The issue is not limited to TLS. It extends to signing, key exchange, certificate authorities, update channels, and device trust. NIST guidance on quantum-resistant algorithms and migration planning, alongside the broader control structure in NIST Cybersecurity Framework 2.0, supports a phased approach: discover, prioritise, pilot, and then replace where operationally safe.

• Classify data by how long confidentiality must hold, not only by sensitivity label.
• Inventory all uses of asymmetric cryptography, including hidden service dependencies.
• Prioritise systems that support long-lived records, digital signatures, and device trust.
• Test hybrid approaches where standards and product support still make migration uneven.
• Include identity infrastructure, machine identities, and signing workflows in scope.

For mature programmes, the work should connect to broader adversary modelling and software assurance, because post-quantum transition failures often appear as trust-chain outages, not clean cryptographic failures. The MITRE ATLAS threat model is not a PQC standard, but it helps teams think about how attackers exploit weak trust assumptions and supply chain dependencies. These controls tend to break down when organisations rely on undocumented embedded cryptography or vendor-managed systems with no practical upgrade path.

Common Variations and Edge Cases

Tighter cryptographic control often increases change-management overhead, requiring organisations to balance resilience against compatibility, cost, and operational risk. That tradeoff becomes especially sharp in environments with legacy devices, regulated records, or third-party platforms that cannot be rekeyed quickly.

One common edge case is the “it is not public-facing, so it is safe” assumption. Internal systems still matter if they hold long-lived secrets or support identity assertions that must remain trustworthy for years. Another is assuming that a single algorithm replacement will solve the problem. Best practice is evolving toward crypto-agility, because no universal standard for a one-time swap covers every dependency, lifecycle, and vendor constraint. Organisations also need to separate immediate migration from medium-term standardisation: some systems can move to hybrid or transitional models now, while others require waiting for product maturity.

The identity bridge matters here too. Machine identities, workload certificates, and automated signing flows can become the hidden dependency that slows the entire programme. Where those identities are embedded in CI/CD, IoT, or agentic AI systems, post-quantum planning should include renewal automation, ownership clarity, and fallback procedures. The current guidance suggests treating those systems as part of critical trust infrastructure rather than as routine certificate housekeeping.

For most organisations, the error is not ignorance of quantum threats. It is underestimating the amount of present-day architecture that depends on cryptography they cannot easily replace later.

Related resources from NHI Mgmt Group

• What should organisations get wrong less often about quantum computing risk?
• What do organisations get wrong about post-compromise identity risk?
• What do organisations get wrong about measuring non-human identity risk?
• What do organisations get wrong about questionnaire-based vendor risk management?