What does “quantum-safe” actually cover?

'Quantum-safe' is appearing on firewalls, VPNs and other network products. Suppliers are introducing post-quantum cryptography, and organisations are beginning to upgrade their infrastructure. But when a product is described as quantum-safe, what exactly does that promise cover?

The question is becoming more relevant as the technology moves into deployment. In October 2026, the NCSC updated its TLS guidance to reflect developments in post-quantum key agreement. Yet there is a risk of assuming that an upgraded product protects more than it actually does.

A supplier can describe the protection its technology provides. Whether that protection extends across a business service is something the organisation needs to establish.

A protected connection is not a protected service

A sufficiently capable quantum computer could break the RSA and elliptic-curve public-key cryptography widely used for key exchange, authentication and digital signatures. Symmetric encryption, including AES-256, remains comparatively strong. The challenge lies in how keys are established and how trust is maintained.

Consider an organisation upgrading its firewall and remote-access VPN to support hybrid post-quantum key exchange. Its existing applications and integrations remain unchanged.

Traffic inside the VPN tunnel benefits from its confidentiality protection against passive interception, even where the application uses classical cryptography. But that protection ends where the tunnel terminates.

The separate connection from the VPN gateway to an internal application may still use classical key exchange. The application might connect to a payment provider using classical cryptography. Its software updates may still rely on RSA signatures, raising a separate question about the long-term integrity and authenticity of software.

These are different exposures, and they need different answers.

The upgraded VPN may be working exactly as intended. A quantum-safe edge is not a quantum-safe service.

Supporting protection is not the same as proving it

There is a difference between what a product supports, what a connection uses and what an organisation can verify.

In September 2026, Cloudflare announced additional visibility into the cryptographic algorithms negotiated across TLS connections, including connections to origin servers. It illustrates why observing actual connections matters.

A supplier statement may confirm that post-quantum cryptography is supported. A configuration check can show that it is enabled. Neither proves that a particular connection negotiated it.

Connection testing provides stronger evidence, but even a verified post-quantum handshake says little about other connections, authentication mechanisms or signing dependencies elsewhere in the service.

Verification has to follow the traffic and trust relationships, not stop at the product boundary.

The dependencies organisations cannot yet see

One of the biggest challenges in post-quantum migration is knowing what needs to change. Organisations may discover applications with unclear ownership, undocumented integrations or systems where nobody can confidently identify the cryptography in use.

They may also struggle to establish how long particular information needs to remain confidential. These gaps affect migration priorities because organisations need to understand what requires protection, how exposed it is and how long that protection must last.

The NCSC's migration milestones provide a useful framework, with discovery and initial planning recommended by 2028, high-priority migration by 2031 and completion by 2035. But meaningful progress requires more than a record of upgraded products. It requires evidence of what those changes actually protect.

What should organisations measure instead?

A migration report showing more quantum-safe products may look reassuring. But unless it shows which critical services are protected, and where dependencies remain, it tells leaders surprisingly little about their actual exposure.

For each critical service, organisations should understand which connections and cryptographic functions are protected, where that protection ends and what remains dependent on classical cryptography.

That means asking suppliers precise questions, checking negotiated algorithms, tracing dependencies beyond upgraded boundaries and recording unresolved gaps alongside completed work.

The challenge is no longer simply whether organisations can deploy post-quantum cryptography. It is whether they can demonstrate that the services they depend on are protected by it, and identify precisely where they are not.

About UBDS Digital

At UBDS Digital, we help organisations understand their cybersecurity risks and work out what needs to change. Our post-quantum cryptography readiness work focuses on identifying where existing encryption could be vulnerable, understanding the dependencies involved and planning a practical route towards stronger protection.

Find out more about our Post-Quantum Cryptography Readiness services.