BSI TR-02102 und Post-Quanten-Kryptografie: Fristen, Pflichten und der nächste Schritt

Stand: 3. November 2026. Geprüft an der TR-02102-1 in der Version 2026-01 und an der nationalen Leitlinie vom 12. Oktober 2026. Was sich seitdem geändert hat, steht am Seitenende.

• Die TR-02102-1 des BSI ist eine technische Richtlinie, kein Gesetz. Sie richtet sich „in erster Linie empfehlend an Entwickler, die ab 2026 die Einführung neuer kryptographischer Systeme planen“. In Deutschland gilt sie als Maßstab für den Stand der Technik.
• Schlüsseleinigung: RSA, Diffie-Hellman und ECDH allein empfiehlt die Version 2026-01 nur noch bis Ende 2031, bei sehr hohem Schutzbedarf bis Ende 2030. Danach nur noch hybrid, also zusammen mit einem quantensicheren Verfahren wie ML-KEM.
• Signaturen: Klassische Signaturverfahren allein empfiehlt sie voraussichtlich bis Ende 2035.
• 2030 und 2035 für ganze Anwendungsfälle stammen aus der EU-Roadmap. BMDS, BMI und BSI haben diese Termine am 12. Oktober 2026 für Deutschland übernommen, als dringende Empfehlung und mit einem ersten kryptografischen Inventar bis Ende 2026.
• Pflicht wird daraus über § 30 BSIG (Stand der Technik für wichtige und besonders wichtige Einrichtungen), über Produktzulassungen, über Verträge und über Ausschreibungen. Eine gesetzliche Frist für Post-Quanten-Verfahren gibt es nicht.

Nehmen Sie eine Leitstandsanwendung, wie sie in vielen Werken läuft: seit 2012 in Betrieb, validiert, mit zwei Wartungsfenstern im Jahr. Sie spricht über TLS mit ihrem Datenbankserver, über ein VPN mit der Zentrale und signiert Prüfberichte für die Qualitätssicherung. An ihrer Kryptografie hat seit Jahren niemand etwas geändert, und das war richtig so: Jede Änderung an einem validierten System kostet einen Test, einen Stillstand und eine Unterschrift. Solange RSA und elliptische Kurven halten, gab es keinen Grund dafür.

Geändert hat sich nicht die Anlage, sondern der Zeitrahmen, in dem sie gedacht werden muss. Verschlüsselte Daten lassen sich heute mitschneiden und später entschlüsseln, sobald ein ausreichend leistungsfähiger Quantencomputer verfügbar ist. Das BSI nennt das das Szenario „Store Now, Decrypt Later“ (TR-02102-1, Abschnitt 2.1). Die vom BSI beauftragte Studie zum Entwicklungsstand hält einen solchen Rechner innerhalb von höchstens 15 Jahren für wahrscheinlich, also bis 2040 oder früher; die Leitlinie von BMDS, BMI und BSI stützt sich darauf (Abschnitt 1).

Daraus folgt keine Panik, aber eine Rechnung. Wie lange müssen die Daten auf dieser Verbindung vertraulich bleiben: Rezepturen, Prozessparameter, Personaldaten? Und wie lange dauert eine Umstellung, die durch Validierung, Lieferanten und Gegenstellen muss? Ist die Summe länger als die Zeit bis zu einem solchen Rechner, ist der Beginn für diese Daten schon heute spät. Wie Sie die Schutzdauer bestimmen, beschreibt „Heute abgefangen, morgen entschlüsselt“.

Die Technische Richtlinie besteht aus vier Teilen, derzeit alle in der Version 2026-01:

Das BSI überprüft die Empfehlungen jährlich. Teil 1 spricht sie ausdrücklich nur für einen Zeitraum bis Ende 2032 aus, weil längere Prognosen unsicher sind (Abschnitt 1.2).

Was sie verlangt und was nicht. Die Richtlinie bewertet Verfahren, nicht Ihr System. Sie selbst warnt vor dem Fehlschluss, dass ein System sicher sei, nur weil es ausschließlich empfohlene Verfahren verwendet (Abschnitt 1). Soll die Übereinstimmung eines Produkts mit der Richtlinie nachgewiesen werden, verlangt sie Common-Criteria-Zertifikate oder vergleichbare Verfahren des BSI, etwa eine Zulassung (Abschnitt 1.2). Schreibt ein Lieferant „BSI-konform“, ist die richtige Rückfrage deshalb: Was wurde von wem geprüft?

Wie sie verbindlich wird. Vier Wege, die man auseinanderhalten sollte:

Unsere Einordnung: Für eine NIS-2-Einrichtung ist die TR-02102 kein Gesetz, aber der naheliegende Maßstab, an dem ein Prüfer den Stand der Technik bei Kryptografie misst. Die Leitlinie sagt es ausdrücklich: Kryptografische Anwendungen müssen dem Stand der Technik genügen, „z.B. durch Einhaltung der Empfehlungen aus der Technischen Richtlinie BSI-TR-02102“ (Abschnitt 4.4).

