Choosing Post-Quantum Algorithms, And Whether To Run Them Alongside The Old Ones

The algorithm standards are finished, so the hard part of the post-quantum migration is no longer which mathematics to trust. It is two engineering choices the standards deliberately leave open, and on one of them the national cryptographic authorities contradict each other. France has made running a post-quantum algorithm alongside a classical one obligatory inside its regulated scope. The NSA tells American national security systems to avoid doing it.

Which post-quantum algorithms to pick is close to decided, and the NCSC will name them for you. Whether to run the new one beside the one it replaces is not decided at all. That is the choice that determines whether you budget for this migration once or twice.

Which algorithm to use is settled, whether to run two is not

The choice of algorithm is the decision everybody writes about and the one that matters least, because the standards bodies have already done the work. The second is the one that will cost real money, because getting it wrong means doing the migration twice.

This guide follows the NCSC’s guidance on choosing post-quantum algorithms, which is the clearest public statement of the choice, and then does the thing that paper cannot do: set it beside what the other agencies say. For what post-quantum cryptography is in the first place, see our plain English guide.

The NCSC names ML-KEM-768 and ML-DSA-65 for most use cases

For general purpose work the field of post-quantum algorithms narrows to two, and the choice between them is a choice of job rather than of quality. ML-KEM, standardised as FIPS 203, agrees a shared secret over an open connection. ML-DSA, standardised as FIPS 204, signs things.

The NCSC goes further than naming the post-quantum algorithms and names the parameter sets. It recommends ML-KEM-768 and ML-DSA-65 as providing appropriate levels of security and efficiency for most use cases. That is a more useful recommendation than it sounds, because a parameter set is where the implementation decision really gets made.

Both rest on the same lattice mathematics, which is efficient and well studied and also means a single breakthrough would weaken both at once. That shared dependence is the reason the three hash-based algorithms in the next section exist. It is also the strongest argument the hybrid camp has.

Every parameter set is strong enough up to OFFICIAL, so the choice is about size

The instinct on meeting a list of parameter sets for the post-quantum algorithms is to reach for the largest, on the assumption that more is safer. The NCSC closes that off directly. All of the parameter sets, it says, provide an acceptable level of security for personal, enterprise and OFFICIAL-tier government information.

What separates them is cost rather than safety. Smaller parameter sets need less power and less bandwidth and carry a lower security margin, while larger ones want more processing power and more bandwidth and produce bigger keys and bigger signatures for the same job.

So the question is how long the thing has to last, not how much security you need today. The highest level earns its cost where keys are particularly long lived or protect data that must stay secret for a long time, which is the harvest now, decrypt later case, and for signatures where the key has a long lifetime, such as a root of trust. Everywhere else the middle set is the sensible default, which is exactly what the NCSC recommends.

One authority disagrees with that, which is worth knowing before you copy the NCSC’s numbers. The NSA’s CNSA 2.0 suite requires ML-KEM-1024 and ML-DSA-87 for all classification levels, so American national security systems take the largest sets as a floor rather than a considered choice. That is a scope difference rather than a dispute about the mathematics.

Firmware signing is the one job the general-purpose algorithms should not do

There is a category of signing where the general purpose post-quantum algorithms are the wrong answer, and it is the category that lasts longest. Firmware and software signatures may be verified years after they are made, by devices nobody can update, using a check burned into hardware.

For that job the NCSC points at three hash-based post-quantum algorithms: SLH-DSA under FIPS 205, and LMS and XMSS under NIST Special Publication 800-208. Hash-based signatures rest on different security assumptions from ML-DSA, so a break in the lattice assumption would not touch them.

They are not suitable for general purpose use, and the NCSC says so plainly, because the signatures are large and the schemes sign much more slowly than ML-DSA does. Where speed is not the bottleneck, which is precisely the firmware case, that trade is worth making.

LMS and XMSS remember which keys they have used, and forgetting is fatal

This is the part of the post-quantum algorithms guidance most coverage leaves out, and it is the part most likely to cause a real incident. LMS and XMSS are stateful. Their security critically depends on the user correctly managing that state, which means knowing which one-time keys have been used so that it can be guaranteed they are never used again.

Reuse a one-time key and the scheme does not degrade gracefully. It fails outright. That makes state a piece of security-critical infrastructure rather than a bookkeeping detail, and it has to survive backups, restores, crashes and hardware replacement for the whole lifetime of the signing key.

The NCSC’s rule is narrow on purpose. LMS and XMSS should only be used where it is possible to manage state in a trusted manner for the lifetime of the signing key. It points to ETSI Technical Report TR 103 692 for how to do it, and names firmware and software signing as cases where the problem is tractable, because the signing happens in one place under one team’s control.

SLH-DSA pays in bytes for not having to remember anything

SLH-DSA is the stateless alternative, and the trade is explicit. It holds up in exactly the situations where it may be difficult or impossible to guarantee that a one-time key is never reused, because it keeps no state and so has no state to lose.

That safety is bought with size and with signing time. An SLH-DSA signature starts at 7,856 bytes and runs to 49,856 depending on the parameter set, against 3,309 bytes for ML-DSA at the middle set and 64 bytes for the elliptic-curve signature it replaces. Verification performance is similar to LMS and XMSS; it is the signing that is slow.

The decision rule is therefore about your organisation rather than about cryptography. If you can guarantee state management for decades then LMS or XMSS are smaller and faster, and if you cannot, which is the honest answer for most systems that sign in more than one place, SLH-DSA is the one that fails safe.

A hybrid scheme runs two algorithms so one failure is survivable

A hybrid runs two algorithms where one would do. The literature calls it a PQ/T hybrid, and it pairs one or more post-quantum algorithms with one or more traditional ones of the same type. A post-quantum signature alongside a classical signature gives a hybrid signature. The same construction works for agreeing a key.

The appeal is easy to state. Suppose the lattice assumption turns out to be wrong. The classical half still stands, and if a new implementation carries a bug then the mature one behind it has had twenty years of attack to shake those out. You are betting only that the two will not fail at the same time.

The cost is just as easy to state, and it is usually understated. Hybrid schemes are more complex to implement and to maintain, and they are less efficient. You are running two cryptosystems where you used to run one, in every place you used to run one.

There are three good reasons to want a hybrid, and lasting security is not one

The NCSC gives three, and it is worth noticing what they have in common. The first is interoperability. A large network cannot switch in a single step, so there will be a long period where both the post-quantum and the traditional algorithms have to be supported at once. A flexible protocol carrying both lets systems on different policies talk.

The second is implementation security. The post-quantum algorithms have been through a thorough standards process. The code implementing them has not. Assurance in the implementations will take years to build, and running the new alongside the old aims at a system that stays secure even if one of them turns out to be broken.

The third is protocol constraints. Some protocols make it awkward to remove the traditional algorithm when adding the new one, and the NCSC’s example is the need to avoid IP layer fragmentation in IKEv2. All three reasons are about the transition rather than the destination, which is the whole argument in miniature.

Five national authorities, five different answers

No single agency’s guidance can tell you this, because each states only its own view. On whether to run a hybrid the major cryptographic authorities disagree, and they disagree across the whole available range, from one authority making it compulsory to another telling its own systems to steer clear of it. That is not a footnote to the choice.

France is at one end, and it is the only authority that has made the call binding. ANSSI’s position paper calls the role of hybridation “crucial and will be mandatory” for the first two phases of its transition. The 2023 follow-up hardens that into a requirement. A product that includes post-quantum mitigation shall implement hybridation, unless the mitigation rests only on hash-based signatures. Inside the regulated scope, which covers defence-classified and Diffusion Restreinte data, vital information systems and any product seeking an ANSSI security visa, hybridation is obligatory rather than advised. ANSSI is aiming to attach post-quantum obligations to product qualification from 2027.

The NSA is at the other end. Its CNSA 2.0 FAQ says it has confidence in the CNSA 2.0 algorithms. It will not require builders of national security systems to use hybrid certified products. It goes further and tells them not to run a hybrid or other non-standardised solution on mission systems, except for the exceptions it names itself to meet standardisation or interoperability requirements.

Germany recommends a hybrid and stops recommending classical-only after 2031

Germany sits between them and is moving. BSI’s Technical Guideline TR-02102-1, in the version dated 23 January 2026, says the recommended quantum-safe mechanisms should be used in hybrid form, in a suitable combination with a classical method. It is written as a recommendation rather than a requirement.

What gives it teeth is a date. The same guideline recommends the sole use of classical key agreement only until the end of 2031, and beyond that recommends those methods only in combination with a quantum-safe mechanism. After 2031, classical-only falls off the recommended list. Hybrid becomes the only recommended way to keep a classical algorithm in the stack at all.

NIST declines to take a side and expects a second transition anyway

The United States standards body writes no requirement at all. Its draft transition guidance leaves the call to each application, on whether it can afford the cost, the drop in performance and the extra engineering. NIST says it will accommodate hybrid modes in validation for anyone who wants them.

On the destination it lands where the NCSC does. It expects hybrid solutions to be temporary measures leading to a second transition, which is the same warning about paying for the migration twice, written by the body that standardised the algorithms.

Positions as published by each authority and read on 31 August 2026. All five documents are subject to revision. NIST IR 8547 remains an initial public draft; its comment period closed on 10 January 2025 and no final version has superseded it.

Your regulator decides, and hash-based signatures are exempt from the French rule

The spread on post-quantum algorithms is not a sign that the question is unsettled science. It is a difference of legal instrument and of risk appetite. ANSSI regulates it, BSI recommends it with a deadline attached, the NCSC treats it as a bridge worth crossing and then leaving, NIST stays neutral, and the NSA regards it as overhead its own systems should avoid.

For most organisations the answer follows from where you operate and who audits you, not from the cryptography. A French operator of vital importance is waiting on an updated reference document rather than making a choice, and hybridation will be in it when it lands. A supplier selling into Germany should assume hybrid past 2031. A vendor selling into United States national security systems should assume the opposite.

One class of organisation is caught between two of these positions rather than covered by one. A vendor selling the same product into a French security visa and into American national security systems is told by ANSSI to implement hybridation and by the NSA not to run a hybrid on mission systems. No single build satisfies both. The answer is two configurations of one codebase. That is the practical argument for keeping the algorithm choice in configuration rather than for either agency’s position.

One exemption is worth carrying, because it connects the two halves of this guide. ANSSI’s requirement carves out hash-based signatures: for XMSS, LMS and SLH-DSA, hybridation is optional. The reasoning is the same one that makes those algorithms right for firmware in the first place, which is that they do not rest on the lattice assumption everything else shares.

If no regulator binds you, take the hybrid you are given and build none

Most organisations sit inside none of these five scopes, and for them the rule on post-quantum algorithms is short. Take the hybrid your protocol already offers. Do not build one yourself unless you can name the failure you are insuring against.

Taking one is close to free. TLS 1.3 gives you X25519MLKEM768 as a configuration choice and the clients have already shipped it, so there is no second migration on your budget. When the classical half is eventually dropped, the change happens in the protocol rather than in your code.

Building one is not free. A hybrid you construct yourself means running two cryptosystems in every place you used to run one, for the life of the deployment, and then a second migration to take out the half you added. The NCSC’s three reasons for wanting a hybrid are interoperability, implementation security and protocol constraints. Every one of them is about the transition rather than the destination.

So the threshold is implementation risk rather than quantum risk. Build a hybrid where a flaw in one new implementation would be unrecoverable and you cannot patch the thing in the field, which in practice means long-lived embedded systems and anything that ships without an update path. Everywhere else take the single post-quantum algorithm.

Spend the effort you saved on being able to change algorithm without a release. In practice that means negotiating the algorithm rather than hard-coding it, keeping the identifier in configuration, and being able to hold two in the trust store at once. It costs a fraction of a hybrid, because you build one code path instead of running two cryptosystems for the life of the deployment.

Three dates would change that answer and all three are already on this page. NIST IR 8547 has sat as an initial public draft since its comment period closed in January 2025, and a final version could turn NIST’s neutrality into a position. ANSSI intends to attach post-quantum obligations to product qualification from 2027. The BSI stops recommending classical-only key agreement at the end of 2031. Look again when the first of those moves.

The protocol answered before the agencies did

While the authorities were writing guidance, the internet went ahead and picked. RFC 10024, published in August 2026 on the standards track, defines concrete hybrid key agreement for TLS 1.3 and registers three combinations. One of them, X25519MLKEM768, is the only one the registry flags as recommended.

The deployment numbers moved faster than any of the guidance. Cloudflare publishes the share of its human traffic that post-quantum key agreement protects. That share passed half in October 2025 and reached more than 65 per cent by April 2026. It moved because Chrome, Firefox and Apple turned the hybrid on by default, so there was a migration programme. It was simply not run by the organisations whose traffic it protects.

So for the commonest case, a web connection, the choice of post-quantum algorithms has largely been made on your behalf, and it was made in favour of hybrid. The agencies’ disagreement bites where you are choosing rather than inheriting: in your own protocols, your own firmware signing and anything you procure from the vendors selling this.

The cost nobody prices is doing the migration twice

One sentence in the NCSC guidance should shape a budget, and it is not the one that gets quoted. If a cryptographically relevant quantum computer ever exists, traditional public-key algorithms will provide no additional protection against it. At that point a hybrid gives no more security than the post-quantum algorithm on its own. The classical half becomes pure cost, in complexity and in overhead, for no security at all.

So a hybrid is a temporary structure by construction. The NCSC’s recommendation follows from that: if a hybrid scheme is chosen, use it as an interim measure, inside a flexible framework that enables a straightforward migration to post-quantum only in the future.

The consequence is a cost line most plans do not carry. The guidance names it directly, as the need to complete the migration twice, once to a hybrid scheme and again to post-quantum only as the end state. Our enterprise readiness guide sets out what the rest of that bill looks like. Anyone budgeting this work should decide deliberately whether they are buying one project or two. For most organisations the answer is one, because the hybrid that matters is the one TLS already gives them and the second migration is the bill for building their own.

Frequently asked questions