Quantenbereitschaft ist ein Problem der Softwarelieferkette. Eine SBOM zeigt nicht das ganze Risiko

Quantenbereitschaft wird zunehmend zu einem Problem der Softwarelieferkette. Unternehmen müssen Kryptografie in Anwendungen, Build-Systemen, Infrastruktur und bei Zulieferern finden, bevor sie eine Migration zur Post-Quanten-Kryptografie priorisieren können. Eine Software Bill of Materials (SBOM) hilft, Komponenten zu identifizieren. Sie zeigt aber nicht automatisch jeden verwendeten Algorithmus, die ausgehandelte Kryptografie eines Dienstes zur Laufzeit oder die Bereitschaft eines Zulieferers für einen Wechsel.

Am 14. Oktober 2026 veröffentlichte Singapurs Cyber Security Agency (CSA) konkretere Meilensteine für eine quantensichere Migration. Die öffentlich zugänglichen CII-Leitlinien der CSA verpflichten CII-Betreiber, ihren Migrationsplan bis zum 31. März 2027 bei der CSA einzureichen; als Ziel für den Abschluss der Migration gilt der 31. Dezember 2031. Sie besagen außerdem, dass bei der Beschaffung neuer CII-Systeme ab 2028 quantensichere Aspekte berücksichtigt werden müssen. Anderen Organisationen, die einem Quantenrisiko ausgesetzt sind, empfiehlt CSA einen Plan bis Ende 2027 und den Abschluss der Migration bis 2035. Diese Termine beziehen sich auf die Singapurer Leitlinien und ihre jeweiligen Adressaten; sie sind keine globalen Fristen für jedes Unternehmen. Ankündigung der Singapore CSA · CSA-Empfehlung · Öffentliche CII-Leitlinien und Quantum-Safe Kickstarter Grant

Das Signal für die Planung ist eindeutig: Teams brauchen eine belegbare Übersicht über kryptografische Abhängigkeiten, Verantwortliche und Einschränkungen. Der erste Schritt ist die Erfassung – nicht die Behauptung, heutige Verschlüsselung sei bereits gebrochen.

Warum Quantenbereitschaft mit einem Inventar beginnt

Wann ein kryptografisch relevanter Quantencomputer verfügbar sein wird, ist nicht bekannt. Öffentliche Schlüsselverfahren auf Basis von RSA und herkömmlichen elliptischen Kurven gelten gegenüber einem ausreichend leistungsfähigen Quantencomputer als verwundbar. Das bedeutet nicht, dass eine solche Maschine heute bereits eingesetzte Systeme angreift. Unternehmen benötigen dennoch Zeit, um Veränderungen in langlebigen Produkten und bei Zulieferern zu erfassen, zu testen und zu koordinieren. Auch die erforderliche Vertraulichkeitsdauer heute erfasster Daten kann für die Priorisierung wichtig sein.

Eine SBOM ist dafür eine wichtige Grundlage. Sie dokumentiert Softwarekomponenten und ihre Beziehungen. Für sich genommen beweist sie jedoch nicht, welche Algorithmen in der Produktion ausgewählt werden, welche Zertifikate und Schlüssel aktiv sind, wie ein vom Zulieferer betriebenes Gateway konfiguriert ist oder wie schnell die Firmware eines Geräts ersetzt werden kann.

Kryptografie kann an leicht übersehenen Stellen stecken:

• In einer Bibliothek, die JWT-Signaturen prüft oder TLS-Verbindungen aufbaut.
• In einem Cloud-Dienst oder SDK, das Schlüsselverwaltung oder Signaturen an einen verwalteten Anbieter delegiert.
• Bei einem Zahlungs-, Identitäts- oder Messaging-Anbieter mit eigenen Zertifikaten und einem eigenen Umstellungsplan.
• In einer Build-Pipeline, die Pakete, Container oder Software-Updates mit klassischer Public-Key-Kryptografie signiert.
• In VPNs, Firmware, langlebigen Geräten und Hardware-Sicherheitsmodulen, die nicht im Release-Zyklus einer Anwendung aktualisiert werden können.
• In Datenbanken und Service-zu-Service-Verbindungen mit separat verwalteten Protokollen und Konfigurationen.

Die Vorbereitung auf Quantenrisiken ist daher eine gemeinsame Aufgabe von Security, Entwicklung, Einkauf und Lieferantenmanagement. Ein Komponenten-Inventar kann zeigen, wo weitere Prüfungen nötig sind. Laufzeit- und Lieferantennachweise braucht es, um die tatsächliche Exposition zu verstehen.

