PQC-Migration im Jahr 2026: Entwicklung einer Roadmap, die den Kontakt mit der Produktion übersteht.

Am 13. Mai 2026 stellte Microsoft die allgemeine Verfügbarkeit der ML-DSA-Unterstützung in den Active Directory-Zertifikatdiensten für Windows Server 2025 bereit und brachte damit die Post-Quanten-Kryptografie aus der Dokumentation direkt in die Systeme, auf denen die meisten Unternehmens-PKIs tatsächlich laufen. Drei Wochen zuvor stritten dieselben Teams noch mit Auditoren darüber, ob ihre CA-Hierarchien überhaupt inventarisiert werden könnten. Diese Diskrepanz zwischen den beiden Entwicklungen führt dazu, dass 2026 die Roadmap für die PQC-Migration nicht länger nur ein Diskussionspunkt ist, sondern zu einem konkreten Umsetzungsprogramm mit Verantwortlichen, detailliertem Budget, Abhängigkeitslisten und vierteljährlichen Compliance-Berichten wird.

Dieser Artikel richtet sich an PKI-Architekten, Infrastrukturverantwortliche und CISOs, die ihr Programm von einer Präsentation in einen praktischen Leitfaden umsetzen möchten. Wir beleuchten die regulatorischen Rahmenbedingungen, die die Pläne für 2026 prägen, das Problem der Bestandsaufnahme, das niemand direkt angehen möchte, die drei Migrationsstrategien, die zu unterschiedlichen Risikoprofilen passen, warum PKI der limitierende Faktor in jeder soliden Roadmap ist, wie ein schrittweiser Rollout aussieht, wenn ML-DSA-Signaturen etwa 48-mal so groß sind wie ECDSA-Signaturen, und wie das Programm so instrumentiert wird, dass es die nächsten 18 Monate mit ihren ständigen Standardänderungen und Plattformaktualisierungen übersteht.

Die Druckkarte von 2026

Der Wandel von „Wir sollten planen“ zu „Wir müssen liefern“ vollzog sich nicht nur theoretisch, sondern auch praktisch. Sieben Meilensteine ​​definieren nun den Planungshorizont, den jede Unternehmens-Roadmap berücksichtigen muss, und keiner von ihnen liegt mehr als neun Jahre entfernt.

Moderator	Quelle	Datum	Operationelle Bedeutung
FIPS203 / 204 / 205 abgeschlossen	NIST	August 13, 2024	ML-KEM, ML-DSA und SLH-DSA sind produktionsreife Standards, keine Entwürfe.
HQC als Backup-KEM ausgewählt	NIST	11. März 2025	Algorithmische Vielfalt im KEM-Bereich; FIPS-Entwurf voraussichtlich 2026, endgültige Fassung 2027
EU NIS CG PQC Roadmap	Europäische Kommission, NIS-Kooperationsgruppe	Veröffentlicht am 23. Juni 2025	Die nationalen Pläne der Mitgliedstaaten sind bis zum 31. Dezember 2026 einzureichen.
FIPS 140-2-Module wurden in den historischen Bereich verschoben.	NIST CMVP	September 21, 2026	Die Beschaffung auf Bundesebene erfordert FIPS 140-3-validierte Module; der Validierungsrückstand nach FIPS 140-3 beträgt durchschnittlich über 500 Tage.
ADCS ML-DSA GA auf Windows Server 2025	Microsoft	Mai 2026 Update	Erste marktgängige CA-Plattform für Unternehmen, die PQC-Zertifikate ausstellt, im Produktivbetrieb
CNSA 2.0 Übernahmetor	NSA	1. Januar 2027	Neue Beschaffungen von Systemen für die nationale Sicherheit müssen ML-KEM-1024 und ML-DSA-87 unterstützen.
Auslaufen des NIST IR 8547-Algorithmus	NIST	2030 außer Kraft gesetzt, 2035 nicht mehr zulässig	RSA-2048 / ECC P-256 ab 2030 als veraltet markiert; quantenanfällige Algorithmen ab 2035 nicht mehr zulässig.

