TL;DR. Die NCSC-Frist zur Bestandsaufnahme 2028 liegt vor jeder Migrationsfrist. Banken können sie nicht halten: Das DORA-Asset-Register erfasst keine Kryptografie.

Wichtige Erkenntnisse

Die Frist, die niemand kalkuliert hat. Lesen Sie die veröffentlichten Migrationsfristen genau, und die Abfolge ist eindeutig.
Ihr DORA-Register erfasst alles außer der Kryptografie. Hier kommt der Teil, der die Leute überrascht.
Was ein CBOM tatsächlich enthält. Ein Cryptography Bill of Materials ist ein formales Inventar der kryptografischen Assets eines Systems — der Algorithmen, Schlüssel, Zertifikate und Protokolle sowie ihrer Beziehungen zu den Softwarekomponenten, die…
Die Bestandsaufnahme sind vier Probleme, nicht eines. Die Bestandsaufnahme als einen einzigen Arbeitsstrang zu behandeln, ist der häufigste Weg, auf dem diese Programme scheitern.

Was Sie nicht erfassen können, können Sie nicht migrieren: Das kryptografische Bill of Materials, das Banken immer noch fehlt

Jede Post-Quanten-Roadmap im Bankwesen setzt ein Inventar voraus, das es nicht gibt. Die Pläne sind geschrieben, die Steuerungsgremien tagen, die Scorecards stehen auf Gelb. Darunter liegt die Annahme, irgendjemand könne irgendwo eine Liste jeder Stelle vorlegen, an der die Bank eine kryptografische Operation ausführt — welcher Algorithmus, welche Schlüssellänge, welche Bibliothek, welches Zertifikat, ablaufend wann. Fast kein Institut kann das. Der erste Meilenstein des NCSC ist kein Migrationsmeilenstein: Er ist ein Meilenstein der Bestandsaufnahme, fällig 2028, und er ist derjenige, den niemand kalkuliert hat.

Management Summary

Die Reihenfolge lautet: Bestandsaufnahme, dann Agilität, dann Migration. Die Leitlinie des NCSC setzt einen definierten Meilenstein zur Bestandsaufnahme auf 2028, die Migration höchster Priorität auf 2031 und den Abschluss auf 2035. Ein Institut, das mit der Migration beginnt, bevor es erfasst hat, migriert die Systeme, die es zufällig kennt.

Das Register, das Sie haben, beantwortet die Frage nicht, vor der Sie jetzt stehen. DORA Article 8 verpflichtet Finanzunternehmen, IKT-Assets zu identifizieren, zu klassifizieren und zu dokumentieren sowie ihre Interdependenzen zu kartieren. Es verlangt keine einzige kryptografische Eigenschaft. Ein Article 8-konformes Register kann daher vollständig und für die Planung der Krypto-Agilität dennoch wertlos sein.

Der Standard existiert bereits. Kryptografische Assets — Algorithmen mit Schlüsselgröße, Modus und Kurve; Schlüssel; Zertifikate; Protokolle — lassen sich in CycloneDX abbilden, das als ECMA-424 veröffentlicht ist. Das ist eine Schema-Frage, keine Beschaffungsfrage.

Das schwierigste Viertel können Sie nicht selbst scannen. Hardware-Sicherheitsmodule, Payment-Appliances, herstellerseitig eingebettete Bibliotheken und SaaS-Anbieter lassen sich nicht erfassen, indem man einen Scanner darauf richtet. Dieser Teil des Inventars entsteht aus vertraglichen Nachweispflichten, und die Klausel muss existieren, bevor die Roadmap es kann.

Die Frist, die niemand kalkuliert hat

Lesen Sie die veröffentlichten Migrationsfristen genau, und die Abfolge ist eindeutig. Die Roadmap des National Cyber Security Centre setzt die Bestandsaufnahme — ein vollständiges Bild davon, welche Systeme und Dienste von Kryptografie abhängen — auf 2028, die Migrationsarbeit höchster Priorität auf 2031 und den Abschluss über alle Systeme, Dienste und Produkte hinweg auf 2035. Der Transition Report des NIST, IR 8547, läuft auf einer kompatiblen Spur: Quantenanfällige Public-Key-Algorithmen einschließlich RSA und ECC gelten nach 2030 als veraltet und sind nach 2035 unzulässig.

Die meisten Bankprogramme haben 2035 als das maßgebliche Datum verinnerlicht. Das ist das falsche Ende des Zeitplans, um von dort aus zu planen.