Welche Kryptografie sollte genauer geprüft werden?

„Quantensicher“ sollte sich auf einen genau definierten Algorithmus und Anwendungsfall beziehen – nicht auf ein ungeprüftes Etikett oder einen einzelnen Score. Eine größere Schlüssellänge bei Public-Key-Kryptografie ändert die Quantenrisiken der zugrunde liegenden Algorithmusfamilie nicht. RSA-4096 bleibt RSA; stärkere klassische elliptische Kurven bleiben klassische elliptische Kurven.

NIST hat FIPS 203, 204 und 205 am 13. August 2024 finalisiert. Es sind etablierte Standards, keine Neuerscheinungen vom Oktober 2026. Die Auswahl eines Standards belegt für sich genommen weder eine sichere Implementierung noch die Migration eines Protokolls oder Systems. NIST-Veröffentlichungen zur Post-Quanten-Kryptografie

Eine Cryptography Bill of Materials (CBOM) kann kryptografische Ressourcen und ihre Beziehungen dokumentieren. Je nach Quelle und Format kann sie Algorithmen, kryptografische Komponenten, schlüsselbezogene Metadaten und den Nutzungskontext erfassen. CycloneDX veröffentlicht Informationen zu einer CBOM-Funktion und ihrer Spezifikation. Eine CBOM ist ein Inventarartefakt – kein Beleg dafür, dass das Inventar vollständig oder ein System quantensicher ist. CycloneDX CBOM-Funktion

Was die Meilensteine von 2027 bis 2035 bedeuten

Die Ankündigung und Empfehlung der Singapore CSA unterscheiden zwischen CII-Betreibern und anderen Organisationen, die einem Quantenrisiko ausgesetzt sind:

• Einreichung des CII-Migrationsplans bis 31. März 2027: CII-Betreiber müssen ihren Plan laut den öffentlichen CII-Leitlinien bis zu diesem Datum bei der CSA einreichen.
• Ab 2028: Bei der Beschaffung neuer CII-Systeme müssen quantensichere Aspekte berücksichtigt werden. Öffentliche CII-Leitlinien und Förderprogramm der CSA
• CII-Migration bis 31. Dezember 2031: Dies ist das genannte Ziel für den Abschluss der Migration der CII-Systeme.
• Andere exponierte Organisationen: CSA empfiehlt einen Migrationsplan bis Ende 2027 und die Migration bis 2035.

Das britische National Cyber Security Centre (NCSC) veröffentlicht eigene Leitlinien-Ziele: Erfassung und Bewertung abschließen und bis 2028 einen ersten Plan erstellen; bis 2031 Migration priorisieren und voranbringen; bis 2035 die Migration über Systeme, Dienste und Produkte hinweg anstreben. Das NCSC weist darauf hin, dass eine kleine Zahl selten genutzter Technologien bis 2035 schwieriger zu migrieren sein könnte. Organisationen sollten trotzdem auf die genannten Termine hinarbeiten. Das sind britische Leitlinien und keine globale Gesetzgebung. Unternehmen sollten prüfen, welche lokalen Vorgaben, Branchenregeln und vertraglichen Verpflichtungen tatsächlich gelten. UK NCSC: Zeitplan für die PQC-Migration

NISTs IR 8547 zur Umstellung ist mit Stand vom 16. Oktober 2026 ein Entwurf. Er sollte nicht als endgültige pauschale gesetzliche Frist für Privatunternehmen dargestellt werden. NIST-Entwurf IR 8547

Die praktische Lehre ist, früh mit der Erfassung zu beginnen. Eine Migration kann Anwendungsverantwortliche, Protokollkompatibilität, Hardware-Erneuerungszyklen, Zulieferer und Kundenverpflichtungen betreffen. Der Austausch einer einzelnen Bibliothek kann der kleinste Teil der Arbeit sein.

Von Komponentenlisten zu verbundenen Inventaren

CycloneDX unterstützt bereits CBOMs. Version 1.6 führte die CBOM-Funktion ein; Version 1.7 ergänzte Kennungen für kryptografische Algorithmusfamilien und elliptische Kurven. Am 5. August 2026 kündigte das Projekt Pläne für CycloneDX 2.0 an. Vorgesehen sind unter anderem Möglichkeiten, kryptografische Ressourcen mit Migrationsrisiken, Maßnahmen, Verantwortlichen, Zielterminen und Status zu verknüpfen.