Horizontal betrachtet ist dies kein Problem, das erst 2035 auftritt. Die Beschaffungsfristen, die Umstellung auf FIPS 140 und die Veränderungen der Plattformverfügbarkeit konzentrieren sich auf das letzte Quartal 2026 und den 1. Januar 2027. Unternehmen, die an Bundesbehörden, NSS- oder kritische Infrastrukturmärkte verkaufen, müssen entweder innerhalb dieses Zeitraums die CNSA-2.0-Funktionalität bereitstellen oder aus dem Ausschreibungsverfahren ausscheiden. Selbst nicht regulierte Unternehmen sind indirekt betroffen: Ihre Anbieter nehmen die CNSA-2.0-Anforderungen mittlerweile in ihre Ausschreibungen auf, und Beschaffungsbeauftragte in regulierten Sektoren fordern im Rahmen ihrer Sorgfaltspflicht zunehmend PQC-Roadmaps an. Die Zeit, in der „Wir beginnen nächstes Jahr mit der Planung“ eine vertretbare Antwort auf eine Frage des Vorstands ist, endet im dritten Quartal 2026.

Warum HNDL keine hypothetische Idee ist

Der Slogan „ Erfassen, später entschlüsseln “ wurde in Marketingtexten so oft verwendet, dass manche Teams ihn bereits als Zukunftsszenario betrachten. Das ist er aber nicht. Die Datenerfassung findet bereits auf der bestehenden Infrastruktur statt: Staatliche Akteure erfassen heute TLS-Sitzungen, IPsec-Tunnel und gespeicherte verschlüsselte Backups, speichern diese und warten darauf, dass ein kryptografisch geeigneter Quantencomputer (CRQC) die verschlüsselten Schlüssel wiederherstellt. Der Anfang 2026 veröffentlichte Entwurf der EU-Richtlinie NIS2 bezeichnet HNDL-Angriffe als „wahrscheinlich bereits jetzt stattfindend“ – die bisher deutlichste Aussage in einem wichtigen Regulierungsdokument.

Daraus ergeben sich zwei Konsequenzen. Erstens ist die Migration der Verschlüsselung dringlicher als die Migration der Signaturen für alle Daten, deren Vertraulichkeitsanforderungen über den voraussichtlichen Zeitraum der CRQC-Einführung hinausgehen. Dazu gehören beispielsweise Banktransaktionsdaten, Gesundheitsdaten gemäß HIPAA, geistiges Eigentum im Zusammenhang mit Produktlebenszyklen, Verschlusssachen, Bürgerdaten gemäß DSGVO und Arbeitsdokumente im Rahmen von Fusionen und Übernahmen. Zweitens ist die Migration der Signaturen besonders wichtig für langlebige Signaturidentitäten (Root-CAs, Codesignaturzertifikate, Firmware-Update-Schlüssel), bei denen die Signatur über Jahre nach ihrer Ausstellung vertrauenswürdig bleiben muss. Eine gefälschte Signatur stellt zwar ein anderes Bedrohungsmodell dar als eine entschlüsselte Nachricht, doch die Lebensdauer der Assets bestimmt in beiden Fällen die Dringlichkeit.

Fazit: Priorisieren Sie die Einführung von ML-KEM für vertraulichkeitskritische Kanäle und implementieren Sie ML-DSA anschließend für die Signaturidentitäten mit den längsten Laufzeiten. Jede andere Reihenfolge kehrt das tatsächliche Risikomodell um.

Welche Standards sind heute tatsächlich versandfähig?

Fünf Algorithmen sind mittlerweile in oder nahe an den produktionsreifen NIST-Standards enthalten. Zu wissen, welcher Algorithmus wo eingesetzt werden soll, ist der entscheidende Unterschied zwischen einem Migrationsplan und einem Beschaffungsdokument.

Algorithmus	Standard	Typ	Produktionsstatus Mitte 2026
ML-KEM (Kyber)	FIPS203	Schlüsselkapselung	Primäres KEM; ML-KEM-768 für zivile Anwendungen, ML-KEM-1024 für CNSA 2.0
ML-DSA (Dilithium)	FIPS204	Digitale Unterschrift	Primäre Signatur; ML-DSA-65 zivil, ML-DSA-87 CNSA 2.0
SLH-DSA (SPHINCS+)	FIPS205	Staatenlose Hash-basierte Signatur	Konservativer Ausweichmechanismus; nicht in CNSA 2.0; große Signaturen
Hauptquartier	FIPS-Entwurf voraussichtlich 2026, endgültige Fassung 2027	Backup KEM (codebasierte Mathematik)	Krypto-Agilitätsreserve für den Fall, dass die Gittermathematik versagt
FN-DSA (Falcon)	Entwurf FIPS 206, voraussichtlich Ende 2026 oder Anfang 2027	Kompakte Signatur	Nicht in CNSA 2.0; kleinere Signaturen als ML-DSA, aber schwieriger sicher zu implementieren.

Die Parameterauswahl für CNSA 2.0 ist von Bedeutung und überrascht zivile Teams oft. Roadmaps, die standardmäßig ML-KEM-768 und ML-DSA-65 verwenden, sind ohne Anpassungen nicht auf NSS-Umgebungen übertragbar. Jedes Produktteam, das an die Verteidigungsindustrie verkauft, muss von Anfang an ML-KEM-1024 und ML-DSA-87 einplanen, da diese Parametersätze größere Schlüssel-, Chiffretext- und Signaturgrößen erfordern. CNSA 2.0 verbietet außerdem explizit HashML-DSA (die Pre-Hash-Variante) und plant nicht, zukünftige NIST-PQC-Algorithmen wie FN-DSA hinzuzufügen. Die Suite soll während der Übergangsphase stabil bleiben, was die Planung der Anbieter vereinfacht, jedoch die Flexibilität einschränkt.

Das Inventurproblem, das niemand sehen will

Die Ermittlungsphase ist der Punkt, an dem jede PQC-Roadmap scheitert, und das Fehlermuster ist immer dasselbe: Teams beschränken die kryptografische Bestandsaufnahme auf die Assets, die sie bereits verwalten, und übersehen dabei die, die das eigentliche Risiko darstellen. Eine glaubwürdige Bestandsaufnahme muss im Jahr 2026 mindestens sechs Ermittlungsebenen umfassen.

Die Endpunkt- und Serverprüfung erfasst kryptografische Bibliotheken (OpenSSL, BoringSSL, BCFIPS, den .NET-Kryptografie-Stack) und deren Versionen. Die Netzwerkermittlung erfasst TLS-Konfigurationen auf aktiven Ports, einschließlich der Fingerabdrücke, die aufzeigen, welche Clients noch RSA-Schlüsselaustausch oder SHA-1-Signaturen aushandeln. CA-APIs und Certificate Transparency Logs zeigen öffentlich ausgestellte Zertifikate an, wobei CT-Logs nur öffentlich vertrauenswürdige Zertifikate erfassen. Private CAs (die Mehrheit der Enterprise-PKI) erfordern eine direkte Integration mit AD CS oder der Plattform, die internes Vertrauen ausgibt. HSM-Inventare zeigen Schlüsselmaterial, aber nicht die zugehörigen Zertifikate. Daher muss die HSM-Partitionszuordnung mit CA-Datenbanken abgeglichen werden.

CMDBs und Infrastructure-as-Code-Repositories legen die Konfiguration offen, die Kryptografie mit Anwendungen verknüpft. Hier findet sich die Schattenkryptografie: fest codierte Algorithmen in älterem Java-Code, weitverbreitete SSH-Schlüsselpaare in CI/CD-Systemen, signierte JAR-Dateien mit eingebetteten Zertifikaten und fest codierte private Schlüssel in Repositories. Herstellerangaben und SBOMs schließen die Lücke bei Drittanbieterbibliotheken, insbesondere für eingebettete Systeme und IoT.

Manuelle Prüfungen liefern eine Momentaufnahme, die bereits vor dem Schließen der Tabelle veraltet ist. Die automatisierte, kontinuierliche Erkennung ist der einzige Ansatz, der im Unternehmensmaßstab zuverlässig funktioniert und regelmäßig wiederholt werden muss, da sich die kryptografischen Ressourcen täglich ändern, wenn Container gestartet, Updates von Anbietern bereitgestellt und neuer Code von Entwicklern eingecheckt wird. Das Inventar sollte für jedes Artefakt folgende Informationen erfassen: Algorithmus und Parameter, Schlüssellänge, Aussteller, Ablaufdatum, Geschäftsinhaber, technischer Verantwortlicher, Datenklassifizierung, Systemkritikalität und Komplexität des Austauschs. Ohne diese Felder kann das Inventar keine Risikobewertung ermöglichen.

Ein hilfreicher Vortest: Bitten Sie das Team, alle X.509-Zertifikate aufzulisten, die in den nächsten 90 Tagen ablaufen. Lautet die Antwort „Das müssten wir prüfen“, ist das Inventar noch nicht ausreichend, um einen Migrationsplan zu erstellen, und dieser wird Lücken aufweisen.

Drei Migrationsstrategien, drei Risikoprofile

Die Fachliteratur bietet zahlreiche Möglichkeiten zur Kategorisierung von Migrationsansätzen. In der Praxis lassen sich drei Muster beschreiben, die die meisten Unternehmen im Jahr 2026 tatsächlich einsetzen werden, wobei die Wahl zwischen ihnen von regulatorischen Vorgaben und den Kosten eines fehlerhaften Algorithmus abhängt.

Strategie	Was es bedeutet	Optimale Bildschirmwahl	Abtausch
Stufenweise Migration	Zuerst die Schlüsseleinrichtungen auf ML-KEM migrieren; Signaturen in einer späteren Welle auf ML-DSA.	Organisationen mit hohem HNDL-Bezug, aber begrenzter PKI-Änderungskapazität	Verschiebt die Komplexität der Signatur, lässt aber klassische Signaturidentitäten jahrelang ungeschützt.
Hybride Kryptographie	Klassische Sicherheitsverfahren (z. B. X25519, ECDSA) und PQC werden in einem einzigen Vorgang kombiniert; beide müssen aus Sicherheitsgründen erfüllt sein.	Regulierte Branchen, Hochsicherheitsumgebungen, alle, die der jungen PQC-Mathematik misstrauen.	Verdoppelt die Größe kryptografischer Artefakte, erschwert das Testen und erfordert eine zweite Migration (Hybrid zu reinem PQC) nachgelagerter Prozesse.
CNSA 2.0-Ausrichtung	ML-KEM-1024, ML-DSA-87, AES-256, SHA-384 / SHA-512 durchgehend	NSS, Verteidigungsindustrie, Bundesauftragnehmer	Strengere Parameter als die zivilen Standardeinstellungen; größere Schlüssel, Signaturen und Chiffretexte; längerer Zeitrahmen für die HSM- und Plattformbereitschaft

Hybridzertifikate verdienen besondere Beachtung. Die ADCS-Implementierung von Microsoft unterstützt zusammengesetzte Zertifikate, die eine klassische Signatur (RSA oder ECDSA) mit einer ML-DSA-Signatur kombinieren. Beide müssen validiert werden, damit das Zertifikat als vertrauenswürdig gilt. Der zusammengesetzte Ansatz ist betrieblich einfacher als ein paralleler Dual-Stack-Hybrid, da das Zertifikat ein einzelnes Artefakt darstellt. Allerdings führt er zu längeren Zertifikatsketten und erfordert vertrauende Parteien, die das zusammengesetzte Format verstehen. Planen Sie während der Übergangsphase beide Varianten ein. Die schrittweise Abschaffung von NIST IR 8547 zwischen 2030 und 2035 wird die klassische Komponente schließlich unterbinden, und jede Hybridkonstruktion, die die PQC-Komponente schwächt, wird diese Übergangsphase nicht überstehen. NIST hat diesen Punkt in den öffentlichen Kommentaren zu IR 8547 explizit hervorgehoben.

Die Entscheidung für kryptografische Agilität, die allen drei Mustern zugrunde liegt, ist dieselbe. Keine dieser Strategien funktioniert ohne eine Architektur, die Algorithmen per Richtlinie statt per Codeänderung austauschen kann. Diese operative Fähigkeit sollte unabhängig vom gewählten Migrationsmuster des restlichen Programms zuerst entwickelt werden.

PKI ist der Ratenbegrenzer

PKI ist der längste Pfahl in jedem PQC-Migrationszelt, und die Gründe dafür sind arithmetischer Natur.

ML-DSA-87 erzeugt Signaturen von ca. 4,627 Byte. ECDSA P-384 erzeugt Signaturen von ca. 96 Byte. Eine Zertifikatskette mit vier Zertifikaten (Root-, Zwischen-, Ausstellungs- und Endzertifikat) repliziert diese Größenänderung bei jedem TLS-Handshake, jeder OCSP-Antwort und jedem Aufbau einer authentifizierten Sitzung. Die Folgen sind erhöhter Bandbreitenbedarf, mehr Handshake-Runden, MTU-Fragmentierung auf Pfadsegmenten, die diese Änderung nicht berücksichtigt haben, und eine Belastung des HSM- Durchsatzes, da PQC-Signaturoperationen intern mehr Byte verarbeiten. Pre-Hashing hilft, die Auswirkungen auf das HSM zu reduzieren, ist aber gemäß CNSA 2.0 für diese Suite explizit untersagt. Daher benötigen NSS-Implementierungen leistungsfähigere HSMs anstatt intelligenterer Vorverarbeitung.

Zertifikatsketten weisen auch hierarchische Sequenzierungsprobleme auf, die durch die Wahl des Algorithmus nicht behoben werden können. Die Migration eines Endzertifikats zu ML-DSA ohne vorherige Migration der ausstellenden Zertifizierungsstelle (CA) führt zu Validierungsfehlern. Die Migration der ausstellenden CA ohne vorherige Migration der Offline-Root-CA erzeugt eine auf klassischer Mathematik basierende Kette und untergräbt somit den Zweck der Migration.

Die HSM-Bereitschaft verlängert den Zeitplan. SafeNet Luna und Thales-Plattformen bieten Firmware-Unterstützung für ML-DSA auf aktueller Hardware, ältere Module erfordern jedoch eine Hardware-Aktualisierung, Partitionsrestrukturierung und KSP-Neukonfiguration auf jedem Windows-Server, der sie nutzt. Das ADCS-Update vom Mai 2026 setzt die Auswahl des Schlüsselspeicheranbieters mit aktivierter Signatur in der Anforderungsverarbeitung voraus. Jede Zertifizierungsstelle mit einer HSM-Partition, die über die Seriennummer anstatt über die Steckplatzbezeichnung registriert wurde, benötigt einen erneuten KspConfig-Durchlauf, bevor die neuen Algorithmen im Dropdown-Menü verfügbar sind.

Planen Sie von der Beschaffungsentscheidung bis zum stabilen Betrieb einer PQC-basierten internen Zertifizierungsstelle 18 bis 24 Monate ein. Planen Sie mehr Zeit ein, wenn Sie Gesamtstrukturen überschreiten oder abhängige Middleware verwenden: NDES, Intune SCEP-Konnektoren, Java-Keystores und Codesignierungspipelines haben jeweils eigene Bereitschaftskurven, die bei der Migration der Zertifizierungsstelle nicht umgangen werden können.

Die Pointe: Jeder zweite PQC-Migrationsschritt hängt von der PKI ab, und die PKI ist das, was am langsamsten zu verschieben ist.

Sequenz eines Betreibers aus dem Jahr 2026

Im Folgenden wird die Vorgehensweise beschrieben, die wir anwenden, wenn ein Unternehmen fragt, wie die ersten 18 Monate einer PQC-Migration konkret aussehen. Sie basiert auf einer stark auf Microsoft-Produkte basierenden Umgebung mit einer zweistufigen AD CS-Hierarchie, HSM-gestützten Stammknoten und einer Mischung aus klassischen TLS-, S/MIME- und Codesignierungs-Workloads. Passen Sie die Tiefe der einzelnen Schritte an Ihre Umgebung an; die Reihenfolge darf nicht geändert werden.

1. Kontinuierliche kryptografische Unterstützung EntdeckungSetzen Sie einen automatisierten Scanner für Endpunkte, Netzwerksegmente, CA-Datenbanken, HSM-Partitionen, Container-Images und Code-Repositories ein. Erstellen Sie ein dynamisches Inventar, das nach Geschäftsinhaber, Ablaufdatum, Algorithmus, Parametersatz und Datensensibilität kodiert ist. Ohne diese Grundlage ist jeder weitere Schritt reine Spekulation, getarnt als Planung.
2. Bewerten Sie das Risiko anhand der Vertraulichkeitsdauer der Daten, nicht anhand der Anzahl der Assets. Erstellen Sie eine Risikomatrix, die Zertifikate und Schlüssel danach einstuft, wie lange die von ihnen geschützten Daten vertraulich bleiben müssen, gewichtet nach HNDL-Exposition und Systemkritikalität. Ein 90-Tage-TLS-Zertifikat für eine Marketing-Website wird niedriger eingestuft als ein Codesignaturschlüssel, dessen Signaturen zehn Jahre lang gültig sein müssen. Eine Priorisierung anhand der Anzahl führt zu einem Rückstand, der von Assets mit geringem Wert dominiert wird.
3. Erstellen Sie eine ML-DSA-Testhierarchie in einer nicht-produktiven Umgebung. Richten Sie in einer Windows Server 2025-Laborumgebung mit installiertem Mai-2026-Update eine parallele zweistufige AD CS-Hierarchie ein. Verwenden Sie ML-DSA-65 für die ausstellende Zertifizierungsstelle und ML-DSA-87 für die Offline-Stammzertifizierungsstelle. Stellen Sie Testzertifikate für Codesignierung, Webserver-Authentifizierung, Computerauthentifizierung und Benutzerauthentifizierung aus. Dokumentieren Sie, was aktuell funktioniert (Codesignierung ist das einfachste Szenario), was nur teilweise funktioniert (TLS-Webserver, bestimmte Authentifizierungsszenarien) und was noch nicht unterstützt wird (allgemeine Authentifizierung). TLS(VPN, Remote Desktop). Die in diesem Labor durchgeführte Gap-Analyse bildet die Grundlage für jede nachfolgende Produktionsentscheidung.
4. Testen Sie hybrides TLS in einer begrenzten Arbeitslast. Wählen Sie eine einzelne interne Anwendung mit geringem Sicherheitsradius. Konfigurieren Sie deren TLS-Endpunkt für den hybriden Schlüsselaustausch nach X25519MLKEM768 mit modernen Clients. Messen Sie Handshake-Größe, Latenz, Zertifikatskettenlänge und HSM-Durchsatz im Vergleich zur klassischen Baseline. Dokumentieren Sie die Abweichungen, einschließlich der MTU und des Load-Balancer-Verhaltens, die durch den größeren Handshake ausgelöst werden. Diese Werte, nicht Herstellerangaben, sind ausschlaggebend für die Produktionsfreigabe.
5. Bereiten Sie die HSM- und CA-Plattform vor. Prüfen Sie jede HSM-Partition auf Kompatibilität mit der Firmware des Herstellers hinsichtlich ML-DSA-Unterstützung. Planen Sie Firmware-Updates innerhalb von Wartungsfenstern, die den Rhythmus der Offline-Root-Zeremonie berücksichtigen. Stellen Sie für CA-Plattformen sicher, dass AD CS oder Ihre CLM-Plattform PQC-Zertifikate ausstellen kann und dass nachgelagerte Anwendungen (Intune, NDES, Codesignatur-Pipelines, zertifikatsverarbeitende Anwendungen) diese anfordern, bereitstellen und validieren können. Beachten Sie, dass die Ausstellung von ADCS-PQC-Zertifikaten derzeit die Auswahl eines KSP mit festgelegter Signatur in der Anforderungsverarbeitung erfordert und bestimmte Vorlagenversionen neu veröffentlicht werden müssen.

Keiner dieser Schritte erfordert einen kryptografisch relevanten Quantencomputer. Sie alle scheitern am Entdeckungsproblem in Schritt eins, weshalb jedes seriöse PQC-Programm einem Inventarbesitzer die Inventare zuweist, bevor es anderen Benutzern zuweist.

Wie CertSecure Manager PQC-konformes Zertifikatslebenszyklusmanagement ermöglicht

CertSecure Manager (CSM) ist so konzipiert, dass er als CA-agnostische Zertifikatslebenszyklusschicht über klassische, hybride und PQC-Zertifikatpopulationen hinweg fungiert, was der Bereitstellungsstruktur entspricht, die die PQC-Migration tatsächlich erfordert.

Multi-CA-Orchestrierung : CSM vermittelt die Ausstellung und Erneuerung von Zertifizierungsstellen über Microsoft AD CS, andere Enterprise-CA-Plattformen und öffentliche CAs hinweg von einer einzigen Richtlinienebene aus, sodass ein Wechsel von RSA zu ML-DSA auf der Backend-CA den Registrierungsworkflow der verbrauchenden Anwendung nicht unterbricht.

Kontinuierliche kryptografische Erkennung : Endpunkt- und Netzwerkscanner speisen CSM mit einem Echtzeit-Inventar von Zertifikaten, Algorithmen, Parametersätzen, Schlüssellängen und Ablaufzeiträumen, die den geschäftlichen und technischen Verantwortlichen sowie der Datensensibilität zugeordnet sind.

Richtlinienbasierte Krypto-Agilität : Die Algorithmenauswahl erfolgt über Richtlinien, nicht über Anwendungscode. Die Umstellung eines Zertifikatsbestands von ECDSA P-384 auf ML-DSA-65 wird zu einer Richtlinienaktualisierung und nicht zu einer erneuten Bereitstellung. Nur so lassen sich die Zeitvorgaben von FIPS 140 und CNSA 2.0 einhalten.

Unterstützung von zusammengesetzten und hybriden Zertifikaten : CSM wird erweitert, um das von Microsoft definierte ADCS-Kompositzertifikatsformat und die IETF-Hybridzertifikatsmuster zu verarbeiten, sodass Übergangsartefakte durchgängig über alle verwendenden Anwendungen hinweg validiert werden.

Wie kann Verschlüsselungsberatung helfen?

Encryption Consulting implementiert seit über einem Jahrzehnt PKI-, Kryptografie- und CLM-Programme für regulierte Unternehmen aus den Bereichen Finanzdienstleistungen, Gesundheitswesen, Energie, Telekommunikation und Fertigung. Kernstück unserer PQC-Lösungen ist CertSecure Manager , eine CA-unabhängige Plattform für den gesamten Zertifikatslebenszyklus. Sie orchestriert Ausstellung, Verlängerung, Erkennung und Richtlinienverwaltung über Microsoft AD CS, andere CA-Plattformen für Unternehmen und öffentliche CAs (klassisch, hybrid und PQC) hinweg von einer zentralen Steuerungsebene aus.

Ergänzend dazu bieten wir unsere PQC-Beratungsleistungen für Migrationsplanung und Krypto-Agilitäts-Roadmaps, PKI-Services für die Bewertung und Modernisierung von CA-Hierarchien in Unternehmen sowie HSM-Services für SafeNet Luna- und Thales-Plattformen, die für ML-DSA bereit sind. Um Ihre Roadmap zu erstellen, kontaktieren Sie uns unter [email protected] oder besuchen Sie www.encryptionconsulting.com.

Häufig gestellte Fragen

Was ist eine PQC-Migration?

Die PQC-Migration ist ein Programm zum Austausch quantenanfälliger kryptografischer Algorithmen (RSA, ECDSA, ECDH, Diffie-Hellman) in den Systemen, Anwendungen, Zertifikaten, Schlüsseln, Bibliotheken und Protokollen einer Organisation durch quantenresistente Algorithmen, die vom NIST in FIPS 203, 204 und 205 standardisiert sind. Es handelt sich um ein mehrjähriges Programm und nicht um ein einmaliges Upgrade. Es betrifft gleichzeitig die Bereiche PKI, Identität, Netzwerk, Anwendung und Beschaffung.

Warum wurde 2026 das Jahr, in dem die PQC-Migration von der Planungsphase in die Umsetzungsphase überging?

Drei unabhängige Termine fallen Ende 2026 und Anfang 2027 zusammen: der Übergang von NIST FIPS 140-2 zur historischen Version am 21. September 2026, der Meilenstein der nationalen Strategie der EU-NIS-Kooperationsgruppe am 31. Dezember 2026 und der Beschaffungsstart für NSA CNSA 2.0 am 1. Januar 2027. Alle drei führen zur Umwandlung von Empfehlungen in verbindliche Vorgaben für Beschaffung, Prüfung und Einhaltung von Vorschriften, die sich auf heute abgeschlossene Verträge auswirken.

Was ist Harvest Now, Decrypt Later (HNDL) und warum ist das heute wichtig?

HNDL beschreibt Angreifer, die heute verschlüsselte Daten abfangen und speichern, um sie später mit einem kryptografisch geeigneten Quantencomputer zu entschlüsseln. Dies ist heute relevant, da die abgefangenen Daten bereits gefährdet sind. Die Umstellung der Verschlüsselung muss vor der Existenz des CRQC erfolgen, nicht erst danach. Der Entwurf der EU-NIS2-Änderung von Anfang 2026 nennt HNDL-Angriffe ausdrücklich als bereits stattfindend.

Worin besteht der Unterschied zwischen ML-KEM und ML-DSA?

ML-KEM (FIPS 203, ehemals Kyber) ist ein Schlüsselkapselungsmechanismus zur Etablierung gemeinsamer Schlüssel und ersetzt klassische Schlüsselaustauschverfahren wie ECDH. ML-DSA (FIPS 204, ehemals Dilithium) ist ein Algorithmus für digitale Signaturen, der klassische Signaturverfahren wie ECDSA und RSA-Signatur ablöst. Die beiden Verfahren lösen unterschiedliche Probleme und werden zu unterschiedlichen Zeitpunkten eingeführt.

Muss AES-256 im Rahmen der PQC-Migration ersetzt werden?

Nein. AES-256 ist eine symmetrische Verschlüsselung und gilt bei korrekter Implementierung als quantenresistent. Die Migration zu Public-Key-Verschlüsselung (PQC) konzentriert sich auf Public-Key-Kryptographie (RSA, ECDSA, ECDH), die beim Schlüsselaustausch und bei digitalen Signaturen verwendet wird, wobei Shors Algorithmus einen Quantenvorteil bietet. Symmetrische Algorithmen benötigen lediglich eine Anpassung der Schlüssellängen an Grovers Algorithmus, was AES-256 bereits unterstützt.

Welche Fristen gelten für die Außerkraftsetzung von NIST IR 8547?

Gemäß dem ersten öffentlichen Entwurf von NIST IR 8547 (November 2024) werden Algorithmen, die 112-Bit-Sicherheit (RSA-2048, ECC P-256) bieten, bis 2030 als veraltet gelten. Alle quantenanfälligen Public-Key-Algorithmen sind in den NIST-Standards bis 2035 nicht mehr zulässig, was dem Zieldatum des National Security Memorandum 10 entspricht. Der Zeitraum von 2030 bis 2035 ist eine kontrollierte Übergangsphase und keine Freikarte.

Ist hybride Kryptographie während der PQC-Migration erforderlich?

Hybride Zertifikate sind nicht immer erforderlich, werden aber für Hochsicherheitsumgebungen empfohlen und von Microsofts ADCS-Implementierung in Form von zusammengesetzten Zertifikaten verwendet, die eine klassische und eine ML-DSA-Signatur kombinieren. Zivile Installationen können für neue Artefakte direkt auf reines PQC umsteigen; regulierte Umgebungen nutzen häufig hybride Zertifikate während der Übergangsphase, um eine mehrschichtige Verteidigung zu gewährleisten.

Wie unterstützt Microsoft AD CS PQC im Jahr 2026?

Das Windows Server 2025-Update vom Mai 2026 führte die allgemeine Verfügbarkeit von ML-DSA-44, ML-DSA-65 und ML-DSA-87 in Active Directory-Verwaltungsszenarien (AD CS) ein. Dadurch können ausstellende und Offline-Root-Zertifizierungsstellen Zertifikate mit quantenresistenten Algorithmen signieren. Codesignatur-Szenarien funktionieren seit Mitte 2026 zuverlässig. Weitergehende Szenarien wie TLS, VPN und Remote Desktop werden weiterhin nur teilweise unterstützt und erfordern eine Validierung für jede einzelne Arbeitslast.

Unterstützt CertSecure Manager aktuell PQC-Zertifikate?

CertSecure Manager fungiert als CA-unabhängige Lifecycle-Schicht, die die Zertifikatsausstellung über Microsoft AD CS, andere Enterprise-CA-Plattformen und öffentliche CAs vermittelt. Die Algorithmenauswahl erfolgt richtlinienbasiert und umfasst ML-DSA, sofern die Backend-CA dies unterstützt. Die Unterstützung für zusammengesetzte und hybride Zertifikate wird auf die Formate Microsoft ADCS und IETF erweitert. Erkennung, Automatisierung und Compliance-Berichte sind bereits produktionsreif.

Was ist der wichtigste erste Schritt für einen PQC-Migrationsplan?

Kontinuierliche kryptografische Ermittlung. Solange ein Unternehmen nicht weiß, wo sich seine kryptografischen Abhängigkeiten tatsächlich befinden (Algorithmen im Code, Bibliotheken in Containern, Zertifikate in CA-Datenbanken, Schlüssel in HSMs, fest codierte Geheimnisse in CI/CD), lassen sich Risiken nicht bewerten, Prioritäten nicht festlegen und der Migrationsfortschritt nicht messen. Jedes seriöse PQC-Programm weist daher zunächst einen Inventarverantwortlichen zu, bevor es weitere Personen einsetzt.

Fazit

Die Kräfte, die bis 2026 zusammenlaufen, sind nicht länger abstrakt. Das NIST hat drei Standards und einen vierten als Backup veröffentlicht; die NSA hat den 1. Januar 2027 als neuen Stichtag für die Beschaffung festgelegt; die Europäische Kommission hat die Strategien der Mitgliedstaaten auf den 31. Dezember 2026 ausgerichtet; Microsoft hat ML-DSA in die Plattform integriert, auf der die meisten Unternehmens- PKIs bereits basieren. Jede dieser Entwicklungen wandelt ein Planungsdokument in eine konkrete Umsetzungsanforderung um und hat Konsequenzen für Beschaffung und Audits, die weit vor 2030 spürbar werden.

Die praktischen Beweise sind ebenso eindeutig. PQC-Signaturen sind etwa zwei Größenordnungen größer als klassische Signaturen. Die HSM-Firmware ist nicht einheitlich aktuell. PKI-Hierarchien sind von der Wurzel nach außen sequenziert, und diese Sequenzierung dauert Monate. Die Erkennung ist das größte Hindernis. Die kryptografische Bestandsaufnahme ist noch ein Projekt, bevor sie zu einem System werden kann. Jedes Unternehmen, das versucht hat, diese Schritte abzukürzen, musste feststellen, dass dies nicht möglich ist und später nur durch höhere Kosten für die Reaktion auf Sicherheitsvorfälle, festgestellte Mängel in Audits und den Ausschluss von der Auftragsvergabe bestraft wird.

In der Kryptographie gewinnt der Kalender. Das Jahr 2030, in dem die Technologie abgeschafft wird, rückt näher als die Zeitspanne zwischen der letzten Runde des NIST PQC-Wettbewerbs und heute. Die Roadmap, die sich im praktischen Einsatz bewährt, ist diejenige, deren erster Schritt jetzt beginnt.