Die DORA-Verschlüsselungsleitlinie nach RTS-Artikel 6

Artikel 6 der Delegierten Verordnung (EU) 2024/1774 der Kommission, der technischen Regulierungsstandards (RTS) zum IKT-Risikomanagement unter DORA, verpflichtet ein Finanzunternehmen zu einer Leitlinie für Verschlüsselung und kryptografische Kontrollen. Diese Leitlinie muss Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse enthalten. Der Text nennt keinen Algorithmus und setzt keine Post-Quanten-Frist. Im Folgenden trennen wir die wörtliche Anforderung von unserer Einschätzung, wie das Dokument verfasst und belegt werden kann. IKT steht für Informations- und Kommunikationstechnik. Dies ist eine Information, keine Rechtsberatung.

Was Artikel 6 wörtlich verlangt

Die RTS sind für die Finanzunternehmen in ihrem Anwendungsbereich verbindlich, und Artikel 6 ist ihr Verschlüsselungsartikel. Verlangt wird eine dokumentierte Leitlinie für Verschlüsselung und kryptografische Kontrollen, die als Teil der IKT-Sicherheitsleitlinien angenommen wird und auf den Ergebnissen der Datenklassifizierung und der IKT-Risikobewertung beruht. Die Leitlinie behandelt den Schutz von Daten in den Zuständen, die im Unternehmen tatsächlich vorkommen: im Ruhezustand, bei der Übertragung und, soweit relevant und technisch machbar, bei der Verarbeitung. Ist die Verschlüsselung von Daten in Verarbeitung nicht machbar, wird erwartet, dass das Unternehmen die Daten in einer geschützten Umgebung verarbeitet oder andere Maßnahmen ergreift und diese Entscheidung dokumentiert. Der Artikel verweist auf führende Praktiken und anerkannte Standards statt auf eine feste Algorithmenliste. Und er enthält die Klausel, die für die Post-Quanten-Arbeit am wichtigsten ist: Die Leitlinie muss Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie enthalten, wenn sich die Kryptoanalyse weiterentwickelt. Der maßgebliche Text ist auf EUR-Lex verfügbar, unsere datierte Zusammenfassung finden Sie auf der Seite zu den DORA-RTS. Prüfen Sie die Absatznummerierung stets anhand der konsolidierten Fassung, bevor Sie sie in einer Antwort an Prüfer zitieren.

Artikel 7 ist die ergänzende Bestimmung: kryptografisches Schlüsselmanagement über den gesamten Lebenszyklus (Erzeugung, Erneuerung, Speicherung, Archivierung, Abruf, Vernichtung) sowie ein Register der Zertifikate und der Geräte, auf denen Zertifikate gespeichert sind, zumindest für IKT-Assets, die kritische oder wichtige Funktionen unterstützen. Lesen Sie beide Artikel zusammen. Die meisten Nachweise, die ein Prüfer unter Artikel 6 anfordert, stecken in den Inventaren und Registern, zu deren Führung Artikel 7 Sie verpflichtet.

Was Artikel 6 nicht sagt

Er nennt weder ML-KEM (Module-Lattice-based Key Encapsulation Mechanism, von NIST am 13. August 2024 als FIPS 203 standardisiert) noch hybriden Schlüsselaustausch, und er gibt kein Migrationsdatum vor. Diese Signale stammen aus anderen Dokumenten, und jedes hat seinen eigenen Status. NIST IR 8547 ist ein erster öffentlicher Entwurf (12. November 2024, weiterhin ein Entwurf), der vorschlägt, quantenverwundbare Algorithmen mit 112 Bit Sicherheit nach 2030 als veraltet einzustufen und alle quantenverwundbaren Public-Key-Algorithmen nach 2035 nicht mehr zuzulassen. Die EU Coordinated Implementation Roadmap v1.1 (veröffentlicht am 23. Juni 2025) ist eine koordinierte Orientierungshilfe für die Mitgliedstaaten, keine für Unternehmen verbindliche Verordnung: Sie sieht erste Schritte vor, darunter ein kryptografisches Inventar und nationale Roadmaps bis Ende 2026, die Migration von Anwendungsfällen mit hohem Risiko bis Ende 2030 und mit mittlerem Risiko bis Ende 2035. NIS2 Art. 21(2)(h) verlangt gesondert Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung. Unternehmen, die in den Anwendungsbereich beider Regelwerke fallen, sollten eine einzige Leitlinie verfassen und sie zweifach zuordnen, statt zwei Dokumente zu pflegen.

Eine Gliederung Abschnitt für Abschnitt

Die folgende Struktur ist unsere Interpretation, keine von einer Aufsichtsbehörde veröffentlichte Vorlage. Sie ist so angelegt, dass jeder Abschnitt eine Frage beantwortet, die ein Prüfer wahrscheinlich stellt, und dass der veränderliche Teil (die Algorithmen) in einem Anhang steht, den Sie versionieren können, ohne die gesamte Leitlinie neu aufzurollen.