Was „hohes Risiko“ heißt. Die EU-Roadmap stuft einen Anwendungsfall als hoch ein, wenn ein Bruch der Vertraulichkeit auch nach zehn oder mehr Jahren noch erheblichen Schaden anrichten würde. Die Leitlinie nimmt drei Faktoren hinzu: wie angreifbar die eingesetzten Verfahren sind, wie groß der Schaden wäre und wie lange die Umstellung dauert (Abschnitt 4.5). Die Einstufung nimmt Ihnen niemand ab, auch kein Lieferant.

Woher 2031 kommt. Die TR-02102-1 begründet die Frist mit einer gemeinsamen Empfehlung des BSI und europäischer Partnerbehörden aus dem Jahr 2024. Die EU-Roadmap kennt 2031 nicht; sie arbeitet mit Risikostufen und den Jahren 2030 und 2035. Beide passen zusammen: Wer hohes Risiko bis 2030 umgestellt hat, erfüllt 2031 für diese Verbindungen ohnehin.

2032 und 2036. Manche Übersichten nennen 2032. Das ist dieselbe Grenze wie 2031, gezählt ab dem ersten Jahr, in dem klassische Schlüsseleinigung nur noch hybrid empfohlen ist: Die TR empfiehlt sie „über das Jahr 2031 hinaus“ nur noch zusammen mit einem quantensicheren Verfahren (Abschnitt 2.3). Ebenso steht 2036 für das erste Jahr nach der Signaturfrist Ende 2035; dort ist es eine Ankündigung, noch keine Regel.

Zum Vergleich. In den USA will NIST quantenanfällige Public-Key-Verfahren nach 2030 abkündigen und nach 2035 in seinen Standards nicht mehr zulassen (NIST IR 8547, Oktober 2026). Wer in die USA liefert, hat damit ähnliche Termine aus einer anderen Quelle.

Wie ein nationaler Fahrplan Lieferbeziehungen berührt, steht in „Die deutsche PQC-Roadmap kommt“, mit einem Nachtrag zur Leitlinie.

Das Prinzip. Zwei Schlüsseleinigungen laufen nebeneinander, eine klassische und eine quantensichere, und aus beiden wird ein gemeinsamer Schlüssel abgeleitet. Er soll sicher bleiben, solange eines der beiden Verfahren sicher ist (TR-02102-1, Abschnitt 2.2).

Warum nicht gleich nur das neue Verfahren. Den quantensicheren Verfahren wird „noch nicht das gleiche Vertrauen entgegengebracht“, weil sie etwa bei Seitenkanalresistenz und Implementierungssicherheit weniger untersucht sind (Abschnitt 2.2). Die TR empfiehlt sie deshalb derzeit ausschließlich hybrid.

Welche Verfahren. Für den quantensicheren Teil nennt die TR-02102-1 (Abschnitt 2.4):

• ML-KEM-768 und ML-KEM-1024 nach FIPS 203, das Verfahren, das die meisten Bibliotheken und Protokolle verwenden;
• FrodoKEM-976 und FrodoKEM-1344, die konservativere Wahl auf unstrukturierten Gittern, bei ISO in Standardisierung;
• Classic McEliece mit gelisteten Parametersätzen. Nach Fortschritten in der Kryptoanalyse im Jahr 2026 rät das BSI jedoch, es für Neuentwicklungen nicht zu verwenden;
• HQC will das BSI nach Veröffentlichung des Standards aufnehmen.

Wie die Geheimnisse kombiniert werden. Für eigene Protokolle und Dateiformate empfiehlt die TR zwei Kombinierer (Abschnitt 2.2, Tabelle 2.1):

• CatKDF nach ETSI TS 103 744, mit KMAC oder HKDF;
• KeyCombine nach NIST SP 800-227, wobei die Funktion H durch eine empfohlene KDF oder KMAC umgesetzt wird.

Protokolle wie TLS 1.3 regeln die Kombination selbst; diese Verfahren behandelt Teil 1 nicht (Bemerkung 2.5).

Wo es heute schon geht.

• TLS 1.3: RFC 10024 ist seit August 2026 Proposed Standard. Die Gruppen SecP256r1MLKEM768 und SecP384r1MLKEM1024 will das BSI in der nächsten Fassung der TR-02102-2 empfehlen. Laut BSI lassen sie sich schon jetzt TR-konform einsetzen, und zusätzlich auch X25519MLKEM768.
• SSH: RFC 10042 (Informational, August 2026) beschreibt mlkem768x25519-sha256 und zwei Varianten mit NIST-Kurven.
• IPsec: RFC 9370 erlaubt mehrere Schlüsselaustausche in IKEv2. Die Festlegung von ML-KEM für IKEv2 ist im Oktober 2026 noch ein Internet-Draft.

