Security in the Post-Quantum Era, What Changes Once the Migration Is Done

Post-quantum security arrives in most organisations as a configuration change that nobody notices. A browser update turns on a new key exchange. A certificate renews with a larger key, and the security team finds that the page loads exactly as it did the day before. That quiet result is the whole point of the migration, and it hides both how much has changed underneath and how much has stayed the same.

This guide is written for the security lead at a mid-sized organisation who has read the migration plan and wants to know what the job looks like afterwards. It covers what changes when the new algorithms go in, what does not, which new risks arrive with the new code, and how the programme is run while the standards keep moving. Two things are left out. The mathematics of the threat, and the question of when a capable quantum computer might exist, are covered in our guide to Q-Day.

Post-quantum security is neither a product nor a date, but a set of new algorithms with larger keys and a handshake that carries two kilobytes more. It is also an inventory that has to stay current, and a small number of habits that a security team keeps for a decade.

The keys grow up to forty times and the handshake grows by two kilobytes

The visible change in post-quantum security is size. The three standards NIST published on 13 August 2024 replace two families of public-key arithmetic with new ones built on different mathematics. ML-KEM in FIPS 203 is a key encapsulation mechanism, the algorithm that agrees a shared secret, and it takes over from X25519 and RSA. ML-DSA in FIPS 204 and SLH-DSA in FIPS 205 are signature schemes, which prove who produced a message, and they take over from RSA and ECDSA. Our guide to post-quantum cryptography works through what each one is and how it was chosen, so this guide starts where that one ends.

The sizes follow from the mathematics. FIPS 203 sets the ML-KEM-768 encapsulation key, the public half, at 1,184 bytes, against 32 bytes for an X25519 share. A 2,048-bit RSA modulus is 256 bytes, so the new key is between five and forty times the old one. Signatures grow the same way, against the 64 bytes an ECDSA P-256 signature takes. SLH-DSA is the outlier. Its public key is the smallest of the new ones and its signature is by far the largest.

In a TLS handshake, the exchange that opens every HTTPS connection, the hybrid group X25519MLKEM768 puts both the old and the new algorithm on the wire. RFC 10024, published as a Proposed Standard in August 2026, sets the client’s share at 1,216 bytes and the server’s at 1,120. The key exchange now costs 2,336 bytes where X25519 alone cost 64. That is the whole price of post-quantum security for encryption in transit, and it is a price that fits inside a single round trip on almost every network.

Signatures are the heavier half, and the reason is the certificate chain. A TLS server presents its own certificate plus the intermediate and root certificates that vouch for it, and each link carries a public key and a signature. Cloudflare’s engineers calculated in November 2024 that moving a typical chain to ML-DSA-44 adds 14.7 kilobytes to the handshake. Their 2025 review put the median chain today at 3.2 kilobytes, so the post-quantum chain would be roughly five times larger. The same measurements found that adding under 9 kilobytes slows the handshake by about 15 per cent, and that above 10 kilobytes client and middlebox failures rise steeply. Middleboxes are the firewalls and inspection appliances that sit in the path.

Hardware support has moved faster than the certificate standards

An HSM, a hardware security module, is the tamper-resistant box that holds an organisation’s most valuable private keys, and the cloud versions already sign with the new algorithms. AWS Key Management Service lists ML_DSA_44, ML_DSA_65 and ML_DSA_87 key specifications, and AWS CloudHSM offers ML-DSA key generation and signing to applications. Google Cloud KMS offers ML-DSA-65 and SLH-DSA-SHA2-128s at both its software and its HSM protection levels. That covers signing. Neither AWS page listed ML-KEM as a managed key type when they were checked in September 2026. On that platform the encryption side still runs in software libraries rather than inside the box.

Those libraries have arrived too. Windows 11 version 24H2 added ML-KEM and ML-DSA to the operating system’s cryptography interface, while its hash-based SLH-DSA, LMS and XMSS identifiers are documented as not currently implemented by the default provider. OpenSSL 3.5, released on 8 April 2025 as a long-term release supported until 8 April 2030, ships all three NIST standards, and JDK 24 implements ML-KEM. Physical HSM firmware is a vendor-by-vendor question, and it is the first item on the vendor list later in this guide.

AES-256 stays, SHA-2 stays, and so do phishing and misconfiguration

The algorithms that encrypt the data itself do not change. Public-key cryptography does only two jobs. It agrees the key and it proves identity. The bulk of the work is done by a symmetric cipher, one where both sides hold the same key, and those are barely dented by a quantum computer. NIST’s transition report, IR 8547, defines its security categories by what it would take to break a block cipher or a hash. It places AES-128 in category one, AES-256 in category five, the highest, and a collision search on SHA-256 in category two.

The NCSC says the same thing in plainer words. Its post-quantum guidance states that the security of symmetric cryptography is not significantly impacted by quantum computers. Existing symmetric algorithms with at least 128-bit keys, such as AES, can continue to be used. The NSA’s CNSA 2.0 suite, the algorithm list for United States national security systems, keeps AES with 256-bit keys for all classification levels and keeps SHA-384. A post-quantum security programme that spends money replacing AES or SHA-2 has misread its own standards.

Phishing and misconfiguration do not care which key exchange you run

The breaches do not change either. Verizon’s 2025 Data Breach Investigations Report analysed 12,195 confirmed breaches and found the human element in roughly 60 per cent of them. Third-party involvement doubled from 15 to 30 per cent. Exploitation of vulnerabilities opened 20 per cent of breaches, still behind credential abuse as the most common way in. None of those routes runs through a broken public key. A quantum computer able to factor RSA-2048 does nothing to a phished password, an unpatched VPN appliance or a storage bucket left open to the world.

Post-quantum security changes one control among many. The rest of the stack is exactly as exposed as it was. The NSA’s CNSA 2.0 questions and answers, revised in December 2024, put it from the cryptographer’s side. More security products fail because of implementation or configuration errors than because of failures in the underlying algorithms.

Hybrid key exchange already protects most browser traffic

The most widely deployed piece of post-quantum security is X25519MLKEM768. It is a hybrid key exchange that runs the old elliptic-curve agreement and the new ML-KEM-768 side by side and mixes both results into the session key. RFC 9954, the IETF’s hybrid design document published in July 2026, states the property that makes this worthwhile. “The resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken”, it says.

ML-KEM’s security rests on lattice problems, which are questions about points arranged in a grid across many dimensions. If a flaw in lattice mathematics were found tomorrow the connection would still be as safe as it was in 2023, and if a quantum computer arrives it is as safe as ML-KEM alone.

Google turned it on for everyone, enabling the draft Kyber hybrid by default for TLS 1.3 and QUIC on all desktop Chrome platforms as of Chrome 124, as it wrote in May 2024. “This rollout revealed a number of previously-existing bugs in several TLS middlebox products”, the team added. In September 2024 it announced the switch from the draft to the final ML-KEM in Chrome 131, under the new code point 0x11EC, the number the two ends use to name the algorithm.

Apple followed on devices running iOS 26 and iPadOS 26, where TLS 1.3 with the X25519MLKEM768 key exchange is enabled by default. That covers URLSession and the Network framework, the interfaces Apple software uses to open a connection. On the server side, OpenSSL 3.5 changed its default key shares to offer X25519MLKEM768 and X25519.

The browser end is protected far more often than the origin end

The effect shows up in traffic that a content network can count. Cloudflare reported around 43 per cent of human-generated connections on hybrid post-quantum protection in mid-September 2025 and over half by late October 2025. By February 2026 it was over 60 per cent of HTTPS requests, against under 3 per cent in January 2024, and by June 2026 over two-thirds of browser traffic to its network. Each of those figures counts a slightly different population, so read them as a direction rather than one series.

The other end of the connection lags well behind. Fewer than 1 per cent of origin servers supported post-quantum key exchange in January 2025 and about 10 per cent did a year later. The browser-to-edge hop is therefore protected far more often than the edge-to-origin hop that carries the same data onward.

The agencies treat hybrid as a bridge rather than a destination. The NCSC recommends that a hybrid scheme, if chosen, is used as an interim measure, and it notes that such schemes are more complex to maintain and less efficient. NIST’s IR 8547 says hybrid solutions are typically expected to be temporary measures that lead to a second transition to post-quantum algorithms alone. The NSA goes further. It has confidence in the CNSA 2.0 algorithms and will not require hybrid products for security purposes, though product availability and interoperability may lead to adopting them. A programme that deploys hybrid today should already have a line in its plan for switching the classical half off.

The new algorithms have already had their first bugs

New code ships with new mistakes. The first ones are already documented. KyberSlash, disclosed by Daniel Bernstein and colleagues, is a family of timing leaks in Kyber implementations, Kyber being the name ML-KEM carried before standardisation. A line of code divides a secret numerator by a public denominator. The processor takes a different number of cycles depending on the inputs, and that variation falls within the range of values the libraries actually use. This is a side channel, a leak of secret information through something an attacker can measure rather than through the mathematics itself.

The project’s library tracker records patches in liboqs, Botan, AWS-LC, Cloudflare’s CIRCL, PQClean and pqm4 between December 2023 and September 2024. It also records a downstream fix in Signal on 5 January 2024. As of 22 August 2025 it still listed two libraries with unpatched secret-dependent divisions. For a security lead the lesson is not that lattice cryptography is fragile. It is that the ML-KEM inside a product is a specific library at a specific version, and that version belongs in the patch cycle like any other dependency.

NIST anticipated this in Special Publication 800-227, its recommendations for key encapsulation mechanisms finalised in September 2025, which separates three conditions that all have to hold. The algorithm must be mathematically secure, the code must be written securely and the product must be deployed securely. The document says each of the three is essential. It also notes that validation tests only input and output behaviour. Some implementations focus on efficiency while others employ side-channel and leakage protection, so a validated module may be either kind and the certificate will not say which.

A hybrid negotiation can be steered downward

Hybrid deployments add a negotiation. A negotiation is something an attacker or a misconfiguration can influence. RFC 9954 describes what happens when a hybrid-aware client meets a server that is not. Those two “should establish a non-hybrid shared secret (assuming the hybrid-aware client is willing to downgrade to non-hybrid-only)”, in the document’s words. That willingness is a configuration choice, and a fleet that permits it silently will report post-quantum security coverage it does not have. The NSA’s FAQ lists the same hazard in plainer terms. Hybrid solutions add complexity because designers must add negotiation and error handling, and one must balance the risk of flaws in a more complex implementation against the risk that someone breaks the mathematics.

The third new risk is the library supply chain. A mid-sized organisation writes almost none of its own cryptography. It inherits it through OpenSSL, the JDK, the operating system and whichever language runtimes its developers favour. The post-quantum versions of all of those are young. OpenSSL 3.5 is the first long-term release to carry ML-KEM, ML-DSA and SLH-DSA, and Windows added the two lattice algorithms only in version 24H2. Chrome’s 2024 rollout broke middleboxes that had never seen an opening message that large, and the next such failure will come from a device nobody listed. That is why the inventory in the operating section below is the control that makes every other post-quantum security control possible.

Certificates and firmware signing are the unfinished half

Post-quantum security for key exchange is done, but for signatures it is not, and the reason is the size arithmetic above. A browser can absorb a two-kilobyte key share. A certificate chain five times its current size crosses the threshold at which handshakes start to fail, so the public web has not simply switched. The IETF published RFC 9881 in October 2025, the conventions for carrying ML-DSA keys and signatures in X.509 certificates, the standard format that ties a public key to a name. Cloudflare began accepting ML-DSA certificates on its own connections to customer origin servers in July 2026, where both ends are under one operator’s control and the extra bytes are tolerable.

For the public web the plan is a different certificate format. Merkle Tree Certificates, introduced by Cloudflare with Chrome in October 2025, batch many certificates into a tree so that a browser verifies a short proof instead of a chain of large signatures. Cloudflare’s April 2026 roadmap targets mid-2027 for post-quantum authentication to visitors using that format and 2029 for full post-quantum security including authentication. As of September 2026 a public TLS certificate with a post-quantum signature is not something you can buy for a website. Pressing a certificate authority to supply one is effort spent in the wrong place.

Automating renewal now is what makes the algorithm swap cheap later

What is changing on certificates now is the lifetime. It has nothing to do with quantum computers. The CA/Browser Forum’s baseline requirements, at version 2.2.9 of 6 August 2026, cut the maximum validity of a public TLS certificate to 200 days from 15 March 2026. That falls to 100 days from 15 March 2027 and 47 days from 15 March 2029. That schedule forces certificate automation years before post-quantum certificates exist. An organisation that automates renewal now will swap algorithms with a configuration change when the format settles, and one that still renews by hand will be doing it every six weeks by 2029.

Firmware and software signing are the exception. Post-quantum signatures are already advised there. A signature on a firmware image must still verify in fifteen years, when the device is still bolted into a cabinet. That is why the NCSC recommends SLH-DSA, LMS and XMSS for signing firmware and software, the hash-based schemes whose security rests only on the hash function. The NSA says firmware roots of trust are a critical component to upgrade and prefers to see that transition begin now using LMS and XMSS rather than wait for validated ML-DSA. The cost is signature size, which a bootloader can afford and a TLS handshake cannot.

Five timetables shape the programme and none of them is yours

An organisation’s own estimate of when a capable quantum computer arrives changes little in practice, because the dates a post-quantum security programme answers to were set elsewhere. Five timetables matter here, and six documents fix them. NIST’s IR 8547, still an initial public draft dated November 2024, deprecates quantum-vulnerable public-key algorithms at the 112-bit security strength after 2030 and disallows them after 2035. RSA-2048 sits at that strength. The NCSC’s migration timelines, published on 20 March 2025, ask organisations to define goals, complete discovery and build an initial plan by 2028. Highest-priority migration follows by 2031 and everything else by 2035.

Deprecated does not mean banned, and someone signs for the difference

NIST’s vocabulary matters more than its dates. Deprecated means the algorithm and key length may be used, but with a security risk that the data owner must examine and accept. Disallowed means the algorithm is no longer allowed for the stated purpose. The five years between 2030 and 2035 are therefore not a grace period but a period of documented risk acceptance, and someone senior signs it every year.

The document also separates the two halves of the job. An authentication system remains secure as long as the algorithms and keys are secure when the authentication is performed, unlike encryption, which faces harvest now, decrypt later. An attacker stores the traffic today and reads it once the machine exists. Signatures may therefore be transitioned later than key establishment.

The United States national security timetable runs earlier. The NSA’s CNSA 2.0 FAQ sets three dates under CNSSP 15, the updated policy that binds those systems, and the first of them, for new acquisitions, falls on 1 January 2027. For civilian agencies, OMB Memorandum M-26-15 of 24 June 2026 requires a prioritised migration mitigating as much quantum risk as feasible by 31 December 2030. It also requires a migration plan within 120 days.

The European Union set its own three steps in the coordinated implementation roadmap dated 11 June 2025. Member states should have initial national transition roadmaps by 31 December 2026. High-risk use cases should be migrated no later than the end of 2030, and by 2035 the transition should be completed for as many systems as practically feasible. The roadmap says its 2035 date was chosen to align with NIST’s disallowance and the NCSC’s target, so a multinational organisation faces one end date and three different paths to it.

QKD does not fit, and both national agencies say so

Quantum key distribution, or QKD, uses the physics of single photons over a dedicated optical link to share a key between two points in a way that reveals any eavesdropper. It is sold into post-quantum security conversations because it has the word quantum in it. The two agencies with the most to lose have both written down why it does not belong there. The NSA’s FAQ says the sole function of QKD is to distribute keys between users. That is only one part of a cryptographic system. The agency does not generally consider QKD a practical security solution for protecting national security systems.

QKD cannot prove who is at the other end of the link

The NCSC’s quantum security technologies paper, dated 5 August 2025, gives the mechanism. QKD does not provide authentication, so it cannot prove who it is talking to. Nor can any other quantum technique. It must be combined with other cryptographic services to give any protection against an active attacker. The NCSC will not support the use of QKD for government or military applications, and for other sectors it recommends that QKD should not be solely relied upon for generating and distributing keys. It adds that the use of QKD systems should not constitute evidence towards assessments of the security of data in transit under its Cyber Assessment Framework.

Where QKD does fit is narrow and the NCSC describes it. Systems built only on symmetric-key authentication with pre-shared keys can use QKD in some controlled environments. Such systems are not general purpose. Distributing and managing those pre-shared keys is the hard part. Cloudflare’s engineering team reached the same conclusion from the other direction. Its post arguing that you do not need quantum hardware for post-quantum security notes that post-quantum cryptography already runs on existing hardware and works everywhere. A security lead who is offered a QKD link should ask what authenticates it, and the answer will usually be the post-quantum algorithms they already have.

Crypto-agility is the operating model because the standards are still moving

The NCSC’s timeline guidance asks organisations to seek products that offer cryptographic agility, which it defines as the ability to readily support alternative suites of cryptographic algorithms. That is easy to write into a procurement and hard to mean. It has to be meant, because the standards are not finished. On 11 March 2025 NIST selected HQC as a backup to ML-KEM, chosen because it rests on error-correcting codes rather than lattices. A draft standard was expected in about a year and a final one in 2027. FN-DSA, a further signature scheme intended as FIPS 206, is not listed in any status on NIST’s FIPS publications page as of 5 September 2026. Nor is a draft for HQC.

New algorithms keep arriving on a schedule nobody controls

The signature side is moving too. On 14 May 2026 NIST advanced nine candidates to the third round of its process for additional signature schemes, documented in IR 8610. In April 2026 it opened a draft of SP 800-230 proposing further SLH-DSA parameter sets for limited-use cases. The NSA, for its part, says it does not currently plan to add future NIST post-quantum standards to CNSA 2.0, because more algorithms make interoperability more complex. Between those two positions sits every mid-sized organisation. It will be handed new algorithms by its vendors on a schedule it does not control.

Agility therefore means four concrete things. The algorithm and parameter set are named in configuration and not compiled into code. M-26-15 instructs federal agencies to do exactly that, saying the choice of algorithm or hybrid scheme must be specified in external configuration files. Key and signature sizes are treated as variables everywhere a database column, a message format or a hardware buffer was sized for 32 or 256 bytes. Certificate profiles are versioned so that an ML-DSA profile can sit beside an ECDSA one. And the contract with each vendor states how algorithm changes will be delivered and at what cost. Hybrid already implies a second transition, and the backup standards will bring a third.

The operating picture runs from inventory to what you watch

Post-quantum security in operation reduces to a small number of standing tasks. The first is the one the NCSC says takes longest. Any technical system migration needs to start with a clear understanding of the current estate, and the agency expects large organisations to spend two to three years on discovery and assessment alone. The output is a cryptographic bill of materials, or CBOM, a list of every place a key, a certificate or an algorithm appears. M-26-15 describes how to feed it. Tools that read a software bill of materials, scanners that find cryptographic calls in code and network scanners that spot protocols and cipher suites all report into it. Automation keeps it current wherever possible.

Key management changes in size before it changes in kind

The second standing task is key management. The change there is one of size. An ML-KEM-768 decapsulation key, the private half, is 2,400 bytes, and an ML-DSA-65 private key is 4,032 bytes. A key store, a secrets manager or a database column may have been sized for 32-byte elliptic-curve secrets. The parameter set is the first decision to write down. The NCSC recommends ML-KEM-768 and ML-DSA-65 as providing appropriate security and efficiency for most use cases. CNSA 2.0 requires ML-KEM-1024 and ML-DSA-87 for national security systems, so an organisation that supplies both markets needs both profiles. Cloud key services already hold ML-DSA keys behind their HSM boundaries, so the practical question is whether the organisation’s own HSM firmware does.

Certificates are the third task, and the calendar for that one is already fixed. Public TLS certificates go to 47 days in March 2029 whatever happens to post-quantum signatures, so the renewal pipeline is automated first and the algorithm is changed later. An internal certificate authority, where the organisation controls both ends, can move sooner. Firmware signing moves first of all, on to LMS, XMSS or SLH-DSA, because a device signed today with RSA will be verifying that signature long after 2035.

Eight questions for every vendor and what a credible answer contains

Five things to monitor once the switch is thrown

Monitoring is where post-quantum security becomes a routine rather than a project. Five measures cover most of it. The first is the share of TLS sessions that negotiated X25519MLKEM768 rather than falling back to X25519, measured per service and per client population, because a falling share is the downgrade risk made visible. The second is the handshake failure rate in the weeks after any change, since Chrome’s rollout showed that middleboxes fail on an oversized ClientHello, the first message a browser sends. The third is certificate chain size and expiry, which matters more as lifetimes fall to 47 days.

The fourth is the version of every post-quantum library in the inventory against the advisories that name them, because KyberSlash was fixed library by library over nine months. The fifth is the standards themselves. NIST’s FIPS page will one day list FIPS 206 and a standard for HQC, and IR 8547 will move from draft to final. Each of those events changes what vendors ship and what auditors ask. A security lead who checks those five measures quarterly is running post-quantum security rather than waiting for it, and the rest of the job looks reassuringly like the job before.

Common questions about post-quantum security

Contains public sector information licensed under the Open Government Licence v3.0.