Zwei Daten wiegen weit schwerer. Das erste ist 2028, weil die Bestandsaufnahme der Input für alles Nachgelagerte ist — Sie können eine Migration nicht gegen einen unbekannten Nenner zuschneiden, kalkulieren oder sequenzieren. Das zweite ist 2030, denn „veraltet" ist in einem regulierten Institut kein weiches Wort: Es ist der Punkt, an dem das weitere Vertrauen auf einen Algorithmus zu einer Entscheidung wird, die jemand unterschreiben muss.

Von heute bis 2028 bleiben weniger als dreißig Monate. Das sind ein, vielleicht zwei Budgetzyklen, um eine Fähigkeit aufzubauen, mit der die meisten Institute nicht begonnen haben.

Ihr DORA-Register erfasst alles außer der Kryptografie

Hier kommt der Teil, der die Leute überrascht. Die meisten großen europäischen Banken führen bereits ein detailliertes, regelmäßig überprüftes Inventar ihrer IKT-Assets, weil DORA sie dazu verpflichtet.

Article 8 der Regulation (EU) 2022/2554 verpflichtet Finanzunternehmen, alle IKT-gestützten Geschäftsfunktionen, die sie tragenden Informations- und IKT-Assets sowie deren Rollen und Abhängigkeiten im Hinblick auf IKT-Risiken zu identifizieren, zu klassifizieren und angemessen zu dokumentieren — und die Konfiguration dieser Assets sowie die Verbindungen zwischen ihnen fortlaufend überprüft zu kartieren.

Das ist ein ernstzunehmendes Inventar. Es hat auch die falsche Form für dieses Problem.

Tabelle 1: Das Register, das Sie haben, und das Register, das der Meilenstein 2028 verlangt

Frage	IKT-Asset-Register (DORA Article 8)	Kryptografisches Inventar (CBOM)
Was ist dieses Asset, und wem gehört es?	Ja — das ist der Kern des Registers	Nicht sein Zweck
Wie kritisch ist es, und wovon hängt es ab?	Ja — Klassifizierung und Interdependenzkartierung	Aus dem Asset-Register übernommen
Welche Algorithmen nutzt es, und wo?	Nein	Ja — pro Komponente, mit Schlüsselgröße, Modus und Kurve
Welche Bibliothek implementiert sie, in welcher Version?	Teilweise, über das SBOM, sofern eines existiert	Ja, als explizite Beziehung
Welche Zertifikate legt es vor, ablaufend wann?	Selten, und meist in einem separaten PKI-Werkzeug	Ja
Wo liegen die Schlüssel, und wie sind sie geschützt?	Nein	Ja — einschließlich der Frage, ob ein HSM im Pfad liegt
Ist dieses Asset quantenanfällig?	Nicht ableitbar	Direkt beantwortbar

Die letzte Zeile ist das gesamte Argument. Ein Institut kann Article 8 vollständig erfüllen, seine Prüfung bestehen und dennoch außerstande sein, die Frage „Wie viele unserer Systeme brechen 2030?" zu beantworten, ohne ein Projekt zur Bestandsaufnahme von Grund auf zu beauftragen.

Das ist keine Kritik an DORA. Article 8 wurde geschrieben, um Fragen der Resilienz und der Konzentration zu beantworten, und das leistet er gut. Er wurde schlicht nicht geschrieben, um eine Frage der Krypto-Agilität zu beantworten. Die beiden Register müssen verknüpft werden, statt als getrennte Tabellen getrennter Teams geführt zu werden.

Was ein CBOM tatsächlich enthält

Ein Cryptography Bill of Materials ist ein formales Inventar der kryptografischen Assets eines Systems — der Algorithmen, Schlüssel, Zertifikate und Protokolle sowie ihrer Beziehungen zu den Softwarekomponenten, die sie verwenden.

Der entscheidende strukturelle Punkt: Es ist kein neues Dateiformat. Die Unterstützung kryptografischer Assets wurde in CycloneDX eingebracht, die von der OWASP getragene Bill-of-Materials-Spezifikation, die als Standard von Ecma International unter ECMA-424 veröffentlicht ist. Ein CBOM ist damit ein CycloneDX-Dokument mit befüllten Kryptografie-Feldern. Es validiert gegen dasselbe Schema, durchläuft dieselben Pipelines und landet in derselben Artefakt-Registry wie die SBOMs, die ein Institut für Lieferkettenzwecke bereits erzeugt.