Was es kostet. Ein ML-KEM-768-Schlüssel ist 1184 Byte lang, das Chiffrat 1088 Byte (FIPS 203). Der Verbindungsaufbau wird damit um gut zwei Kilobyte größer, und der erste Datensatz des Clients passt nicht mehr in ein einzelnes Paket. Ältere Firewalls und Geräte mit Paketprüfung können daran scheitern. Das gehört in den Test, bevor es in den Betrieb geht.

Was passiert, wenn eine Gegenstelle das neue Verfahren noch nicht kann, beschreibt „Hybride Kryptografie“.

Bei Signaturen gibt es kein „Store Now, Decrypt Later“: Eine klassische Signatur bleibt vertrauenswürdig, bis ein kryptografisch relevanter Quantencomputer existiert (TR-02102-1, Abschnitt 2.1). Deshalb ist die Frist später. Geplant werden muss trotzdem früh, aus zwei Gründen:

• PKI braucht lange. Wurzelzertifikate laufen oft über viele Jahre, und Prüfer müssen neue Formate verstehen, bevor sie eingesetzt werden. Die TR rechnet ausdrücklich mit langen Migrationszeiten bei Signaturen innerhalb einer PKI (Abschnitt 5.3). Die FAQ zur EU-Roadmap schlägt vor, eine neue PKI mit Post-Quanten-Verfahren neben der alten aufzubauen, wenn die vollständige Umstellung bis 2030 nicht machbar ist (Frage 2.4).
• Updates müssen das Update überleben. Produkte, die über 2030 hinaus im Einsatz sein sollen, sollen sich auf quantensichere Verfahren aktualisieren lassen, und der Update-Mechanismus selbst soll Post-Quanten-Signaturen verwenden. Die TR nennt das „dringend empfohlen“ (Abschnitt 5.3). Ein Gerät, dessen Firmware-Signatur sich nicht tauschen lässt, kann später auch nichts anderes mehr nachladen.

Was die TR für Signaturen empfiehlt (Abschnitt 5.3.4):

• Ein quantensicheres Signaturverfahren grundsätzlich nur zusammen mit einem klassischen. Beide Signaturen werden aneinandergehängt und nur gemeinsam als gültig anerkannt.
• ML-DSA-65 und ML-DSA-87 nach FIPS 204, jeweils in der Variante „hedged“.
• Hashbasierte Verfahren dürfen auch allein eingesetzt werden: SLH-DSA nach FIPS 205 sowie XMSS und LMS. Die beiden letzteren sind zustandsbehaftet und deshalb nur dort empfohlen, wo der Zähler sicher verwaltet wird, etwa bei der Signatur von Software- und Firmware-Updates.

Kombinierte Zertifikatsformate (Composite ML-DSA, Composite ML-KEM) sind im Oktober 2026 noch Internet-Drafts der IETF. Wie eine Zertifikatskette den Wechsel übersteht, beschreibt „Ihre Zertifikate laufen ab. Ihre Vertrauensarchitektur bleibt.“

Die TR-02102-1 erscheint jedes Jahr neu, meist im Januar. Eine Auskunft, die 2020 oder 2023 richtig war, kann heute falsch sein, ohne dass sich damals jemand geirrt hat. Bei einer älteren Prüfliste, einem Kryptokonzept oder einer Lieferantenantwort ist deshalb die erste Frage: Auf welche Fassung bezieht sie sich?

Die großen Einschnitte der letzten Jahre: 2020 kamen die ersten Post-Quanten-Verfahren in die Richtlinie, nur für den hybriden Einsatz. 2023 stieg das Sicherheitsniveau auf 120 Bit, seit 2024 ist RSA mit 2048 Bit nicht mehr konform, und DSA ist nur noch bis 2029 empfohlen. 2026 kamen die Migrationsfristen hinzu. Wann wir diese Seite jeweils nachgezogen haben, steht am Seitenende.

Classic McEliece: sechs Jahre empfohlen, für Neues nicht mehr. Seit 2020 steht das Verfahren in der Richtlinie, heute nur noch für den hybriden Einsatz. In seinem Hinweis mit Stand vom 29. September 2026 rät das BSI nach neuen Ergebnissen der Kryptoanalyse, zu denen es selbst beigetragen hat, Classic McEliece in Neuentwicklungen nicht mehr zu verwenden, und verweist auf FrodoKEM, ML-KEM und künftig HQC. Wer es heute hybrid einsetzt, hat trotzdem keinen Notfall: Weil das BSI Post-Quanten-Verfahren nur zusammen mit einem klassischen empfiehlt, bietet die Kombination nach seiner Einschätzung noch mindestens die Sicherheit des klassischen Verfahrens. Genau dafür ist die Regel „nur hybrid“ gedacht. Und der Fall zeigt, warum ein Verfahren tauschbar sein muss, statt fest im Code zu stehen (Punkt 9 der Checkliste).