Mit Stand vom 16. Oktober 2026 ist CycloneDX 2.0 angekündigt und wird für später im Herbst 2026 erwartet; die Version ist noch nicht veröffentlicht oder ratifiziert. Behauptungen über aktuelle Produktfunktionen oder Compliance sollten daher keine angenommene Unterstützung für 2.0 voraussetzen. Ankündigung CycloneDX 2.0 · CycloneDX CBOM

Ein erweitertes Inventar kann drei verschiedene Fragen miteinander verbinden:

1. SBOM: Welche Softwarekomponenten, Versionen, Zulieferer und Abhängigkeiten gehören zum Produkt?
2. CBOM: Welche kryptografischen Algorithmen und Kontexte müssen bewertet oder umgestellt werden?
3. AIBOM: Welche KI-Modelle, Anbieter und zugehörigen Komponenten gehören zum Produkt?

Das sind ergänzende Inventare, keine austauschbaren Sicherheitsgarantien. Eine Extended Bill of Materials (XBOM) ist ein Ansatz, um sie zu organisieren und miteinander zu verknüpfen. Der tatsächliche Inhalt und die Abdeckung hängen weiterhin davon ab, was erfasst und wie es klassifiziert wurde und welche externen Nachweise vorliegen.

CISA und Partnerbehörden veröffentlichten am 8. September 2026 die 2026 Minimum Elements for an SBOM. Die Veröffentlichung aktualisiert empfohlene Mindestangaben und empfiehlt, SBOMs bei Softwareänderungen zu pflegen. Sie schafft für sich genommen keine neuen Anforderungen. Unternehmen sollten diese Leitlinien von Pflichten unterscheiden, die sich aus anwendbaren Gesetzen, Vorschriften, Verträgen oder Branchenregeln ergeben. CISA und Partnerbehörden: SBOM-Mindestangaben 2026

Andere Lieferkettendaten sind hilfreicher Kontext, aber kein Beleg für Quantenangriffe. Sonatypes Q3-Bericht vom 8. Oktober 2026 erfasste insgesamt 149.329 markierte Pakete in den Kategorien „schädlich“ und „unerwünscht“; bei 27.618 Paketen wurde mindestens ein eindeutig bösartiges Verhalten festgestellt. Die Gesamtzahl der markierten Pakete bedeutet nicht, dass alle 149.329 als Malware bestätigt wurden. Diese Zahlen sprechen allgemein für Komponentenverfolgung und Folgenabschätzung. Sie berichten nicht von Quantenangriffen oder Fehlern bei der Kryptografiemigration. Sonatype Q3 2026

Ein Inventar erstellen, das Entscheidungen unterstützt

Für jede wichtige kryptografische Ressource sollten genügend Nachweise erfasst werden, um praktische Fragen zu beantworten:

Krypto-Agilität beschreibt die Fähigkeit, kryptografische Verfahren über Anwendungen, Protokolle, Hardware und Infrastruktur hinweg mit vertretbarem Betriebsrisiko zu ändern. NISTs Whitepaper zur Krypto-Agilität, CSWP 39 Revision 1, wurde am 29. Juni 2026 finalisiert; die Originalfassung erschien im Dezember 2025. Es enthält Planungshinweise, aber weder eine Zertifizierung noch einen Beleg dafür, dass eine bestimmte Organisation agil ist. NIST CSWP 39 Revision 1

Vermeiden Sie Scheingenauigkeit. Ein „Quantenbereitschafts-Prozentsatz“ sagt wenig aus, wenn Umfang, validierte Klassifizierung, Abdeckungsnachweise, Kritikalität und nicht untersuchte Bereiche unklar sind. Ein Code-Scan kann nicht den Zustand jedes Laufzeitzertifikats, Hardware-Sicherheitsmoduls, verwalteten Dienstes oder Lieferantensystems belegen. Prüfen Sie Algorithmusklassifizierungen anhand der NIST-Referenzen und ergänzen Sie Inventare um Laufzeit-, Konfigurations- und Lieferantennachweise.

Ein praktischer 90-Tage-Startplan

Tage 1–15: Verantwortung festlegen und Umfang wählen

Benennen Sie eine Programmverantwortung und wählen Sie einen repräsentativen, geschäftskritischen Dienst oder ein Produkt. Erfassen Sie die Speicherdauer der Daten, Anwendungsfälle für Signaturen und Schlüsselaustausch, Netzwerkschnittstellen, den Release-Prozess und die wichtigsten Zulieferer. Grenzen Sie den Umfang ab, damit sich das erste Inventar prüfen lässt.

