BSI TR-02102-1 and Post-Quantum: Germany's 2026 Crypto Baseline

TL;DR

The Bundesamt für Sicherheit in der Informationstechnik (BSI) — Germany’s Federal Office for Information Security — publishes TR-02102-1 “Cryptographic Mechanisms: Recommendations and Key Lengths”. It is Germany’s baseline cryptographic guidance for federal administration and is widely referenced in private-sector contracts and regulated-entity supervision. Current editions recommend hybrid classical-plus-post-quantum key establishment for long-term confidentiality use cases and name ML-KEM among acceptable post-quantum KEMs. For remote-access deployments in Germany, alignment with TR-02102-1 is the de facto cryptographic compliance standard. This post explains the technical recommendations, the BSI’s post-quantum migration position, and what a TR-02102-1-aligned VPN or ZTNA deployment looks like in 2026.

Who this is for

Security and compliance leads at German federal administration, German critical infrastructure operators (KRITIS), and any private entity with German public-sector contracts. Also non-German teams selling into the German market whose customer contracts reference TR-02102 compliance. Familiarity with general cryptographic vocabulary is assumed; some German-language terms are used where the English translation is awkward.

Table of contents

1. What the BSI is and what it does
2. The TR-02102 family of documents
3. Current TR-02102-1 cryptographic recommendations
4. The BSI’s post-quantum position, in order
5. How TR-02102-1 treats hybrid key exchange
6. How TR-02102-1 interacts with NIS2 in Germany
7. KRITIS and the sector-specific layer
8. Remote-access implementation aligned with TR-02102-1
9. Common pitfalls and how to avoid them
10. Further reading

1. What the BSI is and what it does

The BSI is Germany’s Federal Office for Information Security, part of the Federal Ministry of the Interior (BMI). Its statutory responsibilities include setting cybersecurity baselines for federal administration, operating CERT services, publishing technical guidelines, and certifying products and evaluators under the Common Criteria scheme.

Practically, the BSI produces three kinds of output that touch cryptography:

1. Technische Richtlinien (TR, Technical Guidelines). Normative technical documents. Most relevant: the TR-02102 family.
2. Position papers and white papers. Non-binding but influential. Examples: “Migration zu Post-Quanten-Kryptografie”, the joint paper with BSI/ANSSI on QKD.
3. Common Criteria certifications. Product-level evaluations under ISO/IEC 15408.

For network and remote-access engineering, TR-02102 and the PQC migration position paper are the relevant documents.

2. The TR-02102 family of documents

TR-02102 is published in four parts.

• TR-02102-1: Cryptographic Mechanisms: Recommendations and Key Lengths. General baseline for symmetric ciphers, hashes, asymmetric key establishment, and signatures.
• TR-02102-2: Use of Transport Layer Security (TLS). Specific recommendations for TLS 1.2 and 1.3 configurations.
• TR-02102-3: Use of Internet Protocol Security (IPsec) and Internet Key Exchange (IKEv2).
• TR-02102-4: Use of Secure Shell (SSH).

Each is updated approximately annually. The versioning convention puts the year and month in the document identifier. Always check the BSI website for the current version before quoting recommendations in an audit document.

The BSI publishes both a German-language version (the authoritative one) and an English-language translation. Where the two diverge, the German text controls. For most technical content the translations are faithful, but interpretations of edge cases should reference the German.

3. Current TR-02102-1 cryptographic recommendations

Summary of the general baseline from the current TR-02102-1 (verify against the live document for your target edition).

Symmetric block ciphers

• AES with key lengths of 128, 192, or 256 bits. 128 bits is acceptable for standard use; 256 bits is preferred where long-term protection is needed.
• Modes: GCM or CCM for authenticated encryption; CBC with HMAC as an acceptable alternative.

Hash functions

• SHA-256 and SHA-384 are recommended for general use.
• SHA-512 is recommended where the increased output is justified by use case.
• SHA-1 is not recommended for security-sensitive use.

Asymmetric key establishment (classical)

• Elliptic-curve Diffie-Hellman on curves P-256, P-384, P-521, Brainpool P256r1/P384r1/P512r1.
• Finite-field Diffie-Hellman on groups of at least 3072 bits.
• RSA-OAEP for key transport with RSA keys of at least 3072 bits.

Digital signatures (classical)