Was daraus für Ihre Unterlagen folgt.

• Jede Aussage zur TR braucht die Fassung. „BSI-konform“ ohne Versionsangabe lässt sich nicht prüfen.
• Prüflisten und Kryptokonzepte von vor 2023 messen an einem niedrigeren Sicherheitsniveau. Falsch waren sie nicht, aktuell sind sie nicht mehr.
• Ein Vertrag, der auf „die jeweils gültige Fassung“ verweist, ändert sich mit jeder Ausgabe mit. Das ist gewollt, braucht aber eine Übergangsfrist für Fälle wie Classic McEliece (Punkt 10 der Checkliste).

Die TR-02102 ist für neue Systeme geschrieben. Ihre Systeme sind meist nicht neu. Die Übersetzung in Ihren Bestand findet an wenigen, benennbaren Stellen statt:

• Verbindungen (TLS, VPN, SSH). Hier entscheidet selten Ihr eigener Code, sondern die Komponente, die die Verbindung aufbaut: Betriebssystem, Webserver, Reverse Proxy, VPN-Gateway, Datenbanktreiber. Zu prüfen ist, welche Komponente das ist, in welcher Version, und ob sie die Gruppen aus RFC 10024 kann. Hybrid wird eine Verbindung erst, wenn beide Seiten es können.
• .NET-Anwendungen. Heikel sind fest verdrahtete Verfahren und Schlüssellängen: RSA mit 2048 Bit im Code, eigene Signaturformate, Algorithmuskennungen in Datenbanken. Wo eine Anwendung Kryptografie selbst aufruft, etwa beim Ausstellen von Zertifikaten, bei CMS-Nachrichten, XML-Signaturen oder eigener Verschlüsselung, ändert sich der Aufruf. Neu geschrieben werden muss die Anwendung deshalb nicht.
• Access und VBA. Eine Access-Anwendung verschlüsselt in der Regel nicht selbst. Die Verbindung zu SQL Server baut der ODBC-Treiber auf, Webaufrufe laufen über Komponenten von Windows. Ob dort hybrid verhandelt wird, entscheiden Treiber und Windows, nicht der VBA-Code. Bei der Inventur gehören Treiber und Version, die Verschlüsselungsoptionen der Verbindungszeichenfolgen und signierte VBA-Projekte auf die Liste. Gespeicherte Kennwörter in verknüpften Tabellen sind kein Quantenproblem; finden werden Sie sie bei dieser Gelegenheit trotzdem.
• Datenzugriff über einen Dienst. Steht zwischen Anwendung und Datenbank ein Datendienst, verschiebt sich die Frage auf dessen HTTPS-Endpunkt und die Plattform, auf der er läuft.
• Gespeicherte Daten. Symmetrische Verfahren wie AES-256 bleiben. Kritisch sind Archive und Sicherungen, deren Schlüssel einmal per RSA oder ECDH übertragen wurde: Sie sind nur so sicher wie diese Übertragung, falls sie mitgeschnitten wurde. Verliert ein Verfahren die Konformität zur TR, sollen auch die damit ausgehandelten Schlüssel nicht mehr eingesetzt werden (Bemerkung 2.1).
• Geräte mit langer Lebensdauer. Lässt sich die Firmware nicht auf neue Signaturen umstellen, bleibt Austausch. Die Leitlinie nennt beide Wege: den Ersatz hinauszögern, bis ein PQC-fähiges Gerät verfügbar ist, oder vorzeitig tauschen (Abschnitt 4.6).

Ob ein Altsystem bis 2030 überhaupt migrationsfähig ist, behandelt „Ihr Altsystem funktioniert. Aber ist es bis 2030 noch migrationsfähig?“

Zwölf Prüfpunkte für bestehende Anwendungen und ihre Lieferanten. Jeder Punkt nennt, was zu prüfen ist, wo, wer verantwortlich ist, welcher Nachweis zählt und was danach bleibt. Für den Stand jedes Punkts genügen vier Werte:

• geprüft: Die Bedingung unter „Geprüft, wenn“ ist erfüllt und der Nachweis liegt vor.
• teilweise: für einen Teil der Systeme erfüllt; der Rest ist benannt.
• nicht geprüft: noch offen.
• nicht relevant: mit schriftlicher Begründung, etwa „keine Public-Key-Verfahren im Einsatz“.

• Prüfen: Ist eine Person oder ein Gremium für die Umstellung benannt, mit Zeit und Budget?
• Wo: Organigramm, Beschluss der Geschäftsleitung.
• Verantwortlich: Geschäftsleitung.
• Nachweis: Benennung mit Aufgaben: Umsetzungsplan, Prioritäten, Fortschritt, Abstimmung mit Lieferanten (Leitlinie, Abschnitt 4.2).
• Geprüft, wenn: Die Stelle ist benannt und hat einen Termin für das erste Inventar.