Das wiegt schwerer, als es klingt. Der Unterschied zwischen einem Standard, der sich durchsetzt, und einem, der stecken bleibt, liegt meist darin, ob er neue Infrastruktur verlangt. Dieser tut es nicht.

Tabelle 2: CBOM-Assetklassen und die Migrationsfrage, die jede beantwortet

Assetklasse	Was erfasst wird	Die Frage, die sie beantwortet
Algorithmus	Primitive, Schlüsselgröße, Modus, Kurve, Padding und die ausgeführte Funktion	Welche unserer Operationen sind quantenanfällig, und bei welcher Parameterstärke?
Schlüssel	Typ, Größe, Format, Zustand und Ort des Schlüsselmaterials	Welche Schlüssel schützt ein HSM, und welche liegen im Anwendungsspeicher?
Zertifikat	Subject, Issuer, Signaturalgorithmus, Gültigkeitszeitraum	Was läuft vor dem Migrationsfenster ab, und was ist mit einem veralteten Algorithmus signiert?
Protokoll	Protokoll und Version samt angebotener Cipher Suites	Was wird auf der Leitung tatsächlich ausgehandelt — im Gegensatz zu dem, was die Konfigurationsdatei behauptet?
Zugehörige Komponente	Bibliothek, Version und Codestelle, die das Obige implementieren	Wenn diese Bibliothek ersetzt wird, was zieht mit um?

Die letzte Zeile macht aus einem Inventar einen Plan. Eine Liste von Algorithmen nennt Ihnen die Größe des Problems. Eine Liste von Algorithmen, verknüpft mit den Komponenten, die sie implementieren, nennt Ihnen die Form der Arbeit — und daraus wird eine Migrationssequenz tatsächlich gebaut.

Die Bestandsaufnahme sind vier Probleme, nicht eines

Die Bestandsaufnahme als einen einzigen Arbeitsstrang zu behandeln, ist der häufigste Weg, auf dem diese Programme scheitern. Es sind vier eigenständige Probleme mit vier verschiedenen Werkzeugen, vier verschiedenen Verantwortlichen und sehr unterschiedlichen Konfidenzniveaus.

1. Quellcode — was der Code anfordert. Statische Analyse über die eigenen Repositories findet kryptografische Aufrufe, hartkodierte Parameter und die aufgerufenen Bibliotheken. Offene Werkzeuge existieren: Das Projekt CBOMkit und sein SonarQube-Plugin erkennen kryptografische Assets im Quellcode und geben CycloneDX aus. Höchste Konfidenz, geringste Abdeckung — es sieht nur Code, den Sie geschrieben haben und weiterhin bauen.

2. Binaries und Container — was tatsächlich ausgeliefert wird. Die Quellcodeanalyse übersieht alles, was als kompilierte Abhängigkeit hereinkommt oder in ein Base Image eingebacken ist. Container- und Dateisystem-Scans schließen einen Teil dieser Lücke. Rechnen Sie damit, dass beide Sichten voneinander abweichen; die Abweichung ist selbst ein Befund.

3. Das Netzwerk — was wirklich ausgehandelt wird. Konfiguration ist eine Absicht, keine Beobachtung. Die passive Beobachtung der laufenden TLS-Aushandlung über den gesamten Bestand ist der einzige Weg, um zu erfahren, dass ein Dienst, der TLS 1.3 dokumentiert, gegenüber einer internen Gegenpartei, die nie aktualisiert hat, weiterhin Älteres akzeptiert. In einem Zahlungsverkehrsbestand ist genau diese Gegenpartei oft die entscheidende.

4. Der Anbieter- und Hardwarebestand — was Sie überhaupt nicht scannen können. Hardware-Sicherheitsmodule, Zahlungsterminals, Netzwerk-Appliances, Mainframe-Subsysteme und jeder SaaS-Anbieter in der Kette. Kein Scanner erreicht diese. Dieses Viertel wird erfasst, indem man fragt — vertraglich abgesichert. Dort konzentriert sich das echte Exposure des Wholesale-Banking, weil die Systeme für Clearing und Settlement überproportional von Anbietern geliefert werden.

Mit dem vierten ist jetzt zu beginnen, denn es hat die längste Vorlaufzeit und ist keine Ingenieuraufgabe. Es ist eine Beschaffungsaufgabe: eine Klausel zur kryptografischen Offenlegung und zur Krypto-Agilität in den Vertrag und in die Verlängerungsvorlage zu bringen, damit die Antwort bis 2028 als Lieferantenpflicht eintrifft und nicht als Gefallen. Jedes Quartal, in dem diese Klausel nicht in der Vorlage steht, ist ein Quartal an Verlängerungen, die später wieder aufgemacht werden müssen.

