Sovereign Algorithms: The Dependency Nobody Chose

Brian Couzens

3 minutes ago

15 min read

Sovereign algorithms as a map of five national cipher vaults, each lit a different colour, one vault lamp going out.

Sovereign algorithms: why the post-quantum cryptography in your estate was chosen by other governments, what a national standard does and does not give you, and how to govern cryptography across jurisdictions that no longer agree.

On 1 October 2026, Germany's Federal Office for Information Security (BSI) advised that Classic McEliece should no longer be used for new developments or in the planning of new cryptographic applications. Classic McEliece is the oldest post-quantum encryption scheme in existence, proposed in 1978. BSI had recommended it in its technical guideline on cryptographic mechanisms since at least 2024. The International Organization for Standardization (ISO) had published it, alongside ML-KEM and FrodoKEM, in an amendment to the international standard for asymmetric ciphers on 5 June 2026. Four months later the German authority withdrew its support for new use.

BSI cited significant progress in the cryptanalysis of the scheme during 2026, without naming the work. The leading result is a paper posted in August 2026 by Ashrujit Ghoshal, Yuval Ishai, Aayush Jain and Nuozhou Sun. It gives a classical distinguisher that tells a Classic McEliece public key apart from random data in quasipolynomial time, applying to all the parameter sets considered in the US selection process, and extends it to a heuristic key recovery attack. A September paper by Stephen Weis lowered the estimated cost further. Neither is a practical break, and BSI said so: the results do not allow a practical attack on the parameter sets it recommends, hybrid use with a classical algorithm still gives at least classical security, and ML-KEM, FrodoKEM and HQC are unaffected. The recommendation changed anyway, because the direction of travel had changed.

An organisation that built to the German preference now holds a dependency it did not choose and a decision it cannot make. The algorithm was selected by a national authority, standardised by an international committee, and downgraded on the strength of work by academics in India, Israel and the United States. The organisation's own view was never asked for at any point.

That is the condition this article is about. A sovereign algorithm is one whose acceptability in a market is decided by a national authority rather than by the organisation using it. A post-quantum cryptography (PQC) migration in any organisation that operates across borders now runs through several such authorities at once, and they have stopped agreeing with each other.

What a sovereign algorithm is

The idea that a government should choose its own cryptography is older than the quantum threat. The modern version dates from September 2013, when news reports based on documents leaked by Edward Snowden raised the possibility that a random number generator standardised by the US National Institute of Standards and Technology (NIST), Dual_EC_DRBG, had been engineered by the US National Security Agency so that the agency could predict its output. RSA, which had shipped the generator as the default in its BSAFE developer libraries, advised its own customers to stop using it. In April 2014 NIST removed the algorithm from its draft revised recommendation, citing a lack of public confidence in it.

The lesson governments drew was not that standards are bad. It was that a standard written by another government carries that government's interests, and that a sovereign state needs a choice it controls. Three forms of sovereign algorithm have followed.

National selections. South Korea ran its own competition, KpqC, from 2022 and announced the winners on 16 January 2025: HAETAE and AIMer for signatures, SMAUG-T and NTRU+ for key establishment. China's Institute of Commercial Cryptography Standards launched its Next Generation Commercial Cryptographic algorithms programme on 5 February 2025 and closed submissions on 30 June 2026, with national standards reported to be expected within three years.
National preferences layered on international standards. BSI's technical guideline has recommended FrodoKEM and Classic McEliece, and recommends post-quantum key agreement only in hybrid with a classical algorithm. France's national cybersecurity agency, ANSSI, makes hybrid use mandatory in its regulated scope and intends to require PQC for products entering qualification from 2027. The US National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) accepts ML-KEM only at the 1024 parameter set and ML-DSA only at the 87 parameter set, and states that hybrid solutions will not be integrated into deployable National Security Systems. The UK National Cyber Security Centre recommends ML-KEM-768 and ML-DSA-65 and treats hybrid as an interim measure.
National timetables. The United States, the European Union, the United Kingdom, Australia and Canada have each set dates by which the transition must start, reach priority systems and finish. The dates differ by up to five years, and the G7's call to action set no common deadline to reconcile them. A fuller map is in The State of Post-Quantum Cryptography in 2026.

The same algorithm can appear in all three forms with different standing. ML-KEM is a NIST standard, a CNSA 2.0 requirement at one parameter set, a UK recommendation at another, a German recommendation only in hybrid, absent from the Korean selection, and not yet chosen or rejected by China's programme, which is still selecting. The name is the same. The permission attached to it is not.

Four limits on what a PQC standard gives you