• Prüfen: Wo werden welche Verfahren eingesetzt? Protokolle, Zertifikate, Signaturen, verschlüsselte Ablagen, Schlüsselspeicher, Bibliotheken und Geräte.
• Wo: Konfigurationen, Netzwerkscans, Quellcode, Software-Stücklisten, Auskünfte der Lieferanten.
• Verantwortlich: IT-Betrieb und Entwicklung, gesammelt bei der verantwortlichen Stelle.
• Nachweis: eine Liste mit System, Verfahren, Schlüssellänge, Protokollversion, Bibliothek mit Version und zuständiger Person, analog zum Krypto-Kataster im IT-Grundschutz (CON.1.A19).
• Restrisiko: Kryptografie in Fremdprodukten und Firmware, die niemand sieht.
• Geprüft, wenn: Jedes System im Umfang steht mit diesen Angaben in der Liste. Die Leitlinie empfiehlt das erste Inventar bis Ende 2026; vollständig muss es vor der Planung nicht sein (FAQ zur EU-Roadmap, Frage 4.2).

Vertiefung: Kennen Sie Ihre eigenen kryptografischen Abhängigkeiten? und Eine Software-Stückliste ist noch kein Kryptoinventar.

• Prüfen: Wie lange müssen die Daten jedes Datenflusses vertraulich bleiben?
• Wo: Schutzbedarfsfeststellung, Aufbewahrungsfristen, Verträge mit Kunden.
• Verantwortlich: Fachbereich mit Informationssicherheit.
• Nachweis: Schutzdauer je Datenfluss, mit Begründung.
• Geprüft, wenn: Jeder Datenfluss mit Public-Key-Verfahren hat eine Schutzdauer. Zehn Jahre und mehr bedeutet nach der EU-Roadmap hohes Risiko.

• Prüfen: Welche Anwendungsfälle tragen hohes, mittleres oder niedriges Risiko, und bis wann wird jeder umgestellt?
• Wo: Risikomanagement; Methode nach EU-Roadmap und PQC Migration Handbook, verträglich mit ISO 27005 und BSI-Standard 200-3.
• Verantwortlich: Informationssicherheit.
• Nachweis: Einträge im Risikoregister mit Frist.
• Restrisiko: Die Einstufung beruht auf einer Prognose; die Leitlinie verlangt einen Notfallplan für den Fall schnellerer Fortschritte (Abschnitt 1).
• Geprüft, wenn: Jeder Anwendungsfall aus dem Inventar hat Stufe und Termin.

• Prüfen: Können beide Endpunkte TLS 1.3 mit einer hybriden Gruppe aus RFC 10024? Gilt Entsprechendes für VPN und SSH?
• Wo: Konfiguration von Server, Proxy und Client; Mitschnitt des Verbindungsaufbaus.
• Verantwortlich: IT-Betrieb, für Fremdsysteme der Lieferant.
• Nachweis: Testprotokoll mit der tatsächlich ausgehandelten Gruppe.
• Restrisiko: Kann eine Gegenstelle nicht hybrid, fällt die Verbindung auf ein klassisches Verfahren zurück. Das muss sichtbar sein und darf nicht unbemerkt geschehen.
• Geprüft, wenn: Für jede Verbindung mit hohem Risiko ist die ausgehandelte Gruppe gemessen, nicht nur konfiguriert.

• Prüfen: Gibt es eigene Verschlüsselung außerhalb von TLS, etwa für Dateien, Nachrichten oder Lizenzschlüssel? Wird dort hybrid kombiniert, und womit?
• Wo: Quellcode, Entwurfsdokumente.
• Verantwortlich: Entwicklung.
• Nachweis: Entwurf mit dem Kombinierer (CatKDF oder KeyCombine) und Testvektoren.
• Geprüft, wenn: Kein eigenes Format kombiniert Geheimnisse anders als nach Tabelle 2.1 der TR-02102-1, oder die Abweichung ist begründet und befristet.

• Prüfen: Welche Zertifizierungsstellen gibt es, wie lange laufen ihre Zertifikate, und können alle Prüfer neue Formate lesen?
• Wo: PKI-Dokumentation, Zertifikatsspeicher, Geräte, die Zertifikate prüfen.
• Verantwortlich: PKI-Betrieb.
• Nachweis: Liste der Zertifizierungsstellen mit Laufzeiten; Plan für eine parallele Kette.
• Restrisiko: Kombinierte Zertifikatsformate sind noch nicht als RFC verabschiedet.
• Geprüft, wenn: Für jede Zertifizierungsstelle, deren Zertifikate über 2035 hinaus gelten, gibt es einen Plan.

• Prüfen: Lässt sich das Signaturverfahren der Software- und Firmware-Updates tauschen?
• Wo: Herstellerangaben, Update-Prozess, Bootloader.
• Verantwortlich: Produktverantwortliche, bei Fremdgeräten der Hersteller.
• Nachweis: Herstelleraussage mit Version und Termin oder ein eigener Test.
• Restrisiko: Geräte ohne tauschbaren Vertrauensanker lassen sich nur ersetzen.
• Geprüft, wenn: Für jedes Produkt mit Lebensdauer über 2030 ist der quantensichere Update-Pfad belegt oder der Ersatz geplant.