Aus einem Projekt einen Kontrollmechanismus machen

Der Fehlermodus, auf den ich wetten würde, ist nicht, dass Banken das Inventar auslassen. Es ist, dass sie es einmalig beauftragen, 2028 eine verteidigungsfähige Momentaufnahme abliefern und sie verfallen lassen — weil es als Projektergebnis eines Post-Quanten-Vorhabens finanziert und nicht als gepflegter Kontrollmechanismus gebaut wurde.

Ein kryptografisches Inventar verfällt schneller als ein Asset-Register. Zertifikate rotieren. Bibliotheken werden von der Abhängigkeitsautomatisierung angehoben. Ein Base Image ändert sich, und ein ganzer Dienst erhält still einen anderen TLS-Stack. Eine 2028 aufgenommene Momentaufnahme wird 2029 wesentlich falsch sein — genau dann, wenn die Priorisierungsarbeit für 2031 auf ihr aufbaut.

Drei Festlegungen verhindern das.

Erzeugen Sie es in der Pipeline, nicht in einer Umfrage. Ein CBOM sollte vom Build ausgegeben werden, neben dem SBOM, und als versioniertes Artefakt zum Release abgelegt werden. Ein Inventar, das per Fragebogen an Anwendungsverantwortliche zusammengetragen wird, ist bei Eintreffen veraltet und lässt sich nicht diffen.

Diffen Sie es, und alarmieren Sie auf dem Diff. Das wertvolle Signal ist nicht das Inventar, sondern die Veränderung am Inventar. Ein Dienst, der eine neue kryptografische Abhängigkeit erhalten hat, ein Zertifikat mit verkürzter Laufzeit, ein Algorithmus, der auftaucht, wo er vorher nicht war — das sind die Ereignisse, die einen Kontrollmechanismus verdienen. Dieselbe Logik macht das Diffen von SBOMs nützlicher als deren Archivierung.

Verknüpfen Sie es mit dem Register, das Sie ohnehin führen. Das CBOM beantwortet „welche Kryptografie"; das Article 8-Register beantwortet „wie kritisch, wessen, und was hängt daran". Keines von beiden ist für sich eine Priorisierung. Verknüpft ergeben sie das einzige Ranking, das zählt: quantenanfällige Operationen, sortiert nach der Kritikalität der Geschäftsfunktion, die darauf sitzt. Diese Verknüpfung ist das eigentliche Ergebnis eines Programms zur Bestandsaufnahme, und es lohnt sich, sie im Plan auch so zu benennen.

Das operative Playbook

Denken Sie den Meilenstein 2028 als Fähigkeit, nicht als Bericht. Das Ergebnis ist ein gepflegtes, maschinenlesbares Inventar, das sich selbst neu erzeugt — kein Dokument, das einmal für einen Aufseher entsteht.
Geben Sie CBOMs ab sofort aus dem Build aus, zuerst für neue Dienste. Versuchen Sie nicht, den Bestand in einem Durchgang zu erfassen. Verdrahten Sie es in der Pipeline für alles, was in diesem Jahr gebaut oder wesentlich verändert wird, damit die Abdeckung wächst, statt eine Kampagne zu erfordern.
Nehmen Sie die Vertragsklausel noch in diesem Quartal in die Verlängerungsvorlage auf. Kryptografische Offenlegung und eine Zusage zur Krypto-Agilität. Das hat die längste Vorlaufzeit von allem auf der Liste und hängt von keiner Werkzeugentscheidung ab.
Führen Sie die Netzwerkbeobachtung zuerst auf den Zahlungs- und Settlement-Pfaden durch. Dort richtet die Lücke zwischen Konfiguration und Realität den größten Schaden an, und dort konzentrieren sich Legacy-Gegenparteien.
Verknüpfen Sie das CBOM mit dem Article 8-Register und priorisieren Sie auf der Verknüpfung. Veröffentlichen Sie die Rangliste. Sie ist das Artefakt, das ein Ingenieurinventar in ein Vorstandsgespräch über Reihenfolge und Geld übersetzt.
Diffen Sie jede Neuerzeugung und alarmieren Sie auf neuen quantenanfälligen Abhängigkeiten. Ein Inventar ohne Diff ist ein Archiv.