A published standard is necessary. No organisation should deploy an algorithm that has not been examined in public. The error is to treat the standard as the decision. A standard answers one question, whether a scheme is acceptable to the body that published it, and four limits govern what follows from that.

The first limit is interoperability. Two parties who have each adopted ML-KEM may still fail to connect. One accepts only the 1024 parameter set because its regulator does. The other runs 768 in hybrid with an elliptic curve exchange because its regulator prefers that. The Internet Engineering Task Force published the hybrid key exchange for Transport Layer Security (TLS) 1.3 as a Proposed Standard in 2026, and BSI has said the hybrid combinations named in it will be recommended in its next guideline. The NSA will not have them in deployable National Security Systems, beyond exceptions it names itself. A supplier building for both markets ships two configurations and a policy for choosing between them, or ships one and loses a market.

The second limit is assurance. Standardisation is a judgement about the evidence available on a date. It is not a proof. Rainbow was a finalist in the US process in February 2022 when Ward Beullens recovered a secret key for its lowest security level in 53 hours on a laptop. SIKE had advanced to the fourth round of that process in July 2022 when Wouter Castryck and Thomas Decru broke its lowest security level in about ten minutes on a single core. Classic McEliece had survived close to fifty years of study when the August 2026 result arrived. None of these was a failure of the standards process. Each is a reminder that the process issues opinions, and opinions are revised.

The third limit is longevity. The body that approves an algorithm also decides when to deprecate it, and the organisation using the algorithm has no seat at that table. NIST's draft transition timetable deprecates RSA and elliptic curve schemes at 112-bit security after 2030 and disallows them after 2035. BSI moved on Classic McEliece in a single notice. When the authority changes its mind, the organisation inherits a migration it did not schedule.

The fourth limit is permission. A standard says an algorithm may be used. It does not say a product using it may be sold or operated in a given market. That is decided by certification: ANSSI's security visas and qualification, the Common Criteria schemes, FIPS 140-3 validation for the US federal market, and the national schemes in Malaysia, Korea, China and elsewhere. A product can implement a standardised algorithm correctly and still be unsellable in a jurisdiction until a certification body has said so, and certification bodies work to their own queues. The gap between a dated obligation and the availability of a validated product is examined in Demand has a date. Supply has a register.

Where the sovereign algorithm dependency sits

The sovereign dependency is rarely visible as a line in an architecture document. It sits in four places.

The first is suppliers. For the greater part of any estate, the organisation did not choose its algorithms. The supplier did, when it built the product, against whichever national guidance applied where the supplier sits. A product built to German guidance may arrive with FrodoKEM in hybrid. One built to CNSA 2.0 may arrive with ML-KEM-1024 alone. The buyer inherits both positions without having taken either. A route through that inheritance is set out in From Cryptographic Inventory to 2030: A Practical Roadmap for Vendor PQC Readiness.

The second is certification. A product's standing in a market is set by the certificate it holds, and certificates name algorithms and parameter sets. When the algorithm's status changes, the certificate's value changes with it, on a schedule the buyer does not control.

The third is protocols. Which algorithms a connection ends up using is settled by negotiation between two implementations, each configured to a different authority's preference. The outcome of that negotiation is an operational fact that no inventory of approved algorithms captures. This is the sovereign version of the visibility problem set out in Shadow Cryptography: The Estate Nobody Signed For.

The fourth is the markets the organisation sells into. A bank operating in Frankfurt, Seoul and Washington answers to three authorities with three different lists. A supplier to the US federal government and to a French operator of vital importance faces a hybrid prohibition on one side and a hybrid mandate on the other. The organisation's cryptographic policy has to be written for the strictest intersection of the markets it serves, and that intersection moves whenever any one authority moves. The picture outside Europe and the United States is thinner still: in Southeast Asia, Malaysia alone had national migration machinery in operation as of August 2026, according to SITG-Consulting's ASEAN readiness assessment.

The concentration underneath

One more fact shapes this landscape. Almost every algorithm selected by any authority rests on the same mathematics. ML-KEM, ML-DSA and the forthcoming FN-DSA are lattice schemes. So are HAETAE, SMAUG-T and NTRU+ from the Korean selection. Chinese researchers have been reported as focusing on unstructured lattice constructions rather than the algebraic lattices used elsewhere, which is a variation within the same family rather than a departure from it.

The reserves are few. SLH-DSA rests on hash functions. HQC, which NIST selected in March 2025 as a backup key establishment scheme on different mathematics from ML-KEM, rests on codes. So does Classic McEliece. FrodoKEM is a lattice scheme that drops the algebraic structure the others rely on for speed. The August 2026 result narrowed that reserve by one, in the view of the authority that had leaned on it hardest.

