Post-Quantum Resilience: The Problem Isn’t Just the Algorithm

Why quantum-resistant cryptography is also a test of how organisations build, govern and change their digital infrastructure.

Could your organisation replace the cryptography behind its critical services? Could it do so without interrupting those services or weakening their protection?

That is a different question from whether it uses strong encryption today.

Cryptography secures connections, supports authentication and verifies the integrity of software and information. These functions span applications, devices, infrastructure and external services. They do not sit neatly within one product or team.

The transition to post-quantum cryptography brings this distributed foundation into focus. It also connects three capabilities that should not be confused.

Cryptographic security protects information and trust. Cryptographic agility enables those protections to change. Operational resilience keeps essential services dependable through disruption and change.

These capabilities reinforce one another, but they are not substitutes. Strong algorithms provide little value if an organisation cannot deploy them where needed. Equally, a migration cannot count as successful if it leaves critical services unreliable.

The challenge is to change a foundational security mechanism while preserving the services built around it.

The future threat creates decisions now

A sufficiently powerful, fault-tolerant quantum computer could break widely deployed public-key mechanisms. These include RSA and elliptic-curve cryptography.

The threat is not identical for all cryptography. Symmetric algorithms such as AES have a different risk profile and remain permitted under NIST’s existing guidance. A call to “replace all encryption” therefore misrepresents the task.

For confidentiality, the immediate concern is the lifetime of information. An adversary could capture communications protected by quantum-vulnerable key establishment today. It could then retain them for future decryption. The NSA calls this harvest now, decrypt later. A later upgrade cannot retroactively protect communications already captured.

Authentication presents a separate problem. Quantum attacks against vulnerable digital signatures could eventually enable impersonation and forgery. The NSA describes this as trust now, forge later. The risk concerns not just access to information, but also whether systems can trust identities and instructions.

Rather than relying on a predicted “quantum deadline”, organisations should examine their own timelines. These include required confidentiality periods, system lifetimes and migration lead times. Uncertainty about quantum computing does not remove the need to understand them.

Replacing the algorithms is only the beginning

NIST approved three post-quantum standards in August 2024. ML-KEM supports shared-key establishment, while ML-DSA and SLH-DSA provide digital signatures. These are distinct functions, not interchangeable replacements for a single form of “encryption”.

Protocol integration is advancing too. In August 2026, the IETF published RFC 10024 for hybrid key agreement in TLS 1.3. It combines conventional elliptic-curve mechanisms with ML-KEM.

But post-quantum key establishment does not automatically provide post-quantum authentication. The signatures used to authenticate participants need separate treatment.

Consider an illustrative enterprise service. A browser reaches it through an external gateway. Certificates authenticate its servers, while signed tokens carry identity information. Internal components communicate over separate connections. Digital signatures verify software updates, while cryptographic checks help devices verify their firmware.

Upgrading the gateway would address only part of this architecture. It would not automatically migrate the identity service, update mechanism or underlying devices.

A claim that a product “supports post-quantum cryptography” therefore needs qualification. Which function does it protect? Where is that protection enabled and actually used? What still depends on quantum-vulnerable mechanisms?

The relevant unit of analysis is the service and its dependencies, not just the product being upgraded.

Cryptographic agility is an operating capability

NIST’s guidance connects cryptographic agility with changing algorithms while maintaining security and operations. This makes agility an architectural and operational capability, not simply a product feature.

The starting point is visibility. NIST’s migration programme links cryptographic discovery with risk assessment and prioritisation. Knowing where cryptography is used helps establish what needs attention first.

But an inventory must support decisions. Each important dependency should have an owner and a clear relationship to a service. It should explain what the cryptography protects, who can change it, and what might prevent replacement.

Design choices, naturally, are important. For new systems, I would ask how cryptographic components will be updated. Can they change through supported interfaces? Or would replacement require changes to application logic or hardware?

Agility should mean controlled adaptability, not unlimited choice. That requires approved mechanisms, clear selection policies and a practical way to retire mechanisms that are no longer acceptable.

Deployment also needs verification. The NCSC warns that systems can remain operational while falling back to traditional cryptography. A successful connection does not prove that the intended protection is active. Testing must cover security behaviour as well as interoperability.

Rollback requires similar care. Reverting to an older mechanism may restore service after a failed deployment. Any renewed exposure should be assessed, authorised and time-bounded. It should not become the permanent configuration by default.

Meta’s migration framework distinguishes PQ-Ready from PQ-Enabled. The former means a suitable solution has been implemented but not activated. The latter means that protection is deployed for the relevant use case. Readiness can shorten response times, but it is not the same as protection.

I would measure progress through evidence. Which critical dependencies have been assessed, and which protections are active? Which exceptions remain, and which legacy mechanisms can actually be retired?

Cryptographic agility is not a promise that change will be easy. It is the demonstrated ability to make necessary change safely.

From cryptographic migration to organisational resilience

The NCSC’s migration workshop report emphasises executive sponsorship, collaboration and supplier readiness. The work extends beyond a specialist security team because the dependencies extend beyond that team’s control.

Responsibility should reflect this. Security specialists assess exposure and define requirements. Engineering teams evaluate implementations, while service owners establish acceptable disruption. Procurement addresses supplier commitments. While leadership must resolve competing priorities and fund the transition.

Supplier conversations should go beyond general promises of “quantum readiness”. Organisations need to establish what will be delivered and when. They should also clarify hardware requirements, interoperability testing and customer responsibilities. Early engagment can help align migration with planned technology refreshes.

On the other side, prioritisation must consider how difficult a system will be to change. Meta’s framework distinguishes patchable systems from those with public keys embedded in hardware. Long lived equipment can therefore require attention before its authentication mechanisms face an immediate quantum threat.

This brings PQC into investment decisions being made today. Before buying equipment with a long service life, organisations should ask how its security foundations will evolve. Otherwise, today’s procurement decision could create tomorrow’s replacement obligation.

The UK’s NCSC provides milestones for this work. By 2028, organisations should define migration goals, complete discovery and prepare an initial plan. By 2031, they should complete their highest-priority migration activities. By 2035, they should complete migration. Obviously, these are planning targets, not predictions of when existing cryptography will fail.

The response should remain proportionate. The NCSC expects much commodity technology to migrate through vendor updates and routine refreshes. Bespoke and specialised systems require more direct planning.

The objective is not to turn every organisation into a cryptography research team. It is to ensure that someone understands the exposure, owns the transition and verifies the outcome.

Design for the ability to change

Post-quantum migration must preserve more than confidentiality. It must also maintain trustworthy authentication and service continuity.

A service is not resilient merely because it remains available. Its availability means little if attackers can impersonate trusted parties or forge accepted instructions. Equally, stronger cryptography is insufficient if its introduction causes unacceptable disruption.

There is a broader lesson here. An organisation may not know where its cryptography is used or who controls it. It may also struggle to coordinate its replacement. These weaknesses already exist. The quantum threat simply makes them more visible.

Addressing these elememnts should make future security transitions more manageable. Better visibility and clearer ownership have value beyond this migration. But architectural improvement must support deployment, not postpone it while an organisation pursues an ideal system.

The aim is not simply to adopt algorithms designed to resist quantum attacks. It is to build systems and organisations that can change their security foundations while remaining worthy of trust.

References

1. National Security Agency (NSA). (1 October 2026). Post-Quantum Cryptography: A Digital Armor.
2. National Security Agency (NSA). (1 October 2026). Post-Quantum Cryptography: Primer.
3. National Institute of Standards and Technology (NIST). Post-Quantum Cryptography: FAQs. Updated 5 August 2026. NIST Computer Security Resource Center
4. National Institute of Standards and Technology (NIST). (13 August 2024). Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography.
5. Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and Stebila, D. (August 2026). Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3. RFC 10024. Internet Engineering Task Force (IETF).
6. Barker, E., et al. Considerations for Achieving Crypto Agility: Strategies and Practices. NIST CSWP 39, Update 1. Originally published 19 December 2025. Updated 29 June 2026.
7. National Cybersecurity Center of Excellence (NCCoE), NIST. Migration to Post-Quantum Cryptography.Project resource.
8. National Cyber Security Centre (NCSC). (20 March 2025). Timelines for Migration to Post-Quantum Cryptography.
9. Flo D and Lizzie Moseley. (22 July 2026). Post-Quantum Cryptography (PQC) Migration Workshop Report.National Cyber Security Centre (NCSC).
10. Engineering at Meta. (16 April 2026). Post-Quantum Cryptography Migration at Meta: Framework, Lessons, and Takeaways.