PQC is not a big deal

Post-Quantum Cryptography Is Not a Big Deal

Every few months, a new wave of articles appears warning that quantum computers will soon render all existing encryption obsolete and that organisations need to act urgently. The reality is considerably more mundane. For most people and most organisations, the transition to post-quantum cryptography (PQC) is just routine IT hygiene dressed up in alarming language.

What PQC Actually Means in Practice

The concern is legitimate in principle. Algorithms like RSA and ECDH rely on mathematical problems — integer factorisation and discrete logarithm — that a sufficiently powerful quantum computer could solve using Shor's algorithm. NIST finalised its first set of PQC standards in 2024, namely ML-KEM, ML-DSA and SLH-DSA, which are designed to resist quantum attacks.

So far so good. But the question of what this means operationally is far less dramatic than the headlines suggest.

Browsers

For end users browsing the web, the migration to PQC ciphers is entirely invisible. Chrome has already been shipping experimental support for X25519Kyber768 as a hybrid key exchange since 2023, and other major browsers are following suit. For an organisation managing endpoints, this means patching browsers to a version that supports PQC negotiation. That is it. Patch management is already something every organisation should be doing on a regular cadence. There is nothing new here operationally.

In-House Developed Applications

For applications developed internally that make use of cryptographic libraries — whether OpenSSL, BoringSSL, libsodium or similar — the migration path is equally straightforward in principle. It involves updating to a library version that supports the new algorithms and testing that nothing breaks. Developers already do this regularly, either to pick up new features or to patch vulnerabilities. A zero-day in OpenSSL triggers an emergency update cycle. Adopting a new cipher suite is just a planned version bump. The key exchange or signature algorithm is typically abstracted away by the library, so the application code changes are minimal.

Vendor Applications

For commercial off-the-shelf software, the organisation has even less to do. The vendor will update their product on their own roadmap, as they always have done for cryptographic transitions in the past. TLS 1.0 was deprecated, RC4 was removed, SHA-1 certificates were distrusted — in each case, the vendors pushed updates and administrators applied them. PQC will follow the same pattern. The main action item is to check that vendors have a published roadmap and to factor that into procurement decisions.

The Threat Model Does Not Apply to Most People

The more significant point is that the realistic threat vector for quantum-enabled attacks is extremely narrow.

The attack scenario most frequently cited is "harvest now, decrypt later" (HNDL): an adversary intercepts and stores encrypted traffic today, intending to decrypt it once a sufficiently powerful quantum computer exists. This is a real concern for certain classes of data. But it requires the adversary to be able to intercept your traffic in the first place.

Traffic interception at scale requires the resources and positioning of a nation-state actor. The NSA, GCHQ, and their equivalents have the infrastructure to do this. A cybercriminal group running ransomware does not. If a nation-state adversary is targeting your communications specifically, you have much larger problems than your choice of key exchange algorithm — your threat model encompasses supply chain compromise, insider threats, physical access and a range of other vectors that are far easier to exploit than waiting a decade for a viable quantum computer.

For HNDL to be worth the effort, the data being harvested needs to retain its value far into the future — state secrets, long-term strategic intelligence, classified government communications. The average enterprise's TLS traffic, even if harvested today, is unlikely to be worth decrypting in ten years. By then the transactions will be irrelevant, the credentials will have been rotated and the data will have been superseded.

Who Should Actually Be Concerned

This does not mean PQC is irrelevant. Certain sectors have legitimate reasons to take it seriously ahead of the general curve. Defence and intelligence agencies protecting classified material with a decades-long shelf life, financial institutions processing transactions whose records must remain confidential for extended periods, and critical infrastructure operators whose systems are difficult to update once deployed all have reasons to prioritise this now.

For everyone else, the appropriate response is to ensure that PQC support is on the roadmap — for browsers via normal patch cycles, for in-house applications via library updates, for vendor software via procurement conversations — and to monitor the space without panic.

Conclusion

The cryptographic community has been working on this problem for years and the standards are now in place. The transition will happen incrementally as software is updated, which is exactly how every previous cryptographic migration has worked. There is no cliff edge. The organisations that should be worried about quantum adversaries already know who they are. For everyone else, keeping your software up to date is sufficient.