Tage 16–30: Erste Nachweise sammeln

Erheben Sie Softwareinventare und verfügbare Kryptografieangaben aus Quellcode, Build-Systemen, Konfigurationen und Infrastrukturunterlagen. Dokumentieren Sie Algorithmen und Versionen, Zertifikats- und Schlüsselreferenzen, sofern dies sicher möglich ist, Systemkontext, Vertrauensgrenzen und Lieferantenabhängigkeiten. Kennzeichnen Sie unbekannte oder nicht beobachtete Bereiche ausdrücklich.

Tage 31–45: Nach möglichen Folgen priorisieren

Berücksichtigen Sie sensible Daten, die noch Jahre vertraulich bleiben müssen, extern erreichbare Dienste, Signaturinfrastruktur, kritische Abhängigkeiten sowie schwer aktualisierbare Geräte oder Firmware. Behandeln Sie RSA und herkömmliche ECC als quantenverwundbare Public-Key-Kryptografie, auch wenn sie heute für klassische Sicherheit geeignet sein können.

Tage 46–60: Zulieferer einbeziehen

Fragen Sie, welche Produkte und Dienste Public-Key-Kryptografie einsetzen, wie der Anbieter Post-Quanten- oder gegebenenfalls hybride Umstellungen unterstützt, welche Änderungen Kunden vornehmen müssen und wie Interoperabilitätstests und Meilensteine kommuniziert werden. Halten Sie Antworten und Nachweise fest; leiten Sie Bereitschaft nicht allein aus Marketingaussagen ab.

Tage 61–75: In kontrollierten Umgebungen testen

Erproben Sie ausgewählte Änderungen am Schlüsselaustausch oder an Signaturen in Nicht-Produktionssystemen. Prüfen Sie Interoperabilität, Latenz, Zertifikats- und Signaturgrößen, Leistung, Fallback-Verhalten, Monitoring und Rollback. Lassen Sie relevante Entwicklungs- und Security-Verantwortliche die Ergebnisse prüfen.

Tage 76–90: Eine Roadmap veröffentlichen

Überführen Sie Ergebnisse in Verantwortliche, Nachweislücken, Abhängigkeiten, Vertrauensgrade und priorisierte Meilensteine. Verknüpfen Sie jeden Meilenstein mit einem System und einer Prüfmethode. Aktualisieren Sie Inventare, wenn sich Software, Kryptografiekonfiguration oder Zulieferer ändern.

Warten Sie nicht auf perfekte Abdeckung, bevor Sie die folgenreichsten Risiken angehen. Arbeiten Sie iterativ und risikobasiert und kennzeichnen Sie die Grenzen des Vorgehens.

Welche Rolle Plexicus XBOM spielen kann

Die öffentliche XBOM-Seite von Plexicus stellt SBOM, CBOM und AIBOM in einem Workflow dar und bietet die Möglichkeit, eine Produktvorstellung anzufragen. Das kann ein Ausgangspunkt für Teams sein, die verbundene Inventare untersuchen. Es ist kein Nachweis für vollständige Kryptografieerfassung, korrekte Quantenklassifizierung, Laufzeit- oder Hardwareabdeckung, Lieferantenprüfung, abgesicherte PQC-Migration oder Compliance.

Bevor Sie ein Inventarwerkzeug für Migrationsentscheidungen heranziehen, prüfen Sie Umfang und Klassifizierung anhand der NIST-Referenzen. Ergänzen Sie codebasierte Ergebnisse durch Laufzeit- und Konfigurationsprüfungen, Lieferantennachweise und Tests in den betroffenen Systemen.

Beginnen Sie mit einem klaren Bild dessen, was Sie haben – und was noch unbekannt ist.

Plexicus XBOM ansehen und eine Produktvorstellung anfragen →

Die Quantenfrage ist heute eine Planungsfrage

Es gibt keinen Nachweis dafür, dass ein kryptografisch relevanter Quantencomputer derzeit übliche Public-Key-Systeme bricht. Die unmittelbare Aufgabe lautet: feststellen, welche Systeme quantenverwundbare Kryptografie nutzen, wo Informationen fehlen und wie lange Bewertung und Migration dauern werden.