• Prüfen: Wo stehen Verfahren, Schlüssellängen oder Kennungen fest im Code?
• Wo: Codesuche nach Verfahrensnamen, Schlüssellängen und OIDs; Konfiguration.
• Verantwortlich: Entwicklung.
• Nachweis: Liste der Stellen; ein Test, der ein Verfahren über Konfiguration statt Code wechselt.
• Geprüft, wenn: Jede Stelle ist entweder konfigurierbar oder als Änderung eingeplant.

Vertiefung: Kryptoagilität: Können Ihre Dienstleister Algorithmen austauschen?

• Prüfen: Welche Lieferanten liefern Kryptografie mit, und was planen sie?
• Wo: Verträge, Fragebögen, CBOM.
• Verantwortlich: Einkauf mit Informationssicherheit.
• Nachweis: Antworten mit Versionen und Terminen; im Vertrag „Stand der Technik, orientiert an BSI TR-02102-1 in der jeweils gültigen Fassung“ und die Bereitstellung einer CBOM, wie es die Leitlinie vorschlägt (Abschnitt 4.6).
• Restrisiko: Eine Antwort ist noch kein Nachweis.
• Geprüft, wenn: Jeder Lieferant eines Systems mit hohem Risiko hat schriftlich geantwortet.

Vertiefung: PQC-Lieferantenfragebögen: Fragen Sie nach Nachweisen, nicht nach Schlagwörtern.

• Prüfen: Gibt es einen Testplan für Verbindungsaufbau, Paketgrößen, Leistung und Gegenstellen, und einen Weg zurück?
• Wo: Testumgebung, Änderungsverfahren.
• Verantwortlich: IT-Betrieb.
• Nachweis: Testbericht; dokumentierter Rückweg mit Auslöser.
• Restrisiko: Ein Rückweg auf ein klassisches Verfahren ist eine bewusste Abweichung. Sie gehört befristet ins Register.
• Geprüft, wenn: Jede Umstellung hatte einen Test vor dem Betrieb und hat einen Rückweg.

• Prüfen: Steht die Strategie im Kryptokonzept, und sind Abweichungen mit Frist erfasst?
• Wo: Kryptokonzept (IT-Grundschutz CON.1), Abweichungsregister.
• Verantwortlich: Informationssicherheit.
• Nachweis: Fassung des Kryptokonzepts mit Datum; Abweichungen mit Begründung, Frist und Freigabe.
• Geprüft, wenn: Ein Prüfer kann aus diesen Unterlagen ablesen, was bis wann umgestellt wird und was warum nicht.

Wir entwickeln zwei Produkte für Post-Quanten-Verfahren in bestehender Software. Beide sind als Vorschau veröffentlicht.

Die Kryptografie-Bibliothek für .NET ergänzt vorhandenen Code an der einzelnen Aufrufstelle um ML-KEM und ML-DSA: für Zertifikate, CMS-Nachrichten, XML-Signaturen und hybride Schlüsselvereinbarung. Ihre Voreinstellung folgt der TR-02102-1 in der Version 2026-01, und das lässt sich nachlesen (Richtlinie für Post-Quanten-Verfahren):

• ML-KEM-768 und -1024 sowie ML-DSA-65 und -87 laufen nur zusammen mit einem klassischen Verfahren.
• Hybride Schlüssel kombiniert sie mit KeyCombine nach NIST SP 800-227, mit HKDF-SHA256 als Funktion H.
• Nicht empfohlene Parametersätze und reine PQ-Verfahren erzeugen neue Daten nur mit einer ausdrücklichen Freischaltung beim Start. Jede Abweichung meldet ein Ereignis.
• Fordert ein Aufruf einen PQ-Anteil an und kann ihn nicht erzeugen, scheitert er, statt still klassisch weiterzumachen.

Was sie nicht kann:

• CatKDF, SLH-DSA, XMSS, LMS, FrodoKEM und Classic McEliece sind nicht umgesetzt.
• Sie enthält keinen TLS-Handschlag.
• OpenSSL ab 3.5 installieren und aktualisieren Sie selbst.
• Sie ist weder nach FIPS 140-3 noch nach einem anderen Schema zertifiziert. Dass ihre Voreinstellung der TR folgt, ist keine Zulassung.

Der Krypto-Dienst bietet ML-KEM und ML-DSA als eigenen Prozess für L4Re und Windows. Hybrid kombinieren muss dort der Aufrufer.

