Post-Quantum Cryptography

In August 2024, NIST published the first three federal standards for post-quantum cryptography. Around seven months later, the UK NCSC published its migration roadmap and the EU followed with a coordinated implementation plan in June 2025. The message from all three jurisdictions is the same: the transition is coming, the guidance is here and for many it's becoming mandatory.

This creates a familiar problem. Cybersecurity leaders are being asked to prepare for a threat that does not yet exist - a cryptographically relevant quantum computer - against a deadline that sounds distant, but it is not. The 2035 NCSC target for full migration sounds like a long horizon until you consider that many organisations take five to seven years simply to rotate a certificate authority and the "harvest now, decrypt later" threat means that data you are protecting with RSA or elliptic curve cryptography today may already be captured in transit today, just waiting for the day a quantum machine can decrypt it.

This guide covers what the regulators in the US, UK and EU are actually requiring, what those requirements mean for your infrastructure, how enforcement will work in practice, and how to begin the cryptographic inventory that every roadmap demands with a new tool that we've opened sourced to help in the discovery piece.

Lattice-Based Cryptography

Before examining the standards, it is worth understanding why NIST chose the algorithms it did. The short answer is that RSA, elliptic curve cryptography, and Diffie-Hellman all rely on similar mathematical assumptions: that factoring large integers and computing discrete logarithms are computationally infeasible. Shor's algorithm, published in 1994, proved that a sufficiently powerful quantum computer solves both problems in polynomial time. A cryptographically relevant quantum computer does not exist today, but the mathematical case is established that, when such a machine arrives, public-key systems based on RSA and elliptic curve cryptography become vulnerable to retrospective decryption and signature forgery.

Post-quantum cryptography replaces those assumptions with mathematical problems believed to be hard even for quantum computers. NIST evaluated submissions across five families of problems: lattice-based, code-based, hash-based, multivariate, and isogeny-based. Lattice-based constructions emerged as the clear winner for general-purpose deployment.

A lattice is a geometric grid of points in high-dimensional space. The security of lattice-based schemes rests on the difficulty of finding the shortest vector in such a grid - a problem known as the Shortest Vector Problem (SVP) and its close relative, the Learning With Errors (LWE) problem. Despite decades of research, no quantum algorithm solves these problems efficiently. The best known attacks still require exponential time, even on a quantum computer.

Lattice-based schemes also have practical advantages that matter for real-world deployment:

When it comes to cryptography, monocultures are dangerous and so NIST has not bet everything on lattices. SLH-DSA is hash-based, relying only on the security of cryptographic hash functions - a conservative assumption with decades of scrutiny. HQC, selected in March 2025, is code-based, using error-correcting codes rather than lattices. This diversification is deliberate. If a cryptanalytic breakthrough weakens lattice assumptions, organisations will have alternatives from entirely different mathematical families.

What the Regulators Are Saying

United States: Standards First, Mandates Following

The US has moved fastest on standardisation and is now moving equally fast on compulsion.

NIST finalized its first three PQC standards in August 2024:

Also in development is:

In March 2025, NIST selected HQC as a fifth key encapsulation mechanism, providing a non-lattice alternative to ML-KEM, with draft publication expected in 2026 and finalization by 2027. This diversification matters: if a breakthrough weakens lattice-based assumptions, having alternatives from different mathematical families provides defence in depth.

The NSA's CNSA 2.0 suite is where the mandate lives. Published in September 2022 and updated in 2024, CNSA 2.0 specifies exactly which algorithms National Security Systems must use and by when. It is prescriptive where NIST is descriptive.

The most consequential near-term date is 1 January 2027, when all new acquisitions for National Security Systems must be CNSA 2.0 compliant by default. This is a procurement deadline, not a technical one. Vendors who cannot demonstrate PQC support in their products will be excluded from government contracts. That pressure is already cascading down the defence and critical infrastructure supply chains.

For civilian federal agencies, National Security Memorandum 10 (May 2022) and OMB Memorandum M-23-02 (November 2022) required agencies to inventory their cryptographic systems by May 2023 and then update those inventories annually until 2035. NIST IR 8547, published in draft in late 2024, recommends deprecating quantum-vulnerable algorithms by 2030 and disallowing them entirely by 2035.

United Kingdom: The NCSC Three-Phase Roadmap

In the UK, NCSC published its timelines for migration to post-quantum cryptography in March 2025. Unlike the US approach, which is heavily weighted toward national security systems, the UK guidance is explicitly sector-agnostic. It applies to government, critical national infrastructure, regulated industries, and by extension their supply chains.

The NCSC's three-phase roadmap is:

The NCSC has stated that "the severity of quantum risk facing the UK is being widely underestimated" and that organisations must assume sensitive encrypted data is already being harvested for future decryption.

