Stand der Technik ist kein Gefühl: Warum die BSI TR-02102 Ihre Kryptografie auf den Prüfstand stellt
Hand aufs Herz: Wann haben Sie zuletzt nachgesehen, welche Cipher Suites Ihre Webserver, VPN-Gateways und Admin-Zugänge tatsächlich aushandeln? Bei den meisten Organisationen lautet die ehrliche Antwort: nie. Verschlüsselung gilt als “erledigt”, sobald irgendwo ein Schloss-Symbol im Browser erscheint.
Während die Angriffsflächen wachsen und der regulatorische Druck durch NIS2 und die Neufassung des BSIG spürbar zunimmt, taucht in fast jedem Audit, jeder Datenschutzfolgeabschätzung und jeder Vertragsverhandlung derselbe Begriff auf: Stand der Technik. Artikel 32 DSGVO fordert ihn, NIS2 verschärft ihn – aber kaum jemand kann sagen, was er konkret bedeutet. Für Kryptografie in Deutschland gibt es darauf eine erstaunlich präzise Antwort, und sie steht in einem Dokument, das viele kennen, aber wenige gelesen haben: TR-02102 des BSI.
Technische Richtlinie TR-02102-2 des BSI
Die unbequeme Kernaussage vorweg: Die TR-02102 ist die De-facto-Referenz dafür, was kryptografisch als zeitgemäß gilt. Wer davon abweicht, ist nicht automatisch unsicher – aber er ist begründungspflichtig. Und “haben wir schon immer so gemacht” ist keine Begründung, die ein Auditor akzeptiert.
Die TR-02102 ist eine Technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik. Ihr Zweck ist die Bewertung kryptografischer Verfahren und die Ableitung von Empfehlungen mit einem Vorhersagezeitraum, der inzwischen bis ins Jahr 2031 reicht. Sie richtet sich primär an Organisationen, die kryptografische Infrastrukturen aufbauen oder betreiben – also an genau die Verantwortlichen, die entscheiden müssen, welche Algorithmen, Schlüssellängen und Protokolle eingesetzt werden. Wichtig ist, was die TR-02102 ausdrücklich nicht ist: Sie erhebt keinen Anspruch auf Vollständigkeit. Nicht aufgeführte Verfahren gelten nicht automatisch als unsicher. Es ist also kein Kryptografie-Lehrbuch und kein erschöpfender Algorithmen-Katalog. Für Ihre Praxis heißt das: Sie ist eine Entscheidungsgrundlage und liefert keine fertigen Produkte, sondern den Maßstab, an dem Sie Ihre eigenen Konfigurationen messen können und an dem Dritte sie messen werden.
Die Richtlinie besteht aus vier aufeinander aufbauenden Teilen, die jährlich aktualisiert werden. Die aktuell relevante Fassung ist die Version 2026-01.
Hierbei ergibt sich folgende Gliederung:
- TR-02102-1: Empfehlungen und Schlüssellängen (Algorithmen, Schlüssellängen, PQC, Legacy)
- TR-02102-2: Verwendung von TLS (Webserver, APIs, Mail, Portale)
- TR-02102-3: Verwendung von IPsec / IKEv2 (Site-to-Site-VPN, Standortkopplung)
- TR-02102-4: Verwendung von SSH (Administrative Zugänge, Automatisierung)
Teil 1 definiert den Rahmen; die Teile 2 bis 4 übersetzen ihn in konkrete Anforderungen für die jeweiligen Protokolle. Wer nur Teil 1 liest, kennt die Theorie – wer die Teile 2 bis 4 auslässt, scheitert an der praktischen Umsetzung.
Algorithmen und Schlüssellängen
Die TR-02102 orientiert sich an einem Sicherheitsniveau von mindestens 120 Bit. In der Konsequenz bedeutet das: AES-128 ist die untere Grenze, AES-256 wird für den langfristigen Schutz empfohlen. Bei RSA reicht die historische 2048-Bit-Marke längst nicht mehr; empfohlen werden Schlüssel ab 3000 Bit, bei elliptischen Kurven Kurvenparameter ab rund 250 Bit. Veraltete Ciphers sind aus dem empfohlenen Verwendungszeitraum herausgefallen.
Zugespitzt gesagt: Viele Altverfahren sind faktisch nicht mehr auditfähig. Wer heute noch SHA-1, RSA-1024 oder TLS-Cipher mit statischem RSA-Schlüsselaustausch produktiv betreibt, hat im Prüfungsfall ein Erklärungsproblem – kein technisches Restrisiko, sondern ein dokumentiertes Defizit.
Beim Umgang mit Legacy-Systemen wird die TR-02102 oft missverstanden. Sie verbietet alte Verfahren nicht von heute auf morgen. Stattdessen definiert sie Verwendungszeiträume und Übergangsphasen: Algorithmen werden mit einem Datum versehen, bis zu dem ihr Einsatz noch als vertretbar gilt. Manches ist bis 2026 oder 2029 toleriert, vieles bis 2031.
Für den Mittelstand ist das die entscheidende Frage: Wo darf ich noch Legacy einsetzen – und wo nicht mehr? Die Antwort ist nicht “nirgends”, sondern “mit Ablaufdatum und Begründung”. Ein altes Verfahren in einem isolierten abgesicherten Segment ist etwas anderes als dasselbe Verfahren am internetexponierten Reverse Proxy. Genau diese Differenzierung müssen Sie selbst treffen und dokumentieren können.
Die Theorie wird dort konkret, wo Ihr Tagesgeschäft stattfindet: TLS schützt Webserver, APIs, Exchange/Mail und Self-Service-Portale. Die Richtlinie verlangt mindestens TLS 1.2, präferiert TLS 1.3. SSLv2/v3 und TLS 1.0/1.1 werden explizit NICHT mehr empfohlen. IPsec/IKEv2 sichert Site-to-Site-Kopplungen. IKEv1 wird nicht mehr betrachtet. SSH ist das am häufigsten unterschätzte Einfallstor: Administrative Zugänge, CI/CD-Pipelines und OT-Fernwartung laufen oft mit jahrealten Schlüsseln und ohne saubere Algorithmen Wahl. Gerade an den OT- und Fernwartungszugängen rächt sich nachlässige Krypto-Hygiene besonders, weil dort selten jemand nachjustiert.
Post-Quanten-Kryptografie
Der spannendste Teil der aktuellen Fassung betrifft die Post-Quanten-Kryptografie (PQC). Das BSI macht deutlich, dass die Migration mehr ist als eine Schlüssellängen-Anhebung – es geht um den vollständigen Austausch asymmetrischer Algorithmen, inklusive Neuimplementierung und Integration in Protokolle. Empfohlen werden hybride Verfahren, die klassische und quantenresistente Algorithmen kombinieren, sowie konkrete PQC-Schemata wie ML-KEM, FrodoKEM und Classic McEliece. Die Marschrichtung ist unmissverständlich: Für hochsensitive Anwendungen ruft das BSI – gemeinsam mit europäischen Partnern – zur Umstellung bis spätestens 2030 auf. Klassische asymmetrische Verfahren allein gelten langfristig nicht mehr als ausreichend. Google und Cloudflare setzen einen noch ehrgeizigeren Zeitplan. Dort soll die Umstellung bereits bis 2029 abgeschlossen sein.
Wer jetzt denkt, das betreffe nur Geheimnisträger, irrt. “Harvest now, decrypt later” ist kein Marketing-Slogan, sondern ein reales Angreifermodell: Heute abgefangene, langlebig vertrauliche Daten lassen sich später entschlüsseln. In der Realität finden sich immer wieder dieselben Lücken: veraltete TLS-Versionen, falsch konfigurierte Cipher Suites, zu schwache Schlüssel, kein Krypto-Inventar und kein automatisierter Zertifikats-Rollout. Letzteres wird mit der branchenweiten Verkürzung der Zertifikatslaufzeiten zum operativen Risiko – manuelle Verwaltung skaliert nicht mehr.
Daraus folgen keine Buzzwords, sondern klare Handlungspunkte:
- Kryptografie-Inventar erstellen: Sie können nichts absichern, was Sie nicht kennen. Algorithmen, Schlüssel, Zertifikate, Protokollversionen – inventarisiert und bewertbar.
- Mindeststandards definieren: Eine verbindliche interne Krypto-Policy auf Basis der TR-02102, gegen die jede Konfiguration geprüft wird.
- Lifecycle-Prozesse etablieren: Schlüssel und Zertifikate brauchen Rotation, Ablaufüberwachung und Automatisierung – idealerweise über ACME.
- PQC-Strategie starten: Krypto-Agilität als Architekturprinzip, hybride Verfahren dort, wo Daten lange vertraulich bleiben müssen.
- PKI-Infrastruktur konsolidieren: Eine saubere, automatisierbare Zertifikatsverwaltung ist die Grundlage für alles Weitere.
Hier schließt sich der Kreis zum Management. Die TR-02102 fungiert als Maßstab für den Stand der Technik und als anerkannte Referenz bei Audits und Prüfungen. Im Kontext von Art. 32 DSGVO, NIS2 und – für KRITIS-Betreiber – dem BSIG ist sie das stärkste verfügbare Argument: Wer nachweist, dass er TR-02102-konform verschlüsselt, hat gegenüber Aufsichtsbehörden, Auditoren und im Schadensfall die deutlich bessere Position.
Die Kehrseite ist ebenso klar: Abweichungen müssen begründet werden. Nicht verboten – aber dokumentiert, risikobewertet und mit Übergangsplan versehen. Die Beweislast liegt bei Ihnen.
Was jetzt zu tun ist
Kryptografie ist kein Projekt zum Abhaken. Die TR-02102 wird jährlich aktualisiert, Verwendungszeiträume ändern sich, Verfahren entfallen. Unternehmen müssen deshalb kontinuierlich nachsteuern und ihre Entscheidungen nachvollziehbar dokumentieren. Wer das konsequent tut, stärkt nicht nur seine Audit-Sicherheit, sondern auch seine Resilienz. Wer es ignoriert, baut technische Schuld auf, die spätestens beim nächsten Vorfall oder Audit sichtbar wird.
Hält Ihre Kryptografie künftig einer Bewertung nach TR-02102 stand?
Autor: Christian Müller
Bildquellen: SHD, Shutterstock