• ECDSA on the curves above.
• EdDSA (Ed25519 or Ed448).
• RSA-PSS with at least 3072-bit keys.

Post-quantum key establishment

• ML-KEM (FIPS 203) is named as an acceptable post-quantum KEM in the current guidance.
• FrodoKEM continues to be recognised by the BSI as a conservative alternative based on plain LWE; BSI has historically expressed preference for FrodoKEM in the highest-assurance contexts.
• Hybrid constructions combining a classical primitive with a post-quantum primitive are recommended for any application with long-lived confidentiality requirements.

Post-quantum signatures

• ML-DSA (FIPS 204) is named as an acceptable post-quantum signature.
• SLH-DSA (FIPS 205) is named for specific use cases including software and firmware signing.
• XMSS and LMS are named for stateful hash-based signatures in software and firmware contexts.

4. The BSI’s post-quantum position, in order

Chronologically, the BSI has been consistent in warning about harvest-now-decrypt-later since at least 2020. The key milestones:

• 2020: Initial position papers flagging the quantum threat to long-term confidentiality.
• 2021–2022: Active participation in EU-level discussions; co-authored joint position paper on QKD advising caution about QKD-only solutions without post-quantum backing.
• 2023: Public preference for hybrid deployments over pure post-quantum during the transition.
• 2024: Release of “Migration zu Post-Quanten-Kryptografie” migration guidance. Explicit recommendation that any system with long-lived confidentiality requirements should begin migration now.
• 2024–2025: TR-02102-1 editions incrementally formalise the post-quantum recommendations as FIPS 203, 204, and 205 are published and cross-referenced.

The consistent thread: conservative, favouring defence-in-depth, explicit about the harvest-now-decrypt-later threat, cautious about QKD as a standalone solution, supportive of hybrid deployments with classical fallback.

5. How TR-02102-1 treats hybrid key exchange

The current guidance describes hybrid key exchange as the preferred deployment mode during the transition window. Key properties called out:

1. Both components ephemeral per handshake. Not static keys.
2. Secure combiner that preserves security if either input is secure. Concatenation-then-KDF is the standard construction; specific KDF choice should be HKDF or an equivalent extractor-then-expander construction.
3. Transcript binding to prevent downgrade and rewrite attacks.
4. Domain separation in the KDF output.

This aligns exactly with the construction we described in Hybrid Key Exchange X25519 + ML-KEM-768: The Complete Guide. A hybrid X25519 + ML-KEM-768 deployment implemented with HKDF-SHA256, an explicit transcript hash as salt, and a versioned domain-separation info string meets the letter of the guidance.

6. How TR-02102-1 interacts with NIS2 in Germany

NIS2 is transposed in Germany as the NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG). The German law inherits from the EU directive the requirement of “appropriate and proportionate” cryptographic measures (NIS2 Article 21(2)(h)). It does not specify algorithms.

In practice, the way German entities demonstrate compliance with the cryptographic-measures clause is to align with TR-02102. An auditor or competent authority treating a TR-02102-aligned deployment as “appropriate” is the norm. A deployment that diverges from TR-02102 is not automatically non-compliant, but it needs a documented justification for the divergence.

For foreign vendors selling into Germany under NIS2-adjacent contracts, TR-02102 alignment is often a specific contractual clause, more prescriptive than the directive-level “appropriate” language.

See our NIS2 Remote Access post for the full Article 21 breakdown.

7. KRITIS and the sector-specific layer

KRITIS — Kritische Infrastrukturen — is the German framework for operators of critical infrastructure. It predates NIS2 and has been updated to accommodate the NIS2 transposition via the IT-Sicherheitsgesetz (IT-SiG) updates.

KRITIS operators include entities in energy, water, food, health, finance and insurance, transport and traffic, information technology and telecommunications, government administration, and waste management sectors. Thresholds and definitions are specified in BSIG and BSI-KritisV regulations.

Sector-specific BSI-C5 (Cloud Computing Compliance Controls Catalogue) applies to cloud services; BSI-C5 requires cryptographic controls aligned with TR-02102 among other measures.

For KRITIS-scope remote access, TR-02102-1 alignment is effectively mandatory, and the incident-reporting and audit requirements go beyond what non-KRITIS NIS2 entities face.

8. Remote-access implementation aligned with TR-02102-1

A TR-02102-1-aligned remote-access deployment in 2026 looks like the following:

Transport-layer protocols.

• TLS 1.3 for administrative interfaces, with cipher suite selection from the TR-02102-2 recommended set.
• WireGuard or IKEv2 for VPN, with configurations aligned to TR-02102-3 for IKEv2.
• SSH configured per TR-02102-4 for administrative shell access.

Key establishment.

• Classical ECDH or X25519 for backwards compatibility.
• Hybrid X25519 + ML-KEM-768 for any session carrying data with long-term confidentiality requirements.
• Ephemeral keys only; no static pre-shared keys as primary agreement.

Authentication.

• Phishing-resistant MFA via FIDO2/WebAuthn for administrative users.
• Standard MFA (TOTP or FIDO2) for all remote-access users.
• Certificate-based authentication where appropriate for machine-to-machine.

Symmetric protection.

• AES-256-GCM or ChaCha20-Poly1305 for AEAD.
• HKDF-SHA256 or HKDF-SHA384 for key derivation.

Signatures.

• Ed25519, ECDSA P-256/P-384, or RSA-PSS for classical.
• Planning for ML-DSA-87 where post-quantum signatures become operationally needed, particularly for long-lived certificates.

Logging and monitoring.

• Per-session log of the kex mode, cipher suite, and peer identity.
• Retention per the applicable sectoral requirements; typically six months to two years for security logs, longer for audit trails.

Key management.

• HSMs or validated cloud KMS for privileged keys.
• Documented lifecycle for rotation, revocation, and emergency replacement.

9. Common pitfalls and how to avoid them

Six mistakes we see in TR-02102 alignment work.

9.1 Citing an outdated edition

TR-02102-1 is updated annually. A document citing the 2021 edition in 2026 is stale. Always cite the current edition and review annually.

9.2 Confusing TR-02102-1 with TR-02102-2/3/4

The parts are different documents with different scopes. TLS-specific guidance is in part 2; for IPsec go to part 3. Quoting part 1 as authoritative for a TLS configuration is a common minor error.

9.3 Reading “acceptable” as “recommended”

The BSI distinguishes between primitives that are currently acceptable and primitives that are recommended. Acceptable implies a deployment may use them; recommended implies the BSI expects new designs to use them. For example, SHA-256 is recommended; SHA-1 is not acceptable for security-sensitive use.

9.4 Treating ML-KEM-768 and ML-KEM-1024 as equivalent

Both are in FIPS 203. TR-02102-1 names the ML-KEM family; specific parameter set is contextual. For high-assurance use cases align with the higher category (1024); for general commercial traffic, 768 is commonly considered adequate. Document the choice.

9.5 Skipping the hybrid construction

A deployment that ships ML-KEM alone, without a classical hybrid partner, does not meet the hybrid-preference guidance. Hybrid is deliberate; it is not a hedge.

9.6 Not documenting the justification for divergence

If your deployment diverges from TR-02102 recommendations for a specific reason — legacy interoperability, performance constraints, regulatory requirement from another jurisdiction — document the justification. An auditor finding a divergence with a clear documented justification is a minor finding; the same divergence without documentation is a major one.

10. Further reading

Primary sources. All links verified on the publish date.

• BSI TR-02102-1 Cryptographic Mechanisms: Recommendations and Key Lengths. The document, current edition.
• BSI TR-02102-2 Use of Transport Layer Security. TLS-specific guidance.
• BSI, “Migration zu Post-Quanten-Kryptografie”. Position on PQC migration.
• BSI-ANSSI joint position on QKD. Cautionary view on quantum key distribution.
• NIST FIPS 203 — ML-KEM. The standard cited by TR-02102-1.
• EU Coordinated Implementation Roadmap for PQC.

Related reading on this blog

• ANSSI PQC Transition Plan: France’s Deadlines for Public Sector Networks
• NIS2 Directive Remote Access Requirements
• Hybrid Key Exchange X25519 + ML-KEM-768
• ML-KEM-768 Explained

Try QuickZTNA

QuickZTNA ships hybrid X25519 + ML-KEM-768 on every tunnel, using FIPS 203 ML-KEM via the Go 1.24 standard library with HKDF-SHA256 derivation and transcript binding — a construction aligned with TR-02102-1’s hybrid-preference guidance. For German federal or KRITIS deployments, contact sales for a TR-02102 alignment brief. Start free to evaluate.