Regulatory reinforcement is already in place. The Digital Operational Resilience Act (DORA), in force from January 2025, requires financial entities to demonstrate cryptographic resilience and the ability to adapt to emerging threats. Articles 6 and 7 require robust ICT risk management, including encryption governance and key lifecycle management, creating strong pressure toward crypto-agility. NIS2, effective from October 2024, extends similar expectations across eighteen critical sectors. The UK Cyber Security and Resilience Bill, currently progressing through Parliament, will further strengthen sectoral regulators' powers to mandate specific security standards.

The NCSC has also launched an assured PQC consultancy scheme, on-boarding its first providers in 2025. This signals that the centre expects demand for migration expertise to outstrip supply - a familiar pattern in regulated cybersecurity transitions.

European Union: Coordinated but Decentralised

The EU's approach is built on coordination rather than central command. Cryptographic algorithm selection remains a national competency, but the European Commission is harmonising timelines and expectations across member states.

April 2024: The European Commission issued Recommendation (EU) 2024/1101, calling on member states to develop coordinated transition roadmaps.

June 2025: The NIS Cooperation Group published the Coordinated Implementation Roadmap for PQC, setting three EU-wide milestones:

ENISA's role is technical and advisory rather than regulatory. In May 2025, ENISA published version 2 of its Agreed Cryptographic Algorithms guidance through the European Cybersecurity Certification Group, adding post-quantum mechanisms for the first time. The guidance recommends hybrid schemes - combining classical algorithms like X25519 with PQC like ML-KEM - as the preferred migration approach, providing protection against both classical and quantum adversaries while the newer algorithms mature in production.

ETSI has published the technical standards that will underpin EU compliance: TS 103 744 and related specifications define how PQC algorithms integrate into TLS, IKEv2, and other protocols. The revised eIDAS Regulation is expected to accelerate adoption of quantum-safe cryptography in EU digital identity and electronic signature infrastructure.

National divergence persists. France's ANSSI recommends phased PQC adoption beginning immediately with a preference for hybrid schemes. Germany's BSI supports hybrids but partially differs on algorithm selection. Czechia's NUKIB has set a national goal of PQC readiness by 2027 for sensitive critical infrastructure data. Eighteen EU national cybersecurity agencies issued a joint statement in November 2024 identifying PQC migration as a top priority. The direction is consistent even if the pace varies.

Where PQC Algorithms Need to Be Available

The regulatory timelines are clear. What they mean in practice is less obvious. Post-quantum cryptography does not replace one piece of software and declare victory. It needs to be available everywhere classical public-key cryptography currently operates.

TLS and Web Infrastructure

Every HTTPS endpoint - public websites, APIs, internal services, load balancers - negotiates its cryptography during the TLS handshake. To support PQC, both client and server must offer and accept post-quantum key exchange groups. Cloudflare, Google, and Amazon Web Services have already deployed hybrid X25519/Kyber support across their edge networks. The question for most organisations is not whether their cloud provider supports PQC, but whether their own origin servers, load balancers, and reverse proxies do.

The IETF is finalising standards for PQC in TLS 1.3, with completion expected around 2027. Until then, hybrid schemes - where a classical ECDH key exchange is combined with a PQC KEM - provide the safest migration path. If the PQC algorithm fails, the classical exchange still protects the session. If the classical algorithm is later broken, the PQC component protects against retrospective decryption.

SSH and Remote Access

SSH keys are often the longest-lived cryptographic material in an organisation. Many businesses still use RSA-2048 host keys generated years ago. The SSH protocol supports algorithm negotiation, but both client and server must be updated to recognise post-quantum algorithms. OpenSSH has added hybrid PQC support, but adoption of recent versions across enterprise environments is patchy.

VPNs and Network Encryption

IPSec IKEv2, WireGuard, and OpenVPN all rely on public-key cryptography for initial key establishment. The IETF has defined hybrid key exchanges for IKEv2, and the Open Quantum Safe project provides PQC-enabled versions of strongSwan and OpenVPN. For organisations with site-to-site VPNs, remote worker access, or SD-WAN deployments, every tunnel endpoint needs to be assessed and potentially upgraded.

Code and Document Signing

This is where the earliest regulatory pressure is concentrated. The NSA's CNSA 2.0 timeline requires all software and firmware signing to use post-quantum algorithms exclusively by 2030. For technology vendors, this is not a distant concern. Code signing certificates issued today with RSA or ECDSA will need to be re-issued with ML-DSA or SLH-DSA before that deadline. For organisations that sign their own software, firmware, or container images, the same transition applies.

Document signing, email S/MIME certificates, and timestamping services face similar deadlines. The eIDAS Regulation's 2027 requirement for quantum-safe digital identity infrastructure will accelerate demand for PQC-enabled certificate authorities and trust services.

Encrypted Storage and Backup

Data at rest encrypted with RSA-wrapped keys or ECC-derived keys is vulnerable to harvest-now-decrypt-later attacks. This includes encrypted databases, file shares, backup archives, and tape libraries. The migration challenge here is not just algorithm replacement but key re-encryption: every encrypted object needs to be decrypted with the old key and re-encrypted with a post-quantum key. For organisations with petabytes of archival data, this is a multi-year project in itself.

IoT and Embedded Devices

Perhaps the hardest challenge. IoT devices with ten-to-twenty-year operational lifespans - smart meters, industrial sensors, medical implants, automotive ECUs - were designed with firmware update mechanisms that assume classical cryptography. Many cannot be field-upgraded to support new algorithms, and their constrained processors may not have the computational capacity to run lattice-based schemes efficiently. The NCSC's roadmap acknowledges that "some rarely-used technologies might be harder to upgrade by this deadline," which is regulatory understatement for "some devices will need to be replaced."

Internal PKI and Certificate Authorities

Organisations running internal PKI - whether Microsoft Active Directory Certificate Services, OpenSSL-based CAs, or commercial private CA products - face a fundamental migration. The CA's signing key, the end-entity certificates it issues, the certificate revocation lists, and the Online Certificate Status Protocol responders all need to transition. The NCSC recommends creating a new PQC root of trust and cross-signing with the legacy root during transition, allowing gradual migration without a catastrophic flag day.

How Enforcement Will Work

The regulatory picture is complex because no single statute says "thou shalt use ML-KEM." Instead, enforcement is emerging through multiple channels that converge on the same outcome.

Procurement Rules

The most immediate enforcement mechanism is procurement. The NSA's 1 January 2027 deadline for CNSA 2.0-compliant new acquisitions means that from that date, any product or service sold into US national security systems must support PQC. This is already affecting RFP requirements. Vendors bidding for UK government contracts are seeing PQC readiness questions in security questionnaires. The EU's Cyber Resilience Act, applying from 2027, will impose security requirements on connected products that ENISA has explicitly mapped to PQC readiness.

For organisations that sell into government, defence, critical infrastructure, or financial services, PQC support is becoming a competitive requirement. Those that cannot demonstrate it will lose bids before any regulator issues a penalty.

Sector Regulator Pressure

In the UK, the Cyber Security and Resilience Bill will give sector regulators - Ofcom, Ofgem, the Bank of England, the FCA, and others - explicit powers to mandate security standards. The NCSC's PQC roadmap is guidance today; it becomes enforceable as soon as a regulator incorporates it into a statutory code of practice. The Bill's penalty structure - up to £17 million or 4% of global turnover for higher breaches - provides meaningful leverage.

In the EU, NIS2 requires "state-of-the-art" security measures for operators of essential and important services. As ENISA's guidance evolves, what counts as "state-of-the-art" will progressively include PQC readiness. DORA's explicit crypto-agility requirements for financial services create a direct line from regulatory examination to algorithm migration.

Supply Chain Flow-Down

The most powerful enforcement mechanism may be indirect. When a major bank or energy company is required to demonstrate PQC readiness, it will require the same from its suppliers. Those suppliers will require it from their suppliers. The M&S and JLR supply chain breaches demonstrated how regulatory pressure on critical infrastructure operators cascades through multiple tiers of subcontractors and service providers. PQC will follow the same pattern.

Director and Officer Liability

While no current UK or EU statute creates personal criminal liability for failure to migrate to PQC, the direction of travel is clear. The UK Bill's CAF alignment requirement embeds accountability at board level. DORA requires financial institution boards to approve and review operational resilience arrangements. GDPR Article 32 requires "appropriate" security measures, and as quantum threats become more tangible, failure to address them could be interpreted as a failure of duty. The German BSI has already stated that organisations handling sensitive long-term data have a "special responsibility" to begin PQC migration now.

Insurance and Litigation

Cyber insurance underwriters are beginning to ask about PQC readiness in renewal questionnaires. The first litigation testing whether failure to migrate constitutes negligence is probably five to ten years away, but the legal theory is straightforward: if an organisation knew that RSA and ECC were vulnerable to quantum attack, had regulatory guidance to migrate, and failed to do so, a court may find that failure constituted a breach of duty of care.

The Discovery Problem

Every roadmap - US, UK, and EU - begins with the same instruction: discover what cryptography you are using. This sounds straightforward. It is not.

Most organisations cannot produce a complete inventory of their cryptographic dependencies. They know where their TLS certificates live because certificate management tools tell them. They often do not know:

The discovery problem is compounded by shadow IT, M&A legacy systems, and the proliferation of microservices that each negotiate their own cryptography. A typical enterprise may have thousands of TLS endpoints, hundreds of SSH servers, dozens of VPN gateways, and an unknown number of embedded cryptographic libraries in applications developed over decades.

This is where automated discovery becomes essential. Manual assessment at scale is impractical, and the timelines do not permit it.

A Tool for Rapid Discovery

We have published a set of open-source tooling that help to the discovery problem directly. pqc is a command-line scanner and monitoring agent that probes TLS, SSH, and VPN endpoints to determine whether they support post-quantum cryptographic algorithms. It is designed for security teams that need fast, automated visibility into their cryptographic estate without requiring credentials or disrupting services.

The scanner probes an endpoint, enumerates the algorithms it offers, and reports a binary verdict:

Installation on MacOS is through Homebrew:

brew tap The-CISO-Network/pqc
brew install pqc

Scanning a single endpoint takes seconds:

pqc scan example.com 443
pqc scan bastion.internal 22 --protocol ssh
pqc scan vpn.example.com 500

The agent mode watches active connections and proactively scans observed endpoints, logging results for ingestion into SIEM or GRC platforms. The probe is independent of the observed connection - it opens its own socket to enumerate algorithms without intercepting traffic.

For organisations beginning their NCSC-recommended discovery phase, tools like this provide the raw data that feeds into migration planning. You cannot prioritise what you have not found. You cannot budget for what you have not assessed. And you cannot report compliance to regulators without evidence.

The tool uses only Python's standard library by default, with optional dependencies for deeper TLS enumeration through sslyze and richer SSH probing through asyncssh. It aims to track the NIST current and emerging algorithm suite: ML-KEM, ML-DSA, SLH-DSA, FN-DSA, and hybrid combinations that will dominate production deployments during transition.

Practical Preparation: What to Do Now

Regardless of your jurisdiction or sector, the following actions are defensible and proportionate.

1. Start the Cryptographic Inventory

Use automated scanning tools to map every TLS, SSH, and VPN endpoint in your estate. Include cloud services, SaaS providers, and third-party connections. The inventory should record not just what algorithms are in use, but what protocols, what software versions, and what hardware dependencies exist. The NCSC's 2028 discovery deadline is closer than it appears for organisations with complex estates.

2. Assess Data Sensitivity and Lifespan

Not all data requires immediate migration. Use Mosca's inequality as a heuristic: if the sum of your data's required confidentiality lifespan plus your migration time exceeds the estimated time until quantum capability, you have a problem. Medical records, classified communications, financial instruments with long maturities, and intellectual property all have confidentiality requirements that extend well into the 2030s. Marketing analytics from last quarter do not.

3. Engage Your Supply Chain

Ask your critical vendors for their PQC roadmaps. When will their products support ML-KEM and ML-DSA? What is their hybrid deployment strategy? Will they provide crypto-agile updates that allow algorithm rotation without hardware replacement? The answers will determine whether you can meet regulatory timelines or whether your vendors become your constraint.

4. Pilot Hybrid Cryptography

For high-priority systems, deploy hybrid schemes now. Cloudflare's experience demonstrates that X25519/Kyber hybrid key exchange adds minimal latency and provides immediate protection against harvest-now-decrypt-later. Piloting builds operational experience, validates interoperability, and generates the metrics that regulators will expect to see.

5. Build Crypto-Agility

The NCSC, ENISA, and NIST all emphasise crypto-agility: the ability to swap algorithms without redesigning systems. This means abstracting cryptographic operations behind standardised APIs, avoiding hard-coded algorithm assumptions, and designing key management systems that can handle multiple algorithm families. The organisations that will handle the 2030s transition smoothly are those that build agility now, not those that hard-code ML-KEM as the new RSA.

6. Update Incident Response and Governance

Boards and regulators will increasingly ask about PQC readiness. Ensure your risk register includes quantum risk, your audit committee receives regular updates on migration progress, and your incident response plans account for the possibility of a cryptanalytic breakthrough that accelerates timelines.

The Bottom Line

Post-quantum cryptography is not a future problem. It is a present planning problem with future consequences. The standards are final, the timelines are published, and the regulatory machinery is moving. The organisations that will handle this transition well are those that treat it as a multi-year infrastructure programme rather than a last-minute compliance exercise.

The discovery phase is where every organisation must start. You cannot migrate what you cannot find. Automated tools accelerate that discovery, but they do not replace the governance, budgeting, and vendor management that must follow. The NCSC's 2028 deadline for completing discovery and planning is less than three years away. For complex enterprises, that is barely enough time to map the estate, let alone migrate it.

The question is no longer whether to prepare for post-quantum cryptography. It is whether you will control the timeline or be controlled by it.

References