Database Gateway und OData-ODBC-Treiber sprechen HTTPS. Ihr Schlüsselaustausch ist der der Plattform, auf der sie laufen. Für diese Verbindungen machen wir keine Post-Quanten-Aussage; sie gehören wie jede andere Verbindung unter Punkt 5 der Checkliste. Woran wir dafür arbeiten, steht im nächsten Abschnitt.

Zu diesem Thema sind wir nicht über ein Lehrbuch gekommen, sondern über einen Datenweg. Im März 2020, als über Nacht alle von zu Hause arbeiteten, haben wir in wenigen Tagen einen Notzugang gebaut: Fachanwendungen holten ihre Daten über HTTP statt direkt aus der Datenbank. Er hielt den Betrieb am Laufen. Er prüfte aber nur, wer anfragte, nicht, was diese Person durfte. Aus dieser Lücke ist der Database Gateway entstanden, mit Anmeldung bei jeder Anfrage, Regeln je Objekt und Methode und einem Protokoll auch der abgewiesenen Anfragen. Die ganze Geschichte erzählt „Homeoffice 2020: Die Anwendung lief. War die Architektur darauf vorbereitet?“.

Eine Grenze ist geblieben, die aus dem Abschnitt oben: Die Rechte regelt der Gateway, den Transport schützt die Plattform, mit klassischem Schlüsselaustausch. Daran arbeiten wir auf zwei Wegen.

Ein zusätzlicher quantensicherer Schlüssel für HTTPS. Das Vorbild stammt aus der VPN-Welt. Rosenpass läuft neben WireGuard, handelt mit Post-Quanten-Verfahren einen eigenen Schlüssel aus und übergibt ihn WireGuard als vorab geteilten Schlüssel für den Handschlag, erneuert alle zwei Minuten. WireGuard verschlüsselt weiter wie bisher; schwächer als WireGuard allein wird die Verbindung dadurch nicht. Wir untersuchen, wie sich dieses Muster auf TLS 1.3 zwischen Gateway und Treiber übertragen lässt, denn TLS 1.3 kann einen extern vereinbarten Schlüssel zusammen mit dem gewohnten Diffie-Hellman-Austausch verwenden. Übernehmen wollen wir das Muster, nicht die Auswahl der Verfahren: Rosenpass setzt neben Kyber auch Classic McEliece ein, von dem das BSI inzwischen abrät. Für den quantensicheren Teil planen wir mit ML-KEM und einem Kombinierer nach Abschnitt 2.2 der TR.

Ein Edge-Gateway für Anlagen. Im Verbundvorhaben „Postquantensichere Verschlüsselung in automatisierten Systemen“, gefördert aus dem EFRE/JTF-Programm NRW, arbeiten wir mit der TU Dresden (Betriebssystemkern L4Re), ISS (Hardware) und weiteren Partnern an einem Gateway, das vor einer Anlage sitzt, etwa vor einer Windenergieanlage. Das Ziel: Ein Steuerbefehl erreicht die Anlage nur, wenn sein Absender sich ausweisen kann und berechtigt ist, damit niemand eine Anlage über ihre Fernzugänge übernehmen kann. Unser Anteil im Verbund sind der Algorithmus und PKI as a Service, also die Zertifikate, an denen sich die Beteiligten gegenseitig erkennen.

Wohin das führt. Beide Wege enden bei der Frage, die schon 2020 die entscheidende war: Wer darf was, und wer kann es belegen? Wir erweitern den Database Gateway deshalb zu einer Infrastruktur für eine Lieferkette. Jede Installation wird zu einem eigenen Vertrauensraum für die Unternehmen, die an ihr beteiligt sind, etwa Betreiber, Hersteller und Dienstleister. Darin wird jede Anfrage geprüft, gleich aus welchem Netz sie kommt (Zero Trust), und die Beteiligten weisen sich gegenseitig mit Zertifikaten aus der PKI dieser Installation aus, statt einander pauschal zu vertrauen (Mutual Trust).

Das ist unsere Richtung, kein heutiger Produktumfang. Termine und Funktionsumfang stehen noch nicht fest, und in einem Forschungsvorhaben kann sich auch der Weg noch ändern. Bis dahin gilt für die Verbindungen des Database Gateway, was oben steht. Wer an einer solchen Lieferkette beteiligt ist und früh mitreden möchte, erreicht uns über die Kontaktseite.

• Sie wissen noch nicht, welche Verfahren wo stecken: Beginnen Sie mit den Punkten 1 bis 4 der Checkliste. Dafür brauchen Sie niemanden von außen, und die Leitlinie setzt dafür Ende 2026.
• Eine .NET-Anwendung von Ihnen signiert oder verschlüsselt selbst: Die Dokumentation der Bibliothek zeigt die erste hybride Zertifikatskette Schritt für Schritt. Funktionen, Voraussetzungen und Grenzen stehen auf der Produktseite.
• Sie möchten das Inventar nicht allein aufnehmen: Auf der Seite Kryptografie können Sie die Aufnahme Ihres Krypto-Bestands anfragen. Im ersten Gespräch klären wir, welche Systeme dazugehören.

Ist die TR-02102 verbindlich?
Nicht als Gesetz. Sie richtet sich empfehlend an Entwickler neuer Systeme. Verbindlich wird sie über Produktzulassungen, etwa für Verschlusssachen, über Verträge und Ausschreibungen. Für Einrichtungen nach § 30 BSIG ist sie der naheliegende Maßstab für den Stand der Technik.

Müssen wir bis 2031 auf Post-Quanten-Kryptografie umstellen?
Kein Gesetz verlangt das. Die TR empfiehlt klassische Schlüsseleinigung allein nur bis Ende 2031, danach hybrid. Für Daten mit hohem Risiko empfehlen EU-Roadmap und Leitlinie die Umstellung schon bis Ende 2030.

Reicht es, RSA durch ML-KEM zu ersetzen?
Nein. Die TR empfiehlt ML-KEM nur zusammen mit einem klassischen Verfahren. Außerdem betrifft die Umstellung Signaturen, Zertifikate, Protokolle und gespeicherte Daten, nicht nur den Schlüsselaustausch.

Darf X25519MLKEM768 in TLS 1.3 eingesetzt werden?
Ja. Laut BSI kann es zusätzlich zu den Gruppen eingesetzt werden, die es empfehlen will: SecP256r1MLKEM768 und SecP384r1MLKEM1024 aus RFC 10024, vorgesehen für die nächste Fassung der TR-02102-2. Wer in einem Vertrag „empfohlen nach TR-02102“ zusagt, sollte eine dieser beiden Gruppen anbieten.

Was hat sich in der TR-02102-1 2026 geändert?
Die Version 2026-01 nimmt erstmals Migrationsfristen auf, überarbeitet Schlüsselableitung und Hybridisierung und kündigt die alleinige Nutzung klassischer asymmetrischer Verfahren ab. Was die Fassungen davor geändert haben, steht im Abschnitt Frühere BSI-Empfehlungen.

Was ist mit Classic McEliece?
Die TR-02102-1 nennt Parametersätze, seit 2020 nur für den hybriden Einsatz. Nach Fortschritten in der Kryptoanalyse rät das BSI seit 2026 jedoch, es für Neuentwicklungen nicht zu verwenden.

Wir sind keine NIS-2-Einrichtung. Betrifft uns das?
Die Leitlinie richtet sich ausdrücklich auch an Organisationen und Unternehmen. „Store Now, Decrypt Later“ betrifft Ihre eigenen Daten, gleich wie Sie reguliert sind. Und Ihre Kunden können die Anforderungen in Verträge schreiben.

Gilt das auch für Lieferanten im Ausland?
Eine deutsche Richtlinie bindet sie nicht. Erreichen werden sie die Anforderungen über Verträge und Ausschreibungen, wie es die Leitlinie empfiehlt.

Was ist eine CBOM?
Eine Cryptographic Bill of Materials, zum Beispiel nach CycloneDX: eine maschinenlesbare Liste der kryptografischen Bestandteile eines Produkts. Die Leitlinie empfiehlt sie für den Vergleich innerhalb der Lieferkette und hält fest, dass ihre Bereitstellung vertraglich vereinbart werden kann.

Quellen (geprüft am 3. November 2026):

• BSI: TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“, Version 2026-01 vom 23. 1. 2026, Abschnitte 1, 1.2, 2.1 bis 2.4, 5.3, 5.3.4; Teile 2 bis 4 in der Version 2026-01; Hinweise zu RFC 10024 und zu Classic McEliece auf derselben Seite
• BSI: Pressemitteilung vom 11. 2. 2026
• BMDS, BMI, BSI: „Nationale Umsetzung der EU-Roadmap zur Umstellung auf Post-Quanten-Kryptografie“, 11. 9. 2026, veröffentlicht 12. 10. 2026
• NIS Cooperation Group: „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Part 1, Version 1.1 vom 11. 6. 2025, und die FAQ dazu vom 15. 4. 2026
• Europäische Kommission: Empfehlung (EU) 2024/1101 vom 11. 4. 2024
• § 30 BSIG
• NIST: FIPS 203, FIPS 204, FIPS 205 (August 2024); SP 800-227 (September 2025); IR 8547 (Oktober 2026)
• IETF: RFC 10024, RFC 10042, RFC 9370
• ETSI TS 103 744 V1.2.2 (2026-02)

Was wir beobachten: die nächste Fassung der TR-02102-1 (üblicherweise im Januar), die angekündigte Empfehlung der RFC-10024-Gruppen in TR-02102-2, die Aufnahme von HQC, die Verabschiedung kombinierter Zertifikatsformate und ob IT-Planungsrat und UP KRITIS die Fristen bis Ende 2026 verbindlich machen.

Regulatorische Aussagen altern. Wer diese Seite nach dem Stand oben liest, prüft die Fristen bitte an der Primärquelle.