1. Zweck, Geltungsbereich und Governance. Welche Unternehmen, Systeme und Drittparteien erfasst sind, wer die Leitlinie genehmigt, wer für sie verantwortlich ist, in welchem Rhythmus sie überprüft wird.
2. Begriffe und Rollen. Schlüsselverwahrer, Kryptografie-Architekt, Asset-Verantwortlicher, Zertifikatsverantwortlicher. Definieren Sie jedes Akronym einmal.
3. Bezug zur Datenklassifizierung. Für jede Klassifizierungsstufe der erforderliche Schutz in jedem Datenzustand. Das macht die Leitlinie risikobasiert statt generisch.
4. Zugelassene Algorithmen, Schlüssellängen und Protokolle (Anhang A). Eine versionierte Tabelle mit drei Spalten: bevorzugt, akzeptabel, verboten. Nennen Sie zu jedem Eintrag den zugrunde liegenden Standard.
5. Daten im Ruhezustand. Festplatten, Datenbanken, Objektspeicher, Backups, Archive, Endgeräte. Benennen Sie den Mechanismus und wer die Abdeckung prüft.
6. Daten bei der Übertragung. Mindestversion von TLS, zugelassene Cipher Suites und Gruppen für den Schlüsselaustausch, interner Verkehr zwischen Diensten, Dateiübertragung, E-Mail, Fernadministration.
7. Daten in Verarbeitung. Wo dies gilt und, wo nicht, die stattdessen genutzte geschützte Umgebung oder andere Maßnahmen, mit dokumentierter Begründung.
8. Schlüssel und Zertifikate. Verweis auf Artikel 7: Regeln für den Lebenszyklus, Nutzung von Hardware-Sicherheitsmodulen und Key-Management-Diensten, Rotationsfristen, das Zertifikatsregister und seine Ablaufwarnungen.
9. Kryptografisches Inventar und Lieferanten. Wie das Inventar erstellt und aktualisiert wird und was Sie von IKT-Drittdienstleistern verlangen.
10. Änderung der kryptografischen Technologie (Anhang B). Die Agilitätsklausel, beschrieben im nächsten Abschnitt.
11. Ausnahmen und Altsysteme. Ein Register befristeter Ausnahmen, jeweils mit kompensierender Kontrolle, verantwortlicher Person und Enddatum.
12. Nachweise und Berichterstattung. Welches Artefakt welche Klausel belegt, wer es erstellt und wie oft.

Die Änderungsbestimmung: Krypto-Agilität schriftlich festhalten

Eine Klausel, die besagt, das Unternehmen werde kryptografische Entwicklungen beobachten, ist kein Nachweis. Eine Klausel, die ein Prüfer testen kann, benennt den Auslöser, die verantwortliche Rolle, das Inventar, auf das sie wirkt, und die Zeit bis zur Umsetzung. Fünf Elemente genügen.

• Auslösende Quellen. Benannte Dokumente und Feeds, die Sie verfolgen: NIST-Standards und -Entwürfe, BSI TR-02102-1 (eine Technische Richtlinie, deren Version 2026-01 hybride Post-Quanten-Schlüsseleinigung empfiehlt und klassische Schlüsseleinigung allein nur noch bis Ende 2031 empfiehlt, bei sehr hohem Schutzbedarf bis Ende 2030), Veröffentlichungen der ANSSI (deren Post-Quanten-Empfehlungen außerhalb ihres regulierten Bereichs noch keine regulatorischen Pflichten sind), End-of-Support-Mitteilungen von Lieferanten sowie veröffentlichte kryptoanalytische Ergebnisse.
• Eine Entscheidungsverantwortung. Eine Rolle, die Anhang A ändern kann, mit einem Gremium, das die Änderung genehmigt, und einer Aufzeichnung von Datum, Begründung und Quelldokument.
• Ein Inventar mit Verantwortlichen. Was Sie nicht auflisten können, können Sie nicht ändern. Eine kryptografische Stückliste (CBOM) ist ein praktischer Weg, dieses Inventar zu erstellen; das ist unsere Interpretation, keine Anforderung des Textes.
• Asset-Klassen mit Zieldaten. Gruppieren Sie Assets nach Exposition und danach, wie lange ihre Daten vertraulich bleiben müssen, und geben Sie dann jeder Gruppe ein eigenes Zieldatum statt eines einzigen für den gesamten Bestand.
• Eine Regel für sichere Einführung. Neue Algorithmen werden zusammen mit einem klassischen Fallback aktiviert, in der Staging-Umgebung getestet und erst dann übernommen.

Warum zuerst der Schlüsselaustausch: Aufgezeichneter Verkehr ist nur durch den Schlüsselaustausch geschützt, mit dem die Sitzung aufgebaut wurde. Heute mitgeschnittener Verkehr kann daher später entschlüsselt werden, wenn dieser Austausch quantenverwundbar ist. Signaturen und Zertifikate können danach migriert werden, denn eine heute verifizierte Signatur wird nicht rückwirkend fälschbar. Das ist der nüchterne Grund, warum hybrider Schlüsselaustausch, zum Beispiel X25519MLKEM768 (IANA-Codepoint 0x11EC), der erste konkrete Schritt für ein Finanzunternehmen ist. Vorstandardisierte Kyber-Gruppen wie X25519Kyber768Draft00 (0x6399) sind veraltet und sollten in Anhang A als verboten aufgeführt werden. Für die ML-KEM-Gruppen in OpenSSL ist OpenSSL 3.5 oder neuer erforderlich.

Section 10. Changing cryptographic technology

10.1 Annex A (approved algorithms) is reviewed at least every 12 months and on any
     of these triggers: a new or withdrawn standard, an update to a national
     technical guideline we track, a published cryptanalytic result, a supplier
     end-of-support notice, or a change in the classification of data we protect.
10.2 The CISO owns Annex A. Changes are approved by the ICT risk committee and
     recorded with a date, a rationale and the source document.
10.3 Each asset class in Annex B has a named owner and a target date for migration
     to the algorithms marked preferred in Annex A.
10.4 Where an asset cannot meet its target date, the owner records a time-limited
     exception with a compensating control and an end date.
10.5 A new algorithm is deployed with a classical fallback, validated in staging,
     and promoted only after a documented interoperability test.

Von der Anforderung zum Nachweis

Die linke Spalte gibt die Anforderung sinngemäß wieder. Die mittlere Spalte ist unsere Interpretation von Nachweisen, die sie erfüllen, keine von einer Behörde veröffentlichte Liste.

Prüfen Sie die Aussage zur Übertragung, bevor ein Prüfer es tut

Aussagen der Leitlinie zu Daten bei der Übertragung lassen sich am leichtesten überprüfen und sind am leichtesten falsch, denn ein Load Balancer, ein Content Delivery Network oder ein älterer virtueller Host kann der Baseline unbemerkt widersprechen. Beginnen Sie mit einer rein lesenden Prüfung, mit OpenSSL 3.5 oder neuer:

openssl s_client -connect www.example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"

Führen Sie den Befehl für jeden öffentlichen Hostnamen in Ihrem Register aus, nicht nur für die Hauptseite. Fällt Ihr Bestand auch in den Anwendungsbereich von PCI DSS, speist dasselbe Inventar die Anforderung 12.3.3, die seit dem 31. März 2025 verpflichtend ist und dokumentierte Cipher Suites und Protokolle verlangt, die mindestens alle 12 Monate überprüft werden, wie in unserem Beitrag zum kryptografischen Inventar nach PCI DSS beschrieben. Ein Inventar, zwei Zuordnungen.

Vier Fallstricke

• Fristen in die Leitlinie schreiben, als hätten die RTS sie festgelegt. Zitieren Sie externe Zeitpläne als Auslöser für Überprüfungen und erläutern Sie ihren Status, denn Orientierungshilfen und Entwürfe sind keine Pflichten.
• Eine Leitlinie ohne Inventar dahinter. Die Änderungsbestimmung ist ohne eine Liste der Assets, ihrer Kryptografie und ihrer Verantwortlichen nicht überprüfbar.
• Einen externen Scan als Bestätigung behandeln. Ein Scan beschreibt die von außen sichtbare Konfiguration eines bestimmten Endpunkts zu einem bestimmten Zeitpunkt. Er ist weder eine Zertifizierung noch eine Konformitätsbestätigung.
• Die Algorithmenliste im Haupttext der Leitlinie festschreiben. Führen Sie sie in einem Anhang mit eigener Versionsnummer, damit eine Entwicklung in der Kryptoanalyse keinen vollständigen Genehmigungszyklus der Leitlinie erfordert.

Nächster Schritt

Beginnen Sie mit den Nachweisen, die Sie heute zusammentragen können: Listen Sie Ihre öffentlichen Endpunkte auf, halten Sie fest, welchen Schlüsselaustausch jeder davon aushandelt, und fügen Sie diese Ausgabe dem Abschnitt Ihrer Leitlinie zu Daten bei der Übertragung bei. Sie können Ihre Domain kostenlos mit PQC Status scannen, um die TLS-Versionen, Cipher Suites, die Unterstützung für hybrides ML-KEM und die Zertifikatskette zu sehen, die ein externer Beobachter wahrnimmt, und anhand der Lücken in Anhang B Zieldaten je Asset-Klasse festlegen. Wiederholen Sie den Scan nach jeder Änderung, damit das Auslöserprotokoll datierte Vorher-Nachher-Nachweise enthält.