Sovereignty in algorithm selection has therefore produced national labels rather than national diversity. If a structural weakness in algebraic lattices were found, a scenario discussed in Beyond Q-Day Hype, it would not respect borders. It would weaken the US selection, three of the four Korean selections and much of the European preference in one movement, and each national authority would issue its own notice, on its own timetable, in its own language. Diversity of mathematical family is a governance decision about correlated failure, and at present almost nobody has made it.

Why sovereign algorithms decide a PQC migration

A migration programme that treats "standardised" as "settled" makes a set of predictable errors.

Algorithm selection is delegated to suppliers, so the estate ends up running whichever national preference each supplier built to.
A single national list, almost always NIST's, is adopted as the enterprise standard, and the programme discovers in its second year that it does not satisfy the German, French or Korean markets.
Parameter sets are chosen once, by the loudest regulator, and the organisation carries the cost of 1024-bit keys in markets that accept 768.
Hybrid is turned on or off globally, satisfying one authority and breaching another.
A change of status at one authority, such as the Classic McEliece notice, arrives with no owner, no impact assessment and no plan, because nobody recorded which deployments depended on that authority's view.
Long-lived data is protected by a single mathematical family, so the data's confidentiality rests on one assumption holding for its whole life.

The regulatory position reinforces the last point. The technical standard under the European Union's Digital Operational Resilience Act (DORA), which has applied to financial entities since 17 January 2025, requires a policy on encryption and cryptographic controls that provides for updating or changing cryptographic technology on the basis of developments in cryptanalysis. The BSI notice of 1 October 2026 is a development in cryptanalysis. A financial entity that cannot say, within days of such a notice, where the affected algorithm is deployed and who owns the response is not meeting that requirement.

The governance failure underneath

The failure is the same one that produces shadow cryptography: an unowned dependency. It is one instance of the wider cryptographic governance and control gap. Three habits create it.

The first is treating a standard as a decision. A standard is an input. The decision is the organisation's own: that this algorithm, at this parameter set, in this configuration, is acceptable for this data, in these markets, until this date. If nobody in the organisation has made that decision, the organisation has not chosen its cryptography. It has accepted whatever arrived.

The second is holding no record of what each deployment rests on. An inventory that lists "ML-KEM" is not enough. The record needs the authority whose approval is relied upon, the instrument, its date, and the date on which the organisation will review the position. Without that, a change at the authority cannot be traced to its consequences.

The third is leaving the moment of change unowned. Authorities change their minds. NIST removed Dual_EC_DRBG. BSI moved on Classic McEliece. NIST will deprecate RSA-2048 after 2030. Each change needs a person whose job is to receive it, assess it and act, and a programme that has not named that person will learn of the change from a supplier or an auditor.

Three questions test whether the dependency is owned.

For each algorithm in production, which national authority's position is the organisation relying on, and in which document?
When that authority changes its position, who is told, within how many days, and what do they do?
In which markets does the organisation's current configuration fail, and has anyone signed off on that gap?

Where those questions have no answer, the organisation's algorithm choices have been made for it.

Remediation, part one: establishing the dependency record

Remediation has two parts. The first establishes what the organisation depends on. The second decides what to do about it.

The dependency record extends the cryptographic inventory with the fields the inventory does not hold. It can be built in-house or as part of an independent PQC readiness assessment.

For each algorithm and parameter set in use: the authority relied on, the instrument and version, the date, and a review date.
For each market the organisation operates in or sells into: the authority, the current algorithm list, the hybrid position, the certification scheme and the dates.
For each supplier product with embedded cryptography: the algorithms and parameter sets it supports, whether it runs hybrid, which national guidance it was built to, and whether the algorithm can be changed without replacing the product.
For each protocol endpoint: which algorithms it is configured to offer and accept, so that the negotiated outcome can be predicted rather than discovered.
For each class of long-lived data: the mathematical family protecting it and the authority that approved that family.

The record is then reconciled against the market map. Each deployment that satisfies one market and fails another is a finding. Each supplier product that cannot change algorithm is a finding. Each data class that rests on a single mathematical family for longer than ten years is a finding. The reconciliation is the output, and it is the first time the organisation sees the dependency it has been carrying.

Two sources feed the record and need to be governed as such. The first is the supplier, through contract. Require disclosure of algorithms, parameter sets, hybrid behaviour and the national guidance the product was built to, and require a dated statement of how and when the algorithm can be replaced. The reasoning is set out in Stop Buying Cryptographic Debt for PQC. The second is the authorities themselves. Someone has to read what BSI, ANSSI, NIST, the NSA, the NCSC and the relevant Asian bodies publish, as they publish it, and route each change to the deployments that depend on it. That is a named role with a service level, not a reading habit.