Eine SBOM schafft eine wertvolle Komponentenbasis. Eine CBOM kann kryptografische Ressourcen beschreiben, wenn Erfassung und Klassifizierung geeignet sind. Eine XBOM kann Software-, Kryptografie- und KI-Inventare miteinander in Beziehung setzen. Keine davon ersetzt Laufzeittests, Lieferantenabstimmung, technische Verantwortung oder einen Migrationsplan.

Quantenbereitschaft beginnt als Inventarisierungs- und Governance-Programm. Der Plan sollte Umfang, Nachweise, Unsicherheiten, Verantwortliche und lokal geltende Meilensteine sichtbar machen.

Plexicus-XBOM-Produktvorstellung anfragen →

Häufig gestellte Fragen

Ist RSA-4096 quantensicher?

Nein. Ein größerer Schlüssel ändert die RSA-Algorithmusfamilie nicht. RSA – auch RSA-4096 – und herkömmliche Public-Key-Kryptografie auf Basis elliptischer Kurven gelten gegenüber einem ausreichend leistungsfähigen Quantencomputer als verwundbar.

Ist eine CBOM für eine Post-Quanten-Migration gesetzlich vorgeschrieben?

Es gibt keine globale Regel, die jede Organisation zur Erstellung einer CBOM in einem bestimmten Format verpflichtet. Anforderungen hängen von Land, Branche, Verträgen und anwendbaren Vorschriften ab. Ein strukturiertes Kryptografie-Inventar hilft bei der Planung; die tatsächlich geltenden Pflichten sollten separat geprüft werden.

Kann eine SBOM oder CBOM allein Quantenbereitschaft belegen?

Nein. Das Inventar braucht einen geeigneten Umfang und korrekte Klassifizierungen. Anschließend muss es mit Laufzeitkonfiguration, Hardware- und Lieferantennachweisen abgeglichen werden. Tests, Priorisierung und eine Migrations-Roadmap sind ebenfalls nötig.

Wurde CycloneDX 2.0 bereits veröffentlicht?

Mit Stand vom 16. Oktober 2026 wird CycloneDX 2.0 als bevorstehend beschrieben. Unternehmen sollten weder eine allgemeine Veröffentlichung noch die Unterstützung durch ein bestimmtes Produkt voraussetzen. CycloneDX 1.7 ist die jüngste in den öffentlichen Projektmaterialien erwähnte 1.x-Version.

Welche NIST-Standards für Post-Quanten-Kryptografie sind final?

NIST finalisierte FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) am 13. August 2024. Auswahl und Einsatz erfordern weiterhin systembezogene Entwicklung, Implementierung und Tests.

Sind Singapurs Meilensteine 2031 und 2035 globale Fristen?

Nein. Sie sind CSA-Meilensteine für CII-Betreiber und Empfehlungen für andere Organisationen, die einem Quantenrisiko ausgesetzt sind. Das UK NCSC veröffentlicht separate Leitlinien-Ziele. Die Anwendbarkeit hängt von Land, Branche, Verträgen und Organisation ab.

Garantiert Plexicus XBOM eine PQC-Migration oder Compliance?

Nein. Die öffentliche Produktseite stellt SBOM, CBOM und AIBOM in einem Workflow dar und lädt zu einer Produktvorstellung ein. Das belegt weder vollständige Erfassung noch korrekte Algorithmusklassifizierung, Laufzeit- oder Lieferantenabdeckung, erfolgreiche Migration oder Compliance.

Quellen

• Singapore CSA, Ankündigung zum Zeitplan der quantensicheren Migration und zur Förderung, 14. Oktober 2026.
• Singapore CSA, Advisory on Quantum-Safe Migration for Organisations, 14. Oktober 2026.
• Singapore CSA, Quantum-Safe Kickstarter Grant und Beschaffungsinformationen.
• UK NCSC, Zeitplan für die PQC-Migration.
• NIST, Veröffentlichungen und Standards zur Post-Quanten-Kryptografie.
• NIST, CSWP 39 Revision 1: Considerations for Achieving Crypto Agility, finalisiert am 29. Juni 2026.
• NIST, IR 8547 – erster öffentlicher Entwurf.
• Canadian Centre for Cyber Security und G7-Partner, Preparing for the Post-Quantum Era, September 2026.
• CycloneDX, CBOM-Funktion und Ankündigung zu CycloneDX 2.0.
• CISA und Partnerbehörden, 2026 Minimum Elements for an SBOM, 8. September 2026.
• Sonatype, Q3 2026 Open Source Malware Index, 8. Oktober 2026.
• Plexicus, XBOM.