PQC-Migration: Was Sie erst nach dem Start entdecken

Kurz gesagt: Sobald eine PQC-Migration tatsächlich angelaufen ist, stoßen Unternehmen auf Herausforderungen, die in Frameworks und Whitepapers von Anbietern selten berücksichtigt werden: Die Migrationsfläche ist weitaus größer als jede Bestandsaufnahme der vorhandenen Ressourcen (PKI, Firmware, TLS, SSH, Codesignierung, HSMs, eingebettete Geräte). Die deutlich größeren Schlüssel und Signaturen von PQC stoßen an die Grenzen von Firewalls und Middleboxes mit festen Pufferkapazitäten. Zudem wird die PKI-Modernisierung zu einer frühen Voraussetzung und nicht zum letzten Schritt, da Zertifizierungsstellen, HSMs und Registrierungsprozesse neue Algorithmen unterstützen müssen, bevor andere Prozesse skaliert werden können. Dies ist relevant, da große Unternehmen mit einer Migrationsdauer von mehreren Jahren rechnen müssen, in komplexen Umgebungen sogar mit über einem Jahrzehnt. Gleichzeitig schreibt CNSA 2.0 vor, dass neue Beschaffungen von nationalen Sicherheitssystemen ab dem 1. Januar 2027 quantenresistente Algorithmen unterstützen müssen. Es wird empfohlen, die Analyse und Migration parallel statt sequenziell durchzuführen, frühzeitig eine zentrale Führungskraft mit entsprechender Verantwortung zu etablieren, Anbieter jetzt in die PQC-Roadmaps und Vertragsfristen einzubinden und Krypto-Agilität als permanente operative Fähigkeit und nicht als einmalige Leistung für diesen Übergang zu betrachten.

Wichtige Erkenntnisse

• Der Größen-Overhead von PQC unterscheidet sich grundlegend von früheren Übergängen: Ein ML-KEM-768-öffentlicher Schlüssel ist etwa 37-mal größer als ein X25519-Schlüssel, und eine ML-DSA-65-Signatur ist etwa 51-mal größer als eine ECDSA-Signatur, was zu realen Ausfällen bei Firewalls, Middleboxes und ressourcenbeschränkten IoT-Geräten wie LoRaWAN führt.
• Keine einzelne Erkennungsmethode erfasst die gesamte kryptografische Oberfläche: Netzwerkscans erfassen eingebettete Kryptografie nicht, Codeanalysen erfassen die Laufzeitkonfiguration nicht, und agentenbasierte Tools können weder OT- noch Drittanbieterinfrastrukturen erreichen. Daher sollten Erkennung und Migration parallel und nicht sequenziell erfolgen.
• Governance-Mängel verzögern die Migration oft schon vor Beginn der technischen Arbeiten: Wenn die Verantwortung für die Kryptografie auf verschiedene Bereiche wie Sicherheit, IT, Anwendungsteams, Beschaffung und OT verteilt ist und es keine einzelne verantwortliche Führungskraft gibt, geraten Entscheidungen ins Stocken.
• Die Modernisierung der PKI ist häufig eine frühe Voraussetzung und kein Schritt in einem späteren Stadium, da Zertifizierungsstellen, HSMs, Lebenszyklusmanagement-Plattformen und Registrierungsworkflows alle neue Algorithmen unterstützen müssen, bevor Zertifikate in großem Umfang ausgestellt werden können.
• Krypto-Agilität ist eine kontinuierliche operative Fähigkeit, kein Ergebnis einer Migration: Organisationen, die sie nur für diesen PQC-Übergang aufbauen, bleiben für die nächste kryptografische Veränderung, egal was diese antreibt, schlecht gerüstet.

Was die PQC-Migration tatsächlich beinhaltet

Die Migration zur Post-Quanten-Kryptographie (PQC) ist der Prozess, bei dem quantenanfällige Public-Key-Kryptographieverfahren wie RSA, ECDH, ECDSA und verwandte Schemata durch NIST -standardisierte Post-Quanten-Algorithmen ersetzt werden, darunter ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205). Sie umfasst die kryptografische Ermittlung , die risikobasierte Priorisierung, den hybriden Einsatz während der Übergangsphase und die langfristige operative Fähigkeit, Algorithmen im Zuge der Weiterentwicklung von Standards zu rotieren.

Im Gegensatz zu früheren Algorithmusübergängen erstreckt sich die PQC-Migration auf alle Ebenen eines Unternehmens: PKI, Firmware, TLS, SSH, Codesignierung, HSMs und eingebettete Geräte.

Die meisten Organisationen, die eine PQC-Migration anstreben, verfügen über ein mentales Modell, das auf Konferenzpräsentationen, Whitepapers von Anbietern und Framework-Zusammenfassungen basiert. Diese Quellen sind nicht falsch, beschreiben aber das Ziel, nicht den Weg dorthin. Die Kluft zwischen dem Lesen von Informationen über eine PQC-Migration und deren praktischer Durchführung ist größer als bei fast jedem vergleichbaren Übergang in der Geschichte der Unternehmenssicherheit.

Die regulatorischen Rahmenbedingungen lassen keine Option mehr zum Abwarten zu, und die Bedrohungslage erklärt, warum dieses Abwarten von vornherein nie sicher war. Angreifer können bereits heute verschlüsselten Datenverkehr abfangen und speichern, um ihn zu entschlüsseln, sobald ein kryptografisch geeigneter Quantencomputer verfügbar ist. Bei Daten, die mehrjährige Vertraulichkeitsanforderungen erfüllen müssen, ist diese Gefahr bereits jetzt, nicht erst in der Zukunft, gegeben.

Gemäß NSA CNSA 2.0 müssen Neubeschaffungen von Systemen der nationalen Sicherheit ab dem 1. Januar 2027 quantenresistente Algorithmen unterstützen. Die Software- und Firmware-Signatur in den betroffenen Systemen muss bis 2030 ausschließlich über PQC erfolgen. Ältere Netzwerkgeräte, die CNSA 2.0 nicht unterstützen, müssen bis 2030 außer Betrieb genommen werden.

Das australische Informationssicherheitshandbuch (ISM) empfiehlt, die Verwendung klassischer asymmetrischer Kryptografie, einschließlich RSA, DH, ECDH und ECDSA , bis Ende 2030 einzustellen. Europäische Regulierungsbehörden und Institutionen integrieren zunehmend die Planung von Prozessqualitätskontrollsystemen (PQC) und Aspekte der Krypto-Agilität in ihre Leitlinien zur Cybersicherheit und ihre Initiativen zur Stärkung der Resilienz. Diese Zeitvorgaben verkürzen sich, anstatt sich zu verlängern.

Was oft weniger sichtbar ist als die Fristen selbst, ist der Umfang des organisatorischen und technischen Aufwands, der für eine erfolgreiche Migration erforderlich ist. Viele große Unternehmen rechnen damit, dass die Migration mehrere Jahre und in komplexen Umgebungen sogar mehr als ein Jahrzehnt dauern wird. Diese Diskrepanz zwischen verfügbarer und benötigter Zeit ist die zentrale Herausforderung für PQC im Jahr 2026.

Dieser Blog behandelt die Erfahrungen von Praktikern, sobald ein PQC-Migrationsprogramm angelaufen ist: die Realitäten, die in Rahmenwerken zu kurz zusammengefasst und von Anbietern nur selten erwähnt werden.

Die Migrationsfläche ist größer als Ihr Anlagenbestand.

Das NIST finalisierte FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) im August 2024. Ein Großteil der Unternehmensinfrastruktur basiert auf Public-Key-Algorithmen, die durch die PQC-Standards ergänzt oder ersetzt werden sollen. Diese Algorithmen bilden die Grundlage für Technologien und Vertrauenssysteme im gesamten Unternehmen, darunter Hardware-Roots of Trust, Firmware-Signierung, Secure Boot, TLS, SSH, IPsec, S/MIME, Codesignierung, Hardware-Software-Module (HSMs) und IoT-Attestierung.

Der häufigste Vergleich ist der zwischen SHA -1 und SHA-2. Dieser Vergleich ist jedoch irreführend. SHA-2 war lediglich ein Austausch der Hash-Funktion innerhalb derselben mathematischen Familie. PQC hingegen verändert die zugrundeliegende Mathematik grundlegend. Ein öffentlicher Schlüssel nach ML-KEM-768 ist 1,184 Byte groß, im Vergleich zu 32 Byte bei X25519 – ein Faktor von etwa 37. Eine ML-DSA-65-Signatur umfasst 3,309 Byte, im Vergleich zu 64 Byte bei ECDSA – ein Faktor von etwa 51. Diese Zahlen basieren auf mittleren Parametersätzen und dienen lediglich der Veranschaulichung.

CNSA 2.0 schreibt ML-KEM-1024 und ML-DSA-87 vor, die noch größere Schlüssel und Signaturen erzeugen und dadurch den Speicherbedarf in realen NSS-Implementierungen erhöhen. Infolgedessen kann eine mit ML-DSA-Signaturen und öffentlichen Schlüsseln erstellte Zertifikatskette leicht 10 KB überschreiten.

Diese Größenunterschiede führen in produktionsnahen Umgebungen zu tatsächlichen Fehlern. Firewalls mit festen Pufferzuweisungen verwerfen zu große ClientHello-Nachrichten. Middleboxes, die TLS-Erweiterungsfelder analysieren, können die neuen Größen nicht verarbeiten. Das Wachstum des PQC-Handshakes kann den Fragmentierungsdruck erhöhen und Probleme für Protokolle wie QUIC verursachen. Diese Probleme treten selten bei einem einzelnen, isoliert getesteten Produkt auf.

Sie treten in verschiedenen Browsern, Betriebssystemen, Load Balancern, HSMs, TLS-Prüfgeräten, VPNs, Zertifizierungsstellen und Drittanbieterintegrationen auf. Daher wird die Interoperabilitätsprüfung oft zu einem wesentlichen Bestandteil des Migrationsprozesses und nicht zu einem abschließenden Validierungsschritt.

Viele ressourcenbeschränkte Geräte können aufgrund von Speicher-, Rechen- oder Bandbreitenbeschränkungen Schwierigkeiten bei der Unterstützung von PQC-Algorithmen haben. LoRaWAN, ein stromsparendes Weitverkehrsnetzprotokoll, das in industriellen und Smart-City-IoT-Anwendungen weit verbreitet ist, erlaubt in der EU selbst bei der konservativsten Datenrateneinstellung nur etwa 51 Byte pro Uplink-Nutzlast. Allein der ML-KEM-768-Chiffretext umfasst 1,088 Byte. Für Geräte in Stromnetzen, Wasserversorgungssystemen oder Krankenhausausrüstung handelt es sich hierbei nicht um ein Problem der Softwarekonfiguration, sondern um ein Problem des Hardwareaustauschs im Hinblick auf den jahrzehntelangen Lebenszyklus dieser Anlagen.

Die Grundlagen, die die meisten Organisationen unterschätzen

Die meisten Unternehmen beginnen eine kryptografische Migration, ohne einen vollständigen Überblick über ihre kryptografische Infrastruktur zu haben. Gartner stellt fest, dass die meisten IT-Organisationen nicht wissen, welche kryptografischen Lösungen sie einsetzen, welche Anwendungen sie verwenden, wie sie konfiguriert sind und wer die Entscheidungen darüber trifft. Keine einzelne Ermittlungsmethode kann alle Aspekte erfassen.

Netzwerkscans erfassen TLS-Handshakes, übersehen aber eingebettete Kryptografie. Codeanalysen finden Bibliotheksaufrufe, können aber die Laufzeitkonfiguration nicht einsehen. Agentenbasierte Tools decken die verwaltete IT ab, können aber nicht auf OT- oder Drittanbieterinfrastruktur zugreifen.

Externe Scans erfassen lediglich den öffentlichen Bereich und bieten Einblick in einen relativ kleinen Teil der gesamten kryptografischen Infrastruktur einer Organisation. Die praktische Lösung besteht darin, Erkennung und Migration parallel durchzuführen, dabei nach außen gerichtete Systeme zu priorisieren und den Bestand bei Systemänderungen kontinuierlich zu aktualisieren, anstatt einen Scan zu einem bestimmten Zeitpunkt als abgeschlossenes Ergebnis zu betrachten.

Governance-Schwächen verzögern häufig die Modernisierung der Kryptografie, noch bevor die eigentlichen technischen Arbeiten beginnen. Die Verantwortung für Kryptografie ist typischerweise auf verschiedene Bereiche wie Sicherheit, IT-Betrieb, Anwendungsteams, Beschaffung und OT verteilt, sodass keine einzelne Gruppe für die Ergebnisse verantwortlich ist. Bei dieser fragmentierten Zuständigkeit verzögern sich Entscheidungen, da die Teams über Prioritäten, Budgets und Verantwortlichkeiten diskutieren.

Programme erzielen eher Fortschritte, wenn eine einzelne Führungskraft verantwortlich ist, die Finanzierung klar geregelt ist und die beteiligten Teams ein formelles Mandat erhalten. Organisationen, die bereits mit dem Aufbau dieser Führungsstruktur begonnen haben, verschaffen sich die nötige Zeit, um die anstehenden technischen und operativen Herausforderungen zu bewältigen.

Die Bereitschaft der Lieferanten stellt einen damit verbundenen Druckpunkt dar. Wenn Unternehmen ihre wichtigsten Lieferanten nach einer Roadmap für PQC-Produkte mit Lieferterminen fragen, stellen sie oft fest, dass diese Pläne noch in der Entwicklung sind oder noch nicht vollständig ausgearbeitet wurden. Der Austausch eines Lieferanten für ein kritisches System dauert selbst unter optimalen Bedingungen zwei bis drei Jahre. Unternehmen, die diese Gespräche jetzt beginnen und PQC-Support-Zeitpläne in Vertragsverlängerungen aufnehmen, werden im fünften Jahr eines siebenjährigen Programms keinen Engpass bei den Lieferanten feststellen.

Der PKI-Flaschenhals

Viele Organisationen gehen davon aus, dass die Migration zu Post-Quanten-Zertifikaten (PQC) mit der Implementierung von Post-Quanten-Algorithmen in Produktionsanwendungen beginnt. In der Praxis setzt der Übergang jedoch oft schon viel früher im Bereich der Public-Key- Infrastruktur (PKI) ein . Zertifizierungsstellen, HSMs, Plattformen für das Zertifikatslebenszyklusmanagement, Codesignierungsdienste, Truststores und Registrierungsworkflows müssen alle neue Algorithmen unterstützen, bevor Zertifikate in großem Umfang ausgestellt und verwaltet werden können.

Die Unterstützung von PQC-Algorithmen allein reicht nicht aus. Zertifikatvorlagen, Ausstellungsworkflows, Validierungsdienste, Überwachungsplattformen, TLS-Prüfgeräte und Automatisierungspipelines für Zertifikate müssen möglicherweise getestet und angepasst werden. Unternehmen stellen häufig fest, dass die PKI-Infrastruktur zu einer kritischen Voraussetzung für die umfassendere Migration wird, wodurch die Modernisierung der PKI zu den ersten Voraussetzungen für eine großflächige Implementierung zählt.

Der Unterschied zwischen dem Überstehen des Übergangs und dessen Aufrechterhaltung

Der Einsatz hybrider Kryptografie während der Übergangsphase, bei der klassische Algorithmen mit NIST-standardisierten PQC-Algorithmen wie ML-KEM und X25519 kombiniert werden, ist gut unterstützt und angemessen. Eine durch beide Algorithmen geschützte Sitzung bleibt sicher, solange mindestens einer der beiden Algorithmen gültig ist. Was in den Richtlinien oft unterschätzt wird, ist der operative Mehraufwand. Die Fragmentierung der staatlichen Regulierungsbehörden bedeutet, dass dieselbe Konfiguration die Anforderungen einer Regulierungsbehörde erfüllen, während sie bei einer anderen im Widerspruch stehen kann.

Die Leitlinien des Bundesamts für Sicherheit in der Informationstechnik (BSI) befürworten im Allgemeinen hybride Ansätze während des Übergangs. Im Gegensatz dazu schreibt das australische ISM die Migration zu ASD-zugelassenen Post-Quanten-Algorithmen vor. Laut ISM-1996 werden hybride klassische-PQC-Verfahren zwar nicht verboten, aber nicht empfohlen. Bei der Migrationsplanung müssen neben den technischen Anforderungen auch die geltenden regulatorischen Vorgaben berücksichtigt werden.

Krypto-Agilität ist die organisatorische und technische Fähigkeit, kryptografische Algorithmen systemübergreifend zu aktualisieren, zu ersetzen oder zu rotieren, ohne die Systeme selbst neu zu gestalten. Sie ist keine einmalige Migrationsaufgabe, sondern eine kontinuierliche operative Fähigkeit. Eine für Krypto-Agilität konzipierte Architektur muss die Konfiguration je nach Zuständigkeitsbereich unterstützen, kryptografische Entscheidungen durch Richtlinienkontrollen abstrahieren und SOC-Erkennungsregeln für hybride Downgrade-Angriffe beinhalten, bevor eine hybride Bereitstellung produktiv eingesetzt wird.

Das NIST finalisiert außerdem zusätzliche Signaturverfahren, die über die drei Standards von 2024 hinausgehen. FIPS 206, standardisiert als FN-DSA und basierend auf FALCON, wurde im August 2025 zur Genehmigung als Entwurf eingereicht; die endgültige Fassung des Standards wird Ende 2026 oder Anfang 2027 erwartet. HQC wurde im März 2025 als zusätzliches codebasiertes KEM ausgewählt und befindet sich im Standardisierungsprozess.

Quantencomputing ist nur ein Faktor für den Wandel in der Kryptographie. Schwachstellen in Algorithmen, Implementierungsfehler, Fortschritte in der Kryptoanalyse, regulatorische Anforderungen und sich entwickelnde Sicherheitsstandards können allesamt kryptographische Umstellungen erforderlich machen. Die Fähigkeit, Algorithmen schnell als Reaktion auf eine neu entdeckte Schwachstelle zu ersetzen, unterscheidet sich grundlegend von der Durchführung eines geplanten, mehrjährigen Migrationsprogramms.

Organisationen, die Krypto-Agilität als temporäre Fähigkeit für die PQC-Migration betrachten, können zwar den aktuellen Übergang erfolgreich abschließen, sind aber für den nächsten schlecht gerüstet. Organisationen, die in Krypto-Agilität als dauerhafte operative Fähigkeit investieren, reduzieren hingegen Kosten, Risiken und Störungen zukünftiger kryptografischer Übergänge – unabhängig von deren Ursachen.

Wie Verschlüsselungsberatung helfen kann

Organisationen, die mit einer PQC-Migration beginnen, stellen schnell fest, dass die Herausforderung über die Algorithmusauswahl hinausgeht. Der Erfolg hängt davon ab, zu verstehen, wo Kryptografie vorhanden ist, die Auswirkungen quantenanfälliger Systeme zu bewerten, sich mit Anbietern abzustimmen, die PKI-Infrastruktur zu modernisieren und die operativen Fähigkeiten aufzubauen, die für zukünftige kryptografische Übergänge erforderlich sind.

PQC-Beratungsdienste

Encryption Consulting unterstützt Unternehmen auf diesem Weg mit umfassenden PQC-Migrationsdiensten, die die Bereiche Ermittlung, Bewertung, Planung, Validierung und Implementierung abdecken.

Unsere PQC-Beratungsleistungen unterstützen Unternehmen bei der Identifizierung von Zertifikaten, Schlüsseln, Algorithmen, Protokollen und kryptografischen Abhängigkeiten in Cloud-Umgebungen, Anwendungen, Infrastrukturen, HSMs, Quellcode-Repositories, Containern, APIs und CI/CD-Pipelines . Mithilfe dieser Transparenz bewerten wir die Gefährdung durch quantenanfällige Kryptografie, identifizieren prioritäre Sanierungsbereiche und entwickeln risikobasierte Migrationspläne, die den NIST-Standards, regulatorischen Anforderungen und Geschäftszielen entsprechen.

Über die Planung hinaus unterstützt Encryption Consulting bei der Bewertung der Bereitschaft von Anbietern, der Validierung von Machbarkeitsstudien, Interoperabilitätstests, der Implementierung hybrider Kryptografie, dem Design kryptoagiler PKI-Architekturen und der Durchführung unternehmensweiter Implementierungsprogramme. Dieser strukturierte Ansatz ermöglicht es Unternehmen, von fragmentierter kryptografischer Transparenz zu einem kontrollierten, messbaren und nachhaltigen PQC-Migrationsprogramm überzugehen.

CBOM Secure

Ein erfolgreicher Übergang zur Post-Quanten-Technologie beginnt mit Transparenz. CBOM Secure von Encryption Consulting ermöglicht die kontinuierliche Erkennung und Inventarisierung kryptografischer Assets in der gesamten Unternehmensinfrastruktur, Cloud-Umgebungen, Anwendungen und kryptografischen Diensten.

Im Gegensatz zu einer punktuellen Bestandsaufnahme generiert und nutzt CBOM Secure kontinuierlich kryptografische Stücklisten (CBOMs) und verfolgt dabei Zertifikate, Schlüssel, Algorithmen und kryptografische Abhängigkeiten in der gesamten Umgebung. Es bietet Einblick in die eingesetzten Komponenten, deren Ausführungsorte und die Entwicklung dieser Abhängigkeiten im Zeitverlauf.

Die Plattform unterstützt richtlinienbasierte Governance, indem sie kryptografische Konfigurationen anhand von Organisationsstandards validiert, Abweichungen identifiziert und Sicherheits-, Betriebs- und Compliance-Risiken aufzeigt. Für Organisationen, die sich auf die Migration zu PQC vorbereiten, hilft CBOM Secure dabei, Systeme zu identifizieren, die auf quantenanfälligen Algorithmen basieren, Behebungsmaßnahmen zu priorisieren und die kontinuierliche kryptografische Governance zu etablieren, die für langfristige Krypto-Agilität erforderlich ist.

Die Migration von PQC betrifft jede Ebene der kryptografischen Infrastruktur. Die Beratungsleistungen und das Produktportfolio von Encryption Consulting decken diesen gesamten Bereich ab – von der ersten Bedarfsanalyse bis hin zur langfristigen operativen Krypto-Agilität.

Fazit

Die meisten Organisationen beginnen die PQC-Migration in der Erwartung eines kryptografischen Upgrades. Tatsächlich stellen sie fest, dass es sich um einen unternehmensweiten Transformationsprozess handelt, der Technologie, Governance, Beschaffung, Lieferantenmanagement, operative Resilienz und langfristiges Risikomanagement berührt.

Die Standards sind verfügbar, die regulatorischen Anforderungen werden klarer und die Unterstützung durch die Anbieter entwickelt sich stetig weiter. Die Organisationen, die die größten Fortschritte erzielen, sind jedoch nicht unbedingt diejenigen, die PQC-Algorithmen als Erste implementieren. Es sind vielmehr diejenigen, die Transparenz in ihrer kryptografischen Landschaft schaffen, frühzeitig mit Anbietern zusammenarbeiten, ihre PKI-Infrastruktur modernisieren und die notwendige Governance etablieren, um kryptografische Veränderungen im Laufe der Zeit zu steuern.

Die Migration zu PQC ist kein Projekt mit einem einzigen Abschluss. Sie markiert den Beginn eines neuen Betriebsmodells, in dem kryptografische Anpassungen zu einer kontinuierlichen Geschäfts- und Sicherheitsanforderung werden. Unternehmen, die heute Krypto-Agilität als langfristige Kompetenz aufbauen, sind am besten gerüstet, um nicht nur den Übergang zu PQC, sondern auch alle nachfolgenden kryptografischen Transformationen erfolgreich zu meistern.

Häufig gestellte Fragen

Warum ist der Vergleich der PQC-Migration mit dem Übergang von SHA-1 zu SHA-2 irreführend?

Da SHA-2 lediglich eine Hash-Funktion innerhalb derselben mathematischen Familie austauschte, ändert PQC die zugrundeliegende Mathematik grundlegend. Der Größenunterschied spiegelt dies wider: Ein ML-KEM-768-Schlüssel ist 1,184 Byte groß, im Vergleich zu 32 Byte bei X25519 – also etwa 37-mal so groß. Eine ML-DSA-65-Signatur umfasst 3,309 Byte, während ECDSA nur 64 Byte groß ist – etwa 51-mal so groß. Die von CNSA 2.0 vorgeschriebenen Standards ML-KEM-1024 und ML-DSA-87 erzeugen sogar noch größere Schlüssel und Signaturen.

Welche technischen Fehler verursacht die größere Schlüssel- und Signaturgröße von PQC tatsächlich?

Firewalls mit festen Pufferzuweisungen verwerfen übergroße ClientHello-Nachrichten, Middleboxes, die TLS-Erweiterungsfelder analysieren, scheitern bei den neuen Größen, und das Wachstum des Handshakes erhöht den Fragmentierungsdruck, was zu Problemen für Protokolle wie QUIC führen kann. Für ressourcenbeschränkte IoT-Geräte ist das Problem noch gravierender: LoRaWAN erlaubt selbst in der konservativsten Konfiguration nur etwa 51 Byte pro Uplink, während allein der ML-KEM-768-Chiffretext 1,088 Byte umfasst. Daher ist bei Geräten, die in Stromnetze oder Krankenhausausrüstung integriert sind, eher ein Hardwareaustausch als eine Softwarelösung erforderlich.

Warum können Organisationen die kryptografische Ermittlung nicht vor Beginn der Migration abschließen?

Da keine einzelne Erkennungsmethode die gesamte kryptografische Oberfläche abdeckt: Netzwerkscans erfassen zwar TLS-Handshakes, übersehen aber eingebettete Kryptografie; Codeanalysen finden Bibliotheksaufrufe, können aber die Laufzeitkonfiguration nicht einsehen; und agentenbasierte Tools decken die verwaltete IT ab, erreichen aber weder OT- noch Drittanbieterinfrastruktur. Der praktische Ansatz besteht darin, Erkennung und Migration parallel durchzuführen und dabei nach außen gerichtete Systeme zu priorisieren, anstatt einen Scan zu einem bestimmten Zeitpunkt als abgeschlossenes Ergebnis zu betrachten.

Warum muss die PKI-Modernisierung oft vor anderen Migrationsarbeiten erfolgen?

Da Zertifizierungsstellen, HSMs, Plattformen für das Zertifikatslebenszyklusmanagement, Codesignierungsdienste, Truststores und Registrierungsworkflows neue Algorithmen unterstützen müssen, bevor Zertifikate in großem Umfang ausgestellt und verwaltet werden können, müssen Zertifikatvorlagen, Ausstellungsworkflows, Validierungsdienste und TLS-Prüfgeräte möglicherweise getestet und angepasst werden. Aus diesem Grund wird die PKI-Infrastruktur oft zu einer kritischen Abhängigkeit, die Unternehmen erst im Zuge der umfassenderen Migration erkennen.

Warum gibt es zwischen den Regulierungsbehörden widersprüchliche Richtlinien für hybride Kryptographie?

Da verschiedene nationale Sicherheitsbehörden unterschiedliche Risikoabwägungen vorgenommen haben, bevorzugt das deutsche BSI im Allgemeinen hybride Ansätze (klassische Verfahren plus PQC) während der Übergangsphase. Das australische ISM hingegen schreibt die direkte Migration zu ASD-zugelassenen Post-Quanten-Algorithmen vor und erklärt, dass hybride klassische-PQC-Verfahren zwar nicht verboten, aber dennoch nicht empfehlenswert sind. Organisationen, die in verschiedenen Jurisdiktionen tätig sind, benötigen eine Architektur, die eine Konfiguration pro Jurisdiktion anstelle einer einheitlichen globalen Lösung ermöglicht.

Ist Krypto-Agilität etwas, das Organisationen einmalig für den PQC-Übergang aufbauen?

Nein, es sollte eine dauerhafte operative Fähigkeit sein, nicht nur ein einmaliges Migrationsergebnis. Quantencomputing ist nur ein Treiber kryptografischer Veränderungen; Schwachstellen in Algorithmen, Implementierungsfehler, Fortschritte in der Kryptoanalyse und sich entwickelnde Regulierungen können zukünftige Übergänge erforderlich machen. Organisationen, die Kryptoagilität als temporär betrachten, mögen die aktuelle Migration zwar abschließen, bleiben aber für zukünftige kryptografische Veränderungen schlecht gerüstet.