Die Institute, die 2031 komfortabel erreichen, sind nicht diejenigen mit der fortgeschrittensten Sicht auf ML-KEM. Es sind diejenigen, die an jedem beliebigen Morgen und ohne ein Projekt zu beauftragen die Frage beantworten können, wo ihre Kryptografie tatsächlich sitzt.

Häufig gestellte Fragen

Ist ein CBOM etwas anderes als ein SBOM?
Es ist derselbe Dokumenttyp mit anderen befüllten Feldern. Die Unterstützung kryptografischer Assets wurde in CycloneDX überführt, das als ECMA-424 veröffentlicht ist. Ein CBOM validiert damit gegen dasselbe Schema und durchläuft dasselbe Tooling wie ein SBOM. Institute, die bereits SBOMs erzeugen, sind näher dran, als sie üblicherweise annehmen.

Verlangt DORA ein kryptografisches Inventar?
Nicht mit diesen Worten. Article 8 der Regulation (EU) 2022/2554 verlangt Identifikation, Klassifizierung und Dokumentation von IKT-Assets sowie die Kartierung ihrer Konfiguration und Interdependenzen. Kryptografische Eigenschaften gehören nicht zu den Attributen, deren Erfassung er vorschreibt. Deshalb kann ein Article 8-konformes Register eine Frage zur Quantenanfälligkeit nicht beantworten, ohne erweitert zu werden.

Warum muss die Bestandsaufnahme so weit vor der Migration abgeschlossen sein?
Weil sie der Input für die Priorisierung ist. Die NCSC-Leitlinie setzt die Bestandsaufnahme auf 2028 und die Migration höchster Priorität auf 2031, gerade damit ein definiertes Intervall bleibt, um den Bestand zu bewerten und die Arbeit zu sequenzieren. Beides zusammenzuschieben bedeutet, das zu migrieren, was am besten verstanden ist, statt das, was am meisten zählt.

Wie inventarisieren wir Kryptografie in Anbieter-Hardware und SaaS?
Sie scannen sie nicht, Sie verlangen Offenlegung. Hardware-Sicherheitsmodule, Payment-Appliances und Dienstleister müssen von einer vertraglichen Pflicht zur kryptografischen Offenlegung und zur Krypto-Agilität erfasst sein. Weil das an Verlängerungszyklen hängt und nicht am Ingenieuraufwand, hat es die längste Vorlaufzeit im gesamten Programm und sollte zuerst beginnen.

Sollten wir warten, bis das Tooling reift, bevor wir starten?
Nein, und das Tooling-Argument ist meist ein Stellvertreter für das Budget-Argument. Offene Implementierungen geben bereits kryptografische CycloneDX-Inventare aus Quellcode und aus Container-Images aus, und die Spezifikation ist ein verabschiedeter Standard. Die Restriktion für den Meilenstein 2028 ist die Abdeckung und die vertragliche Reichweite, nicht die Verfügbarkeit von Werkzeugen.

Quellen

Europäisches Parlament und Rat der Europäischen Union, 2022. Regulation (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA). Brüssel: Amtsblatt der Europäischen Union. Verfügbar unter: Europäisches Parlament und Rat der Europäischen Union, 2022..
National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. London: NCSC. Verfügbar unter: National Cyber Security Centre, 2025..
National Institute of Standards and Technology, 2024. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. Gaithersburg: U.S. Department of Commerce. Verfügbar unter: National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Gaithersburg: U.S. Department of Commerce. Verfügbar unter: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Verfügbar unter: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Verfügbar unter: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Verfügbar unter: IBM Research, 2026..

Zuletzt überprüft 2026-08-05.

Diesen Artikel republizieren

Nicht erfassbar, nicht migrierbar: Das fehlende CBOM der Banken — Sebastien Rousseau

Die NCSC-Frist zur Bestandsaufnahme 2028 liegt vor jeder Migrationsfrist. Banken können sie nicht halten: Das DORA-Asset-Register erfasst keine Kryptografie.

Dieser Artikel ist lizenziert unter Creative Commons Attribution 4.0 International. Eine Republikation erfordert Attribution zur kanonischen URL.

Nicht erfassbar, nicht migrierbar: Das fehlende CBOM der Banken — Sebastien Rousseau

Die NCSC-Frist zur Bestandsaufnahme 2028 liegt vor jeder Migrationsfrist. Banken können sie nicht halten: Das DORA-Asset-Register erfasst keine Kryptografie.

Originally published at https://sebastienrousseau.com/de/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER