Germany’s Federal Office for Information Security (BSI) now advises against using Classic McEliece, a post-quantum key encapsulation mechanism, in new systems. In a note dated 29 September 2026 and announced on 1 October 2026, the BSI states that “Classic McEliece should currently no longer be used in new developments or when planning new cryptographic applications.” The reason is a run of 2026 research papers that significantly improve structural attacks on the scheme.
The advice is measured. The BSI also states that the results so far “do not enable a practical attack on Classic McEliece with the parameter sets recommended in TR-02102-1”, and that existing hybrid deployments still provide at least the security of the classical scheme they are combined with. This review covers what the BSI said, why it matters well beyond one algorithm, and how to find out whether Classic McEliece is in use in your estate.
What Classic McEliece is, and why some systems chose it
Classic McEliece is a code-based key encapsulation mechanism built on binary Goppa codes. It descends from the McEliece cryptosystem published in 1978, which makes it one of the oldest public-key cryptosystems. That long history is why it was widely seen as a conservative choice.
Its profile is unusual. Public keys are very large and ciphertexts are very small. NIST’s figures run from 261,120 bytes of public key for the smallest parameter set to 1,357,824 bytes for the largest, with ciphertexts of 96 to 208 bytes. For comparison, an ML-KEM-768 encapsulation key is 1,184 bytes. The BSI describes the resulting niche as “applications with long-lived static keys in which many ciphertexts have to be exchanged”. Responses to NIST’s request for feedback, summarised in NIST IR 8545, gave file encryption and virtual private networks as examples.
Its standing has differed by standards body:
- BSI: recommended in Technical Guideline TR-02102-1 since 2020, always in combination with a classical key agreement scheme. The current version, 2026-01, lists mceliece460896, mceliece6688128 and mceliece8192128 and their faster “f” variants.
- NIST: a fourth-round candidate that was not selected. NIST IR 8545 (March 2025) states that “Classic McEliece is no longer under consideration for standardization as part of the current NIST PQC Standardization Process”, while leaving open a later NIST standard based on the ISO one.
- ISO/IEC: standardised in June 2026, in ISO/IEC 18033-2:2006/Amd 2:2026.
What changed in 2026
For decades the best known way to attack McEliece was generic decoding, which treats the code as a random linear code. Structural attacks, which try to recover the secret Goppa code from the public key, were far more expensive. The BSI notes that the best such key-recovery attack had an estimated complexity of over 2^3000 even for the smallest parameters.
According to the BSI, several papers published “particularly in the last few months” have changed that picture, including work by BSI researchers. The headline results it summarises are:
- A distinguisher by Ghoshal, Ishai, Jain and Sun with a stated complexity of 2^120 to 2^124 operations for the TR-02102-1 parameter sets, and a heuristic key-recovery algorithm the authors estimate at 2^140 to 2^148.
- Follow-up work building key recovery on that distinguisher, including a paper by Stephen A. Weis stating a key-recovery complexity of 2^99 to 2^102 for the same parameter sets.
- Other distinguishers and key-recovery approaches with higher estimated costs, and an adaptation used to solve a specific key-recovery challenge set by the Technology Innovation Institute.
Those figures sit against the TR-02102 target of a security level of at least 120 bits. The BSI is careful about them: the most recent papers “have not yet completed a full peer-review process”, and it must be checked whether the complexity estimates and cost models are realistic, for example on memory access costs. Its overall reading is that “a significant improvement in structural attacks” can be observed, and that further improvements “are conceivable and to be expected”.
What the BSI recommends
- New systems: do not use Classic McEliece in new developments or new cryptographic applications. “For key agreement, it is advised to use FrodoKEM, ML-KEM or HQC (once the corresponding standard has been published) in accordance with the recommendations of TR-02102-1.”
- Existing hybrid deployments: the BSI’s recommendation has always been hybrid only, with the Classic McEliece key combined with a classically negotiated key so that both must be broken. Classical key agreement on its own remains recommended until the end of 2031, so “such a hybrid combination with Classic McEliece therefore still provides at least the security of the classical scheme.”
- Other post-quantum schemes: FrodoKEM and ML-KEM rest on different mathematics and are not affected. HQC, although also code-based, is not affected either.
- What comes next: the recommendation will be revised in the next version of TR-02102-1, expected in early 2027.
- The wider migration: the note does not change the BSI’s “general, urgent recommendation to complete the migration to post-quantum cryptography for key agreement by 2031 at the latest”.
Why this matters beyond one algorithm
Classic McEliece was the conservative option, recommended by a national authority for six years and standardised by ISO in June 2026. Within months of that standard, the same national authority advised against new use. The BSI draws the lesson itself: the results “underline how important it is to pay attention to crypto-agility during the migration because cryptanalytic advances can never be ruled out”, and the hybrid recommendation “has proven its worth”.
Three practical points follow for any post-quantum programme:
- Selection is not the end of assessment. An algorithm’s standing can change after it is chosen and deployed. The inventory has to record which algorithm and parameter set is used where, so that a change in standing can be turned into a list of affected systems quickly.
- Hybrid design buys time. Because the recommended deployments paired Classic McEliece with a second scheme, the change is a planning issue rather than an incident. Recording whether each deployment is hybrid, and with what, is part of the same inventory.
- Agility has to be real. Replacing an algorithm is only routine if it can be changed through configuration or a library update, rather than by redesigning a protocol or a product. Our comparison of crypto-agility maturity models covers how to measure that.
Where Classic McEliece shows up in practice
Because of its key sizes, Classic McEliece has not found widespread use, as the BSI itself notes. The places it does appear are specific and can be checked:
- WireGuard post-quantum add-ons. Rosenpass, an open-source key exchange that supplies post-quantum pre-shared keys to WireGuard, uses Classic McEliece and Kyber. The NetBird client runs an embedded Rosenpass server from version 0.25.4 as part of its quantum-resistance feature.
- Commercial VPN services. Mullvad’s quantum-resistant tunnels, on by default in its desktop apps since January 2025, use Classic McEliece and ML-KEM to exchange the WireGuard pre-shared key. Its command-line tool lists “Classic McEliece 460896 Round3 + ML-KEM-1024” as the default method.
- Cryptographic libraries. Botan documents Classic McEliece support. liboqs from the Open Quantum Safe project lists it as a Tier 3 (Community) algorithm and marks the upstream implementation as having no active maintenance.
- Pilots and long-lived key applications. File encryption tools, internal VPN pilots and products described as using a “conservative” code-based KEM are the other places to check, following the use cases the BSI and NIST describe.
It is equally useful to know where it is not. OpenSSH’s post-quantum key exchange uses mlkem768x25519-sha256, the default since OpenSSH 10.0, and sntrup761x25519-sha512. Neither involves Classic McEliece.
The VPN deployments above combine Classic McEliece with a second post-quantum scheme, ML-KEM or Kyber, and use the result as a WireGuard pre-shared key alongside WireGuard’s own key exchange. A weakened Classic McEliece therefore leaves another post-quantum scheme in place, which is the benefit of combining schemes that the BSI’s note describes.
How to find out whether you use Classic McEliece
For most organisations the honest expected answer is that it is used rarely, if at all. The point is to be able to show it, and to have the method ready for the next change of this kind. A practical sequence:
- Search code and configuration for the parameter set names, which all begin with “mceliece” (for example mceliece460896 or mceliece6688128f), and for library calls that select them.
- Check library inventories on endpoints and in build dependencies for liboqs, Botan and other post-quantum libraries, and record which algorithms each build enables.
- Review VPN and remote-access estates, especially WireGuard deployments that use post-quantum pre-shared key tools such as Rosenpass, NetBird’s quantum-resistance option or Mullvad.
- Ask suppliers which post-quantum key encapsulation mechanisms their products use, whether each use is hybrid, and what their plan is if one of them is downgraded.
- Record the result in the cryptographic inventory, with the parameter set and whether the deployment is hybrid, so that the next revision of TR-02102-1 in early 2027 can be checked against it.
How this maps to the ECEM lifecycle
Enterprise Cryptographic Exposure Management (ECEM) treats post-quantum readiness as a continuous six-stage lifecycle: Discover, Inventory, Assess, Prioritise, Transition, Monitor. The Classic McEliece advice exercises the last stage in particular. Discover and Inventory locate every use of the algorithm. Assess re-scores those uses against the new guidance, taking account of whether each is hybrid. Prioritise and Transition decide which uses to replace, and when, using the BSI’s preference for FrodoKEM, ML-KEM or, once standardised, HQC. Monitor is what turns an advisory like this one into a query against an existing inventory rather than a new discovery project.
Where Quantum Sentinel fits
Quantum Sentinel applies one classification vocabulary to every observation, whatever route found it, and Classic McEliece is part of that vocabulary, alongside ML-KEM, ML-DSA, SLH-DSA, FN-DSA, HQC, FrodoKEM and others. Hybrid constructions are identified as hybrid rather than counted as either half. An algorithm the platform does not recognise is recorded and marked for review rather than ignored. Findings land in a living Enterprise CBOM, so a change in an algorithm’s standing can be checked against the estate as a whole. The cryptographic coverage page sets out what is covered and how it is found.
Frequently asked questions
Has Classic McEliece been broken?
Not in practice. The BSI states that the published results do not enable a practical attack on Classic McEliece with the parameter sets recommended in TR-02102-1. It also states that structural attacks have improved significantly in recent months and that further improvements are conceivable and to be expected, which is why it advises against new use.
What did the BSI recommend about Classic McEliece?
In a note dated 29 September 2026 and announced on 1 October 2026, the BSI advised that Classic McEliece should no longer be used in new developments or when planning new cryptographic applications. For key agreement it advises FrodoKEM, ML-KEM, or HQC once its standard is published. It will revise its Technical Guideline TR-02102-1 accordingly, with the next version expected in early 2027.
Are existing hybrid Classic McEliece deployments still safe?
According to the BSI, a hybrid combination of Classic McEliece with a classical key agreement scheme currently still provides at least the security of the classical scheme, which remains recommended on its own until the end of 2031. Deployments that also combine Classic McEliece with a second post-quantum scheme, such as ML-KEM, keep that scheme’s protection as well.
Does this affect ML-KEM or HQC?
No. The BSI states that the results relate only to the McEliece cryptosystem. FrodoKEM and ML-KEM are based on different mathematical principles and are not affected. HQC is also code-based but is not affected either.
Is Classic McEliece a NIST standard?
No. It was a fourth-round candidate in the NIST post-quantum process, and NIST IR 8545 (March 2025) states that it is no longer under consideration in that process. It was standardised by ISO/IEC in June 2026, and NIST said it may consider a standard based on the ISO one later.
Sources: BSI, Notes on recent developments concerning Classic McEliece (29 September 2026) and announcement (1 October 2026, in German); BSI, TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths, version 2026-01; NIST, IR 8545, Status Report on the Fourth Round of the NIST Post-Quantum Cryptography Standardization Process (March 2025); NIST, FIPS 203; Ghoshal, Ishai, Jain and Sun, Quasipolynomial Cryptanalysis of the McEliece Cryptosystem; Weis, Improving GIJS Key Recovery for Classic McEliece. Deployment references: Rosenpass, NetBird documentation, Mullvad, OpenSSH, Botan and liboqs.
Further reading: crypto-agility maturity models compared, what Enterprise Cryptographic Exposure Management is, what a cryptography bill of materials is and the Quantum Sentinel cryptographic coverage page.