Remediation, part two: deciding the position

With the record in hand, six decisions are available. Each should be made by the risk owner, recorded, and given a review date.

Set a parameter set policy. Decide whether the organisation runs the highest parameter set any of its markets requires everywhere, or varies by market. The first is simpler and dearer. The second needs a configuration record per market. Either is defensible. Silence is not. The size and performance cost of each choice is set out in Post-Quantum Cryptography, Crypto Modernisation and Key Sizes.
Set a hybrid policy by market. Where an authority mandates hybrid, run hybrid. Where an authority prohibits it in deployable systems, do not. Where an authority treats it as interim, record the date by which the organisation expects to drop it and what evidence would justify dropping it. A bounded way to start is set out in Beyond the Hype: A Vendor-Neutral Framework for Your First PQC Hybrid Pilot.
Build the agility layer. The organisation's own code should call cryptography through an interface that lets the algorithm, parameter set and hybrid mode be changed by configuration. A change of national position then becomes a change request rather than a rebuild. That is the practical meaning of cryptographic agility, and it is the only remediation that works for the next notice as well as this one.
Set a diversity policy for long-lived data. For data that must remain confidential beyond the point at which a structural attack on lattices would matter, protect it with two mathematical families, or with one family and a classical algorithm in hybrid, and record the reasoning. Mosca's theorem gives the test for which data qualifies.
Keep an exception register for sovereign conflicts. Where two markets cannot be satisfied by one configuration and the organisation chooses to accept the gap in one of them, record the decision, the owner, the compensating measures and the expiry date.
Replace what cannot change. A supplier product whose algorithm is fixed in hardware or firmware, with no upgrade path, is a dependency on that supplier's national authority for the life of the product. Plan its replacement on the authority's timetable, not the depreciation schedule.

Keeping it from coming back

The conditions that created the dependency will recreate it unless they change.

Procurement terms that require algorithm disclosure, a replacement path and notification of changes in the supplier's national guidance.
A rule that no algorithm enters production without an entry in the dependency record naming the authority relied on and the review date.
A standing watch on the authorities, with a named owner and a service level for routing changes to affected deployments.
Architecture standards that require the agility layer in new systems and prohibit direct calls to specific algorithms in application code.
A review of the dependency record at least annually and whenever an authority issues a notice, reported to the risk committee.
Periodic independent challenge of the record by a party that did not compile it, because deploying PQC is not the same as proving it works.

Questions for the board

A board does not need to understand lattices or Goppa codes to test this. Seven questions do the work.

Which authority's position is each of our production algorithms relying on, and where is that written down?
In which of our markets does our current cryptographic configuration fail, and who approved that gap?
When BSI issued its Classic McEliece notice on 1 October, who in this organisation received it, and what did they do?
How many of our supplier products can change algorithm without being replaced?
What proportion of our long-lived confidential data rests on a single mathematical family?
Do we run hybrid, and is the answer the same in every market we serve? If so, which authority are we breaching?
Who owns the dependency record, and when was it last reconciled against the markets we operate in?

The evidence that should sit behind those answers is set out in What Evidence Actually Proves a PQC Migration Is Good. An organisation that can answer these has chosen its cryptography. An organisation that cannot has had it chosen for it, by several governments at once, none of which was thinking about this organisation when it decided.

The position

Sovereign algorithm programmes exist because governments learned in 2013 that a standard carries the interests of its author. That lesson applies to any organisation that depends on those standards. A national selection carries the nation's interests. An international standard carries a committee's judgement on a date. Neither carries the organisation's own decision, and neither will notify the organisation when it changes.

The Classic McEliece notice is a small event. No practical attack exists, the recommended parameters stand, and the affected deployments are few. Its value is as a rehearsal. The next notice may concern an algorithm with far wider deployment, and the organisations that will handle it well are those that can already say which authority they relied on, where the algorithm runs, who owns the response and how the algorithm will be replaced. That is a governance capability, it sits with the executive who owns enterprise risk, and it has to be built before the notice arrives.

About the author

Brian Couzens is CEO of SITG-Consulting, an independent advisory firm working on post-quantum cryptography governance, cryptographic risk and quantum risk management. The PQC Discovery Sprint is SITG-Consulting's structured engagement for establishing cryptographic visibility across an estate, and the PQC Governance Digest tracks the authorities named in this article week by week.

SITG-CONSULTING