Post-Quanten-Kryptographie hält Einzug in AD CS: Was ML-DSA-Unterstützung konkret für Ihre Microsoft PKI bedeutet

Wichtige Erkenntnisse

• Das Sicherheitsupdate vom Mai 2026 (KB5087539) führt ML-DSA (das NIST-Update) ein. FIPS204 Post-Quanten-Signaturalgorithmus) zu AD CS auf Windows Server 2025. Zertifizierungsstellen, Zertifikatvorlagen und Online-Responder können jetzt mit quantenresistenten Schlüsseln signieren.
• ML-DSA Es handelt sich lediglich um eine Signaturprüfung. Sie schützt vor zukünftiger Fälschung von Zertifikaten und Codesignaturen; sie macht TLS-Sitzungen oder verschlüsselte Daten jedoch nicht quantensicher. Dafür ist ML-KEM erforderlich, das Microsoft zusammen mit zusammengesetzten Zertifikaten für eine spätere Phase eingeplant hat.
• Eine Migration direkt vor Ort ist nicht möglich. Bestehende CAs lassen sich nicht in ML-DSA konvertieren: Es wird eine neue, parallele Hierarchie aufgebaut. Dadurch sind die anfänglichen Laborarbeiten kostengünstig, während Verzögerungen teuer werden.
• Der regulatorische Zeitplan ist festgelegt, auch wenn der Quantenzeitplan es nicht ist: Das NIST plant, RSA-2048 und ECDSA P-256 nach 2030 als veraltet zu kennzeichnen und alle quantenanfälligen Public-Key-Algorithmen nach 2035 zu verbieten. Die heute ausgestellten Vertrauensanker überschneiden sich bereits mit diesen Daten.
• Der erste praktische Schritt ist kein Algorithmuswechsel, sondern eine kryptografische Bestandsaufnahme und eine Automatisierungsschicht, die den späteren Wechsel zu einer Konfigurationsänderung anstatt zu einem mehrjährigen Projekt macht.

Ein unauffälliges Update mit weitreichenden Folgen

Am 12. Mai 2026 veröffentlichte Microsoft eine der bedeutendsten Änderungen in der über zwanzigjährigen Geschichte der Active Directory-Zertifikatdienste. Das Sicherheitsupdate 2026-05 für Windows Server 2025 (KB5087539) ermöglicht es AD CS , Zertifizierungsstellen zu erstellen, Zertifikate auszustellen und OCSP-Antworten mithilfe von ML-DSA zu signieren. ML-DSA ist der von NIST in FIPS 204 standardisierte Modul-Lattice-basierte digitale Signaturalgorithmus. Es handelt sich um den ersten Post-Quanten-Algorithmus, der in der standardmäßigen Zertifizierungsstelle von Microsoft allgemein verfügbar ist.

Das ist nicht nur für die Kryptografie relevant. AD CS bildet im Hintergrund die zentrale Schnittstelle für die Zertifikatsausstellung in einem Großteil der Windows-Unternehmensumgebungen weltweit: Domänenauthentifizierung, Smartcards, Geräteregistrierung, internes TLS und Codesignierung . Jahrelang galt AD CS als im Wartungsmodus befindlich, und jede ernsthafte Modernisierung der Kryptografie musste an anderer Stelle erfolgen. Der Release-Zyklus 2025–2026 (CRL-Partitionierung, Verbesserungen der Überwachung und jetzt PQC) widerlegt diese Annahme. Microsofts Botschaft ist eindeutig: Die integrierte Zertifizierungsstelle ist aktiv am Übergang zur Post-Quanten-Verschlüsselung beteiligt und nicht von ihm betroffen.

In diesem Blogbeitrag erläutern wir die Neuerungen, die zugrundeliegende Kryptographie, was heute funktioniert und was nicht, die regulatorischen Fristen, die all dies vorantreiben, und einen pragmatischen, phasenweisen Zeitplan, anhand dessen Ihr PKI-Team planen kann.

Warum Post-Quanten-Kryptographie benötigt wird und warum PKI an erster Stelle steht

Jedes Zertifikat, das Ihre Zertifizierungsstelle heute ausstellt, basiert auf RSA oder elliptischer Kurvenmathematik. Beide Verfahren beziehen ihre Sicherheit aus Problemen (Faktorisierung ganzer Zahlen und diskrete Logarithmen), die ein ausreichend großer, fehlertoleranter Quantencomputer mit Shors Algorithmus effizient lösen könnte. Symmetrische Kryptographie schneidet deutlich besser ab: Grovers Algorithmus halbiert die effektive Schlüsselstärke lediglich, sodass AES-256 und SHA-2 weiterhin ausreichend sicher sind. Das existenzielle Problem konzentriert sich genau dort, wo PKI angesiedelt ist: bei asymmetrischen Schlüsseln und digitalen Signaturen.

Niemand kann das Jahr vorhersagen, in dem ein kryptografisch relevanter Quantencomputer auf den Markt kommt. Doch das Risiko besteht bereits heute, und zwar aus zwei verschiedenen Gründen:

• Jetzt ernten, später entschlüsseln. Angreifer zeichnen heute verschlüsselten Datenverkehr und gestohlene Geheimtexte auf, um sie nach der Entwicklung ausgereifter Quantencomputer zu entschlüsseln. Alle Daten, deren Vertraulichkeit die Quantentechnologie überdauern muss (z. B. Gesundheitsdaten, geistiges Eigentum, Staatsgeheimnisse), sind praktisch ungeschützt, sobald sie einen durch Quantencomputer anfälligen Schlüsselaustausch durchlaufen.
• Langjähriges Vertrauen. Dies ist ein PKI-spezifisches Problem, das Signaturen und nicht die Geheimhaltung betrifft. Ein Root-CA-Zertifikat, das 2026 mit einer Gültigkeitsdauer von fünfzehn oder zwanzig Jahren ausgestellt wurde, muss bis mindestens 2041 fälschungssicher bleiben. Eine heute angewendete Codesignatur oder Firmware-Signatur wird von den vertrauenden Parteien erst in einigen Jahren überprüft. Liegt der zugrunde liegende Algorithmus innerhalb dieses Zeitraums, kann ein Angreifer gefälschte Zertifikate und Updates erstellen, die sich nahtlos an Ihre Vertrauensanker anbinden und so nachträglich alles, was darauf aufbaut, unbrauchbar machen.

Führt man die Berechnungen durch, wird die Dringlichkeit deutlich. Vertrauensanker sind die langlebigsten kryptografischen Artefakte in jedem Unternehmen. Eine heute erstellte klassische Wurzel setzt darauf, dass Quantencomputer erst in zwei Jahrzehnten ausgereift sein werden – eine Wette, die NIST, NSA und Microsoft öffentlich abgelehnt haben.

Die Standards hinter dem Wandel

Im August 2024, nach einem achtjährigen globalen Wettbewerb, finalisierte das NIST seine ersten drei Post-Quanten-Standards. Alle basieren auf mathematischen Problemen (hauptsächlich strukturierten Gittern), für die kein effizienter Quantenalgorithmus bekannt ist:

Standard	Algorithmus (Abstammung)	Zweck	Status in Windows
FIPS204	ML-DSA (KRISTALLE-Dilithium)	digitale Signaturen	GA, und leben jetzt in AD CS
FIPS203	ML-KEM (KRISTALLE-Kyber)	Schlüsselkapselung / Schlüsselaustausch	Allgemeine Verfügbarkeit in CNG-APIs; AD CS-Unterstützung geplant (Phase 2)
FIPS205	SLH-DSA (SPHINCS+)	Zustandlose Hash-basierte Signaturen	Verfügbar in den Kryptobibliotheken von Microsoft; derzeit kein AD CS-Algorithmus.

Ein vierter Signaturstandard, FN-DSA (basierend auf Falcon), befindet sich noch im Entwurfsstadium. Für die PKI-Planung in Unternehmen ist die relevante Kombination einfach: ML-DSA ersetzt RSA/ECDSA für die Signierung; ML-KEM ersetzt RSA-Verschlüsselung und (EC)DH für die Schlüsselerzeugung. AD CS Phase 1 liefert die erste Hälfte dieser Kombination.

Die Uhr, gegen die Sie tatsächlich ankämpfen

Die ehrliche Antwort auf die Frage „Wann werden Quantencomputer RSA knacken?“ lautet: Niemand weiß es. Die Antwort im Hinblick auf die Einhaltung der Vorschriften ist deutlich konkreter, da die Regulierungsbehörden beschlossen haben, nicht auf Gewissheit zu warten. Drei Zeiträume laufen nun im selben Jahrzehnt zusammen:

Datum	Milestone
August 2024	NIST finalisiert FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS205 (SLH-DSA).
Nov 2024	NIST IR 8547 (Entwurf), Übergang zu Post-Quanten-Kryptographiestandards, veröffentlicht den Fahrplan zur Abschaffung von RSA, ECDSA, ECDH, DSA und DH für endliche Körper.
2025	Microsoft kündigt sein Quantum Safe Program an und stellt Windows Insidern PQC-Algorithmen über SymCrypt und die CNG-APIs zur Verfügung; die Linux-Unterstützung folgt über SymCrypt-OpenSSL.
Okt.–Nov. 2025	PQC ist ab Windows Server 2025, Windows 11 24H2/25H2 (Client-Aktivierung über KB5067036) und .NET 10 allgemein verfügbar.
May 12, 2026	AD CS ML-DSA-Unterstützung GA auf Windows Server 2025 über das Sicherheitsupdate KB5087539.
2027	NSA CNSA 2.0Neuanschaffungen für US-amerikanische nationale Sicherheitssysteme müssen quantenresistente Algorithmen unterstützen.
2029	Microsofts erklärtes Ziel ist die frühzeitige Einführung von PQC in den eigenen Produkten und Dienstleistungen.
2030	NIST IR 8547: Algorithmen auf 112-Bit-Sicherheitsniveau (RSA-2048 und ECDSA P-256) sind veraltet. Die weitere Verwendung erfordert eine dokumentierte Risikoakzeptanz.
2033	Microsofts Ziel ist es, den Übergang zu PQC zwei Jahre vor der bundesweiten Frist abzuschließen.
2035	NIST IR 8547 / NSM-10: Alle quantenanfälligen Public-Key-Algorithmen (RSA mit beliebiger Schlüssellänge, ECDSA, ECDH, DSA, FFDH) sind nicht zulässig. Es gibt keine Möglichkeit der Risikoakzeptanz mehr.

Übertragen Sie nun die Gültigkeitsdauern Ihrer eigenen Zertifikate in diese Tabelle. Ein 2026 ausgestelltes Stammzertifikat mit einer Gültigkeit von 20 Jahren läuft 2046 ab, elf Jahre nach dem Stichtag. Eine im nächsten Jahr erstellte, 10 Jahre gültige ausstellende Zertifizierungsstelle ist noch aktiv, wenn RSA-2048 als Prüfergebnis dokumentiert wird. Aus diesem Grund hat Microsoft die Unterstützung für Zertifizierungsstellen zuerst bereitgestellt: Die Objekte mit der längsten Gültigkeitsdauer in der Hierarchie müssen als Erstes migriert werden.

Was Microsoft tatsächlich in AD CS ausgeliefert hat

Phase 1 ist bewusst so begrenzt: Sie deckt die Signaturebene einer Microsoft PKI vollständig ab. Konkret kann AD CS auf einem gepatchten Windows Server 2025-Rechner nun Folgendes leisten:

• Installieren Sie Root-, Subordinate-, Enterprise- und Standalone-CAs, deren eigene Schlüsselpaar- und Zertifikatsignierungsvorgänge ML-DSA verwenden, einschließlich einer vollständig postquantenbasierten Kette, wenn jede Ebene diese verwendet.
• Veröffentlichen Sie Zertifikatvorlagen, die ML-DSA-Endgerätezertifikate für Codesignierung, TLS/Webserver, Benutzer und Computer ausstellen.
• Registrieren Sie diese Zertifikate über das MMC-Snap-In „Zertifikate“ und certreq.exe, einschließlich der Auswertung von ACL-Vorlagen im Stil der automatischen Registrierung.
• Schild OCSP Antworten mit einem ML-DSA Online Responder-Signaturzertifikat.
• Authenticode-Codesignaturen mit ML-DSA-Zertifikaten prüfen und anwenden: Set-AuthenticodeSignature und die Signatur-UI arbeiten nahtlos zusammen, und .NET 10 stellt den Entwicklern den Algorithmus über die Klassen MLDsa / MLDsaCng zur Verfügung.

Microsoft hat die Roadmap für die Zukunft explizit veröffentlicht. Die Unterstützung wird schrittweise eingeführt, und das Plattformteam hat sich verpflichtet, PQC auf die AD CS-Rollendienste auszuweiten: die Zertifikatregistrierungsrichtlinien und Registrierungswebdienste (CEP/CES), NDES und den Online Responder.

Capability	Standard	Zweck	AD CS-Status
ML-DSA (rein)	FIPS204	PQ digitale Signaturen	Ab sofort verfügbar (Phase 1)
ML-KEM	FIPS203	PQ-Schlüsselkapselung	Geplant (Phase 2)
Composite ML-DSA	IETF LAMPS-Entwurf	Klassische + PQ-Signatur in einem Zertifikat	Geplant (Phase 2)
Composite ML-KEM	IETF LAMPS-Entwurf	Klassische + PQ-Tastenkapselung	Geplant (Phase 2)
CEP / CES / NDES / OCSP Rollen- und Dienstabdeckung	N / A	PQ-Registrierung & -Widerruf Sanitärinstallationen	Engagiert; schrittweise Ankunft

Plattformvoraussetzungen. PQC in AD CS erfordert Windows Server 2025 mit dem Sicherheitsupdate 2026-05 (KB5087539) oder höher auf der Zertifizierungsstelle (CA) und Windows 11 24H2/25H2 mit dem Update 2025-10 (KB5067036) oder höher auf den registrierenden Clients. Es gibt keine Hinweise auf eine Rückportierung: Windows Server 2019- und 2022-CAs werden voraussichtlich keine PQC-Unterstützung erhalten. Falls Ihre ausstellenden CAs noch auf älteren Plattformen laufen, ist das Betriebssystem-Upgrade nun offiziell Teil des kritischen Pfads für PQC. Alle PQC-Algorithmen benötigen außerdem CNG-Schlüsselspeicheranbieter: Ältere CryptoAPI-CSPs werden nicht unterstützt.

ML-DSA im Detail: Was PKI-Ingenieure wissen sollten

ML-DSA stammt von CRYSTALS-Dilithium ab, dem Gewinner des Hauptwettbewerbs des NIST. Seine Sicherheit beruht auf der Schwierigkeit der Probleme „Lernen mit Fehlern“ und „Kurzzahlige Lösung“ über strukturierten Gittern – mathematischen Gebieten, für die kein effizienter Quantenangriff bekannt ist. Zwei seiner Eigenschaften beeinflussen direkt das Verhalten von AD CS; daher sollten sie verinnerlicht werden, bevor man eine Konsole benutzt.

Es handelt sich um einen reinen Signaturalgorithmus.

ML-DSA kann weder Daten verschlüsseln noch einen Schlüsselaustausch durchführen. Dies erklärt die meisten Konfigurationseinschränkungen: Vorlagen müssen für Signaturzwecke bestimmt sein, die Verwendung von Schlüsseln für Verschlüsselung und Schlüsselaustausch ist untersagt, EFS- und Secure-Email-EKUs werden abgelehnt, und die Vertraulichkeit von TLS- Sitzungen bleibt bis zur Einführung von ML-KEM unberührt. Benötigt ein Workflow einen Schlüssel zum Schutz von Daten und nicht zum Nachweis von Identität oder Integrität , ist ML-DSA von Grund auf das falsche Werkzeug.

Drei Parametersätze, drei Sicherheits-/Größenkompromisse

AD CS unterstützt alle drei FIPS 204-Parametersätze im reinen (nicht zusammengesetzten) Modus. Wählen Sie den passenden Parametersatz entsprechend Ihrer Sicherheitskategorie und dem verfügbaren Speicherplatz:

Parametersatz	NIST-Kategorie	Öffentlicher Schlüssel	Privat Schlüssel	Signature	Die in der Windows-Benutzeroberfläche angezeigte „Tastengröße“
ML-DSA-44	Level 2	1,312 B	2,560 B	2,420 B	10,496 Bits
ML-DSA-65	Level 3	1,952 B	4,032 B	3,309 B	15,616 Bits
ML-DSA-87	Level 5	2,592 B	4,896 B	4,627 B	20,736 Bits

Ein Detail, das beim ersten Kontakt oft verwirrt: Die Windows-Benutzeroberfläche zeigt Schlüssellängen wie 15,616 Bit an, was im Vergleich zu RSA-2048 ungewöhnlich wirkt. Es handelt sich dabei lediglich um die Länge des öffentlichen Schlüssels in Bit (1,952 Byte × 8). Nichts Exotisches: einfach ein deutlich größerer Schlüssel. Als praktische Richtlinie gilt: ML-DSA-65 ist der sinnvolle Standard für ausstellende Zertifizierungsstellen und Endbenutzerzertifikate (Kategorie 3 ist vergleichbar mit AES-192). ML-DSA-87 eignet sich für Root-Zertifikate und langlebige Ankerzertifikate, bei denen maximale Sicherheitsmarge gewünscht ist. ML-DSA-44 ist für Fälle mit wirklich begrenzter Schlüsselgröße gedacht, in denen Kategorie 2 ein akzeptabler Kompromiss ist.

Warum verschwindet das Dropdown-Menü für den Hash-Algorithmus?

Klassische PKI basiert auf dem Prinzip „Hashen und dann signieren“: Die Zertifizierungsstelle (CA) berechnet einen Hashwert der zu signierenden Daten und signiert diesen anschließend mit ihrem privaten Schlüssel. Die Wahl des Hashwerts war ein separater, konfigurierbarer Freiheitsgrad. Genau deshalb verwendete die Branche MD5 und SHA-1 mit einwandfreien Schlüsseln und musste anschließend aufwendige Migrationen durchführen, um dieses Problem zu beheben. ML-DSA beseitigt diese Möglichkeit: Die Nachrichtenverarbeitung ist integraler Bestandteil des Signaturverfahrens selbst, intern festgelegt und nicht vom Betreiber wählbar.

AD CS macht dies transparent. Sobald Sie während der CA-Einrichtung einen ML-DSA-Schlüsselalgorithmus auswählen, reduziert sich die Liste der Hash-Algorithmen auf einen einzigen Eintrag: NoHash. Bei Zertifikatvorlagen sind die Hash-Auswahl und die Option für das alternative Signaturformat (PKCS#1 v2.1) ausgegraut: Es gibt keine Signaturvariante zur Auswahl. NoHash bedeutet nicht, dass die Daten ungehasht sind; es bedeutet, dass das Hashing in FIPS 204 integriert ist und AD CS Ihnen keine Wahlmöglichkeit vorgaukelt. Eine ganze Reihe von Fehlkonfigurationen in der PKI gehört damit der Vergangenheit an.

Reine vs. zusammengesetzte Zertifikate: Die Übergangsfrage

Post-Quanten-Zertifikate gibt es in zwei Architekturvarianten, und Microsofts Roadmap umfasst bewusst beide:

• Rein. Das Zertifikat verwendet einen einzigen Post-Quanten-Algorithmus: den, den AD CS aktuell ausliefert. Es ist der sauberste Endzustand, aber jede vertrauende Partei in der Kette muss ML-DSA bereits beherrschen, um es zu validieren. In einer heterogenen Umgebung mit vielen Appliances, eingebetteten Systemen und älterer Middleware stellt dies eine echte Einschränkung dar.
• Verbund Das Zertifikat enthält einen klassischen Schlüssel (RSA oder ECDSA) und einen Post-Quanten-Schlüssel. Seine Signatur besteht aus beiden. Zur Validierung müssen beide Schlüssel verifiziert werden; eine Fälschung erfordert also die Kompromittierung beider Algorithmen. Das Zertifikat bleibt so lange sicher, wie mindestens einer der beiden Algorithmen gültig ist. Der Nachteil ist die Größe (alles muss doppelt gespeichert werden) und die Anforderung, dass die Validatoren das zusammengesetzte Format verstehen, das derzeit in den IETF-LAMPS-Entwürfen definiert ist.

Praktische Anwendung: Reines ML-DSA eignet sich für geschlossene, neu entwickelte Ökosysteme, in denen Sie jeden Validator kontrollieren: interne Codesignatur, Infrastrukturattestierung, Maschine-zu-Maschine-Vertrauen innerhalb einer verwalteten Flotte. Composite ist die Migrationslösung für heterogene Umgebungen, in denen Sie Post-Quantum-Schutz benötigen, ohne von Anfang an auf universelle ML-DSA-Unterstützung setzen zu müssen. AD CS Phase 2 wird voraussichtlich Composite ML-DSA und Composite ML-KEM einführen ; bis dahin sollten Sie reine Implementierungen anhand von Kompatibilitätstests mit den vertrauenden Parteien planen.

Einrichtung einer ML-DSA-Zertifizierungsstelle: Was funktioniert heute?

Ausschließlich neue Hierarchien, absichtlich

Der wichtigste Aspekt bei der Bereitstellung: ML-DSA-Zertifizierungsstellen müssen neu installiert werden. Eine direkte Konvertierung einer bestehenden Zertifizierungsstelle ist nicht möglich, und es gibt auch keine Möglichkeit, eine Zertifizierungsstelle mit neuem Algorithmus zu erneuern: Die Änderung des Public-Key-Algorithmus erfordert einen neuen Schlüssel, ein neues Zertifikat und damit faktisch eine neue Identität der Zertifizierungsstelle. Microsoft empfiehlt, parallel zu Ihrer Produktions-PKI eine Post-Quantum-Hierarchie aufzubauen und Workloads gezielt zu migrieren. Auch wenn dies zunächst umständlich erscheint, entspricht es dem bewährten Vorgehen bei der Rotation von PKI-Generationen und ermöglicht Ihnen, bereits heute mit der Evaluierung zu beginnen – ohne Risiko für die Produktivumgebung.

Installation der CA

Im AD CS-Konfigurationsassistenten des Server Managers werden die drei ML-DSA-Parametersätze nun in der Liste der Schlüsselalgorithmen neben RSA und ECDSA angezeigt, und durch Auswahl eines solchen Satzes wird die Hash-Liste auf NoHash reduziert.

Hinweis: Die „NoHash“-Falle. Sie müssen den Parameter `-HashAlgorithmName "NoHash"` explizit angeben. Die AD CS-Setup-Engine initialisiert standardmäßig RSA mit SHA-256 und behält diesen SHA-256-Hash auch nach dem Wechsel des Schlüsselalgorithmus zu ML-DSA bei. Daher schlägt eine ML-DSA-Installation ohne diesen Parameter fehl. Dasselbe gilt für die Automatisierung: Jedes Bereitstellungsskript, das SHA256 fest codiert, benötigt eine bedingte Verzweigung, bevor es auf eine PQ-Zertifizierungsstelle zugreift.

Nach der Installation zeigt certsrv.msc genau das an, was man erwarten würde: den Microsoft Software Key Storage Provider mit einem ML-DSA-Schlüssel, dem Hash-Algorithmus NoHash und einem CA-Zertifikat, dessen Signaturalgorithmus ebenfalls ML-DSA ist. Die Zertifikatskettenbildung, die CDP/AIA-Veröffentlichung und die Integritätsprüfungen in pkiview.msc funktionieren einwandfrei.

Zertifikatvorlagen: Fünf Einstellungen, die alles steuern

ML-DSA erscheint im Vorlagen-Tab „Kryptografie“ nur dann, wenn die Vorlage korrekt strukturiert ist, und einige der Anforderungen lassen sich direkt auf „Signatur-only“ zurückführen:

Vorlageneinstellung	Erforderlicher Wert	Warum es wichtig ist
kryptografische Anbieterkategorie	CNG-Schlüsselspeicheranbieter	PQC existiert nur im CNG-Stack; ältere CSP-basierte Templates werden ML-DSA niemals auflisten.
Kompatibilität (CA und Empfänger)	Windows Server 2008 oder höher	CNG-Anbieter erscheinen in der Anbieterliste nur ab dieser Kompatibilitätsstufe.
Anfragebearbeitung → Zweck	Unterschrift: genau	Hier liegt der Haken, der den Leuten einen Nachmittag kostet: Bei allen anderen Verwendungszwecken (einschließlich „Signatur und Verschlüsselung“) verschwindet ML-DSA stillschweigend von der Registerkarte Kryptographie.
Bewerbungsrichtlinien (EKU)	Kein EFS, keine sichere E-Mail	Beide implizieren Verschlüsselungsoperationen, die ML-DSA nicht durchführen kann.
Erweiterung zur Schlüsselverwendung	Keine Schlüsselverschlüsselung, keine Schlüsselvereinbarung	Aus demselben Grund: Das Schlüsselpaar kann keine Geheimnisse herstellen oder übertragen.

Registrierung, OCSP und Codesignierung

Die Registrierung funktioniert aktuell über den Zertifikats-MMC-Assistenten und certreq.exe von gepatchten Windows 11 24H2/25H2-Clients. Die NDES-Registrierung (SCEP) ist explizit noch nicht verfügbar; dies ist relevant, wenn Ihre MDM-ausgestellten Gerätezertifikate auf NDES basieren.

Hinweis: Der nur teilweise gepatchte Client. Bei einem nur teilweise gepatchten Windows 11-Client kann der Registrierungsassistent ML-DSA zwar auflisten, die Registrierung selbst aber fehlschlagen. Überprüfen Sie das Feld „Schlüsselgröße“ des Assistenten, um die Ursache zu ermitteln: Ein gültiger Wert (10,496 / 15,616 / 20,736) bedeutet, dass der Client vollständig aktiviert ist, während 0 bedeutet, dass der Algorithmus im Schlüsselspeicher des Clients nur teilweise aktiviert ist. Schließen Sie die Patch-Installation ab, bevor Sie die Zertifizierungsstelle (CA) verantwortlich machen.

Der Online Responder akzeptiert ein ML-DSA OCSP-Antwortsignaturzertifikat (die Standardvorlage duplizieren, nicht bearbeiten) und signiert Antworten problemlos. Eine kleine Besonderheit: Die Hash-Algorithmus-Eigenschaft des Responders kann bei ML-DSA-Konfigurationen einen ungültigen Wert liefern, da kein Hashwert angezeigt werden kann. Ignorieren Sie diese Zeichenkette und vertrauen Sie pkiview.msc , das den Responder als fehlerfrei meldet. Authenticode ist ähnlich vollständig: Signieren und Verifizieren mit Set-AuthenticodeSignature / Get-AuthenticodeSignature funktioniert durchgängig, wodurch die interne Codesignierung zu einer der zuverlässigsten ersten Produktions-Workloads für eine PQ-Hierarchie wird.

Was noch nicht da ist

Eine ehrliche Bedarfsanalyse ist die halbe Miete einer guten Beratung. Hier ist die aktuelle Abgrenzung aus einer Perspektive:

Heute im Einsatz (Phase 1)	Noch nicht / geplant
ML-DSA Root-, Sub-, Enterprise- und Standalone-Zertifizierungsstellen (Neuinstallationen)	Migration oder algorithmische Erneuerung bestehender Zertifizierungsstellen: wird nicht erfolgen; parallele Hierarchien planen
ML-DSA-Blattausgabe: Codesignierung, Webserver, Benutzer, Computervorlagen	NDES/SCEP-Registrierung; vollständige CEP/CES-Webserviceabdeckung (zugesagt, schrittweise)
Registrierung über die Zertifikatsverwaltungskonsole (MMC) und certreq.exe	IIS HTTPS-Bindungen mit ML-DSA-Serverzertifikaten: Die Schannel-TLS-Authentifizierung ist dafür noch nicht aktiviert.
OCSP-Antwortsignierung mit ML-DSA	Kerberos-/PKINIT- und Smartcard-Anmeldeabläufe
Authenticode-Codesignierung und -Verifizierung; .NET 10 MLDsa-APIs	Alles, was mit Verschlüsselung zu tun hat (EFS, S/MIME-Verschlüsselung): standardmäßig bis zur Einführung von ML-KEM.
Unterstützung für die Plattformen Windows Server 2025 und Windows 11 24H2/25H2	Zusammengesetzte ML-DSA-/ML-KEM-Zertifikate (Phase 2); Windows Server 2019/2022 (keine Rückportierung erwartet)

Lesen Sie die rechte Spalte sorgfältig durch, bevor Sie jemandem ein „quantensicheres Intranet“ versprechen. Das heutige Release sichert die Ausstellungs- und Signierungsebene . Die Sitzungsebene (TLS-Schlüsselaustausch und damit der Schutz von Daten während der Übertragung nach dem Prinzip „Erfassen und später entschlüsseln“) wartet auf die Integration von ML-KEM über den TLS-Stack. Drittanbieter-Partner stellen ein eigenes Problem dar: Viele Anwendungen, Appliances und HSM-nahe Middleware können ML-DSA-Zertifikate noch nicht verarbeiten. Daher benötigt jeder Pilot eine Kompatibilitätsmatrix und keine Annahme.

Betriebliche Realitäten: Größe, HSMs und der Betrieb zweier PKIs

Alles wird größer

Die Sicherheit von Gitterstrukturen wird in Bytes bezahlt. Vergleichen Sie die Datenmengen, die Ihre Infrastruktur tatsächlich bewegt und speichert:

Algorithmus	Öffentlicher Schlüssel	Signature	Signatur vs. RSA-2048
RSA-2048	256 B	256 B	1× (Basislinie)
ECDSA P-256	~ 64 B	~ 70 B	~0.3×
ML-DSA-44	1,312 B	2,420 B	~9×
ML-DSA-65	1,952 B	3,309 B	~13×
ML-DSA-87	2,592 B	4,627 B	~18×

Ein Blattzertifikat, das mit RSA etwa 1–1.5 KB groß ist, erreicht mit ML-DSA-65 einen Umfang von 6–7 KB, sobald der eingebettete öffentliche Schlüssel und die Signatur der ausstellenden Zertifizierungsstelle berücksichtigt werden. Eine dreistufige Kette überschreitet bereits vor dem eigentlichen Handshake die 20-KB-Marke. OCSP-Antworten wachsen um eine Signatur plus typischerweise ein eingebettetes Signaturzertifikat. Berücksichtigen Sie die Folgen jetzt schon: Bandbreite und Caching für CDP/AIA und OCSP, Zertifikatsspeicher und die Datenbank der Zertifizierungsstelle, CLM-Inventare, TLS-Einträge und MTU-Verhalten nach dem Eintreffen von ML-KEM-Handshakes sowie die begrenzten Kapazitäten von Smartcards, TPMs und ressourcenbeschränkten Geräten. Nichts davon ist prohibitiv (öffentliche Web-PKIs bewältigen dieselbe Entwicklung), aber es gehört in Ihr Kapazitätsmodell und nicht erst in die Nachbesprechung eines Vorfalls.

HSMs: Prüfen Sie, bevor Sie etwas versprechen.

Die Phase-1-Umgebung nutzt den Microsoft Software Key Storage Provider (KSP), der für Labore und viele interne Hierarchien geeignet ist. Produktionsumgebungen und ausstellende Zertifizierungsstellen in regulierten Umgebungen benötigen hardwarebasierte ML-DSA-Schlüssel. Dies hängt vollständig davon ab, ob der CNG-Anbieter Ihres HSM-Herstellers den Algorithmus in einer Firmware bereitstellt, die FIPS 140-3-validiert ist (oder kurz vor der Validierung steht). Die großen Anbieter (Thales Luna, entrust nShield, Cloud-HSM-Dienste) haben in den letzten Firmware-Generationen die Unterstützung für FIPS 203/204 integriert, der Validierungsstatus und die Reife der KSP-Integration variieren jedoch je nach Modell und Version. Nehmen Sie die Forderung nach ML-DSA über Ihren CNG-KSP und den entsprechenden Validierungsdokumenten fest in Ihren Pilotplan auf und entscheiden Sie bewusst, ob Sie in den frühen Phasen mit Software-Schlüsseln arbeiten, während die Hardware-Integration voranschreitet.

Sie werden jahrelang zwei PKIs betreiben.

Eine parallele Hierarchie ist kein Wochenendlabor, sondern eine zweite Produktionsumgebung mit eigenen Vorlagen, CDP/AIA-Veröffentlichungen, OCSP, Überwachung, Schlüsselzeremonien, CP/CPS-Änderungen und schließlich einem Stilllegungsplan für die klassische Seite. Organisationen, die dies erfolgreich umsetzen, behandeln den Übergang als Programm zur Steigerung der Krypto-Agilität : Sind Zertifikatsausstellung und -erneuerung bereits automatisiert und inventarbasiert, wird der Algorithmuswechsel zu einer Konfigurationsänderung, die automatisch ausgeführt wird. Erneuert Ihr System Zertifikate weiterhin per Tabellenkalkulation und Kalendererinnerung, fühlt sich die PQC-Migration ähnlich an wie die Abschaffung von SHA-1 – nur dass dies alle Ihre Zertifikate betrifft, mit größeren Datenmengen und strengeren Fristen.

Ein pragmatischer Migrationszeitplan

Die Zuordnung der regulatorischen Termine zu konkreten PKI-Maßnahmen ergibt einen Fünf-Phasen-Plan. Die untenstehenden Zeiträume gehen von einem Unternehmen relevanter Größe aus, das etwa jetzt startet; sie können je nach Bedarf verkürzt oder verlängert werden, die Reihenfolge sollte jedoch beibehalten werden: Jede Phase minimiert die Risiken der nächsten.

Phase	Window	Was ist tatsächlich zu tun?
0. Bestands- und Expositionskartierung	Jetzt – Ende 2026	Erstellen Sie ein kryptografisches Inventar (Ein CBOM) über Zertifizierungsstellen, Vorlagen, Schlüssel, Protokolle, Anwendungen und eingebettete Geräte hinweg. Kennzeichnen Sie die beiden Hochrisikoklassen: langlebige Signaturen (Root-Signaturen, Code-/Firmware-Signaturen, Dokumentenvertrauen) und Daten mit langer Vertraulichkeit, die dem Prinzip „Erfassen und später entschlüsseln“ ausgesetzt sind. Bringen Sie die CA-Plattformen auf Windows Server 2025 und die Client-Flotte auf die PQC-fähige Basisversion.
1. Parallel PQ-Pilot	2026 – 2027	Richten Sie im Labor eine isolierte zweistufige ML-DSA-Hierarchie ein. Testen Sie die Installation der Zertifizierungsstelle, die Verwendung von Vorlagen, die MMC-/certreq-Registrierung, OCSP und Authenticode vollständig. Erstellen Sie eine Kompatibilitätsmatrix für die vertrauenden Parteien (Windows, OpenSSL 3.5+, Java, Netzwerkgeräte, Middleware). Messen Sie die Größen- und Leistungsunterschiede. Entwerfen Sie jetzt die CP/CPS-Änderungen und HSM-Anforderungen, solange noch keine Dringlichkeit besteht.
2. Gezielte Produktionsnutzung	2027 – 2028	Verlagern Sie zunächst die Signaturprozesse im geschlossenen Regelkreis (interne Codesignierung, Infrastrukturattestierung, Dokumentensignierung) dorthin, wo Sie jeden Validator kontrollieren. Führen Sie mit der Einführung von Phase 2 zusammengesetzte Zertifikate für gemischte Vertrauenspfade ein. Integrieren Sie die PQC-Unterstützung in die Beschaffungssprache, sodass jedes neue Gerät, HSM und jede Anwendung sofort einsatzbereit ist.
3. Hierarchieübergang	2028 – 2030	Stellen Sie die nächste Generation von Stammzertifizierungsstellen und ausstellenden Zertifizierungsstellen als ML-DSA oder als zusammengesetzte Zertifizierungsstellen ein. Stellen Sie die Neuausstellung von Zertifikaten vor der Abschaffung von RSA-2048 und P-256 standardmäßig um. Integrieren Sie ML-KEM für TLS, sobald Windows und Ihre Load-Balancing-/Inspektionsarchitektur dies ermöglichen.
4. Vermögensübertragung und Ruhestand	2030 – 2033	Massenmigration von Blattbeständen mithilfe von automatisierte Werkzeuge für den ZertifikatslebenszyklusAngesichts der heutigen Zertifikatsmengen und immer kürzeren Gültigkeitsdauern ist die manuelle Migration keine praktikable Lösung. Klassische Hierarchien sollten gemäß einem veröffentlichten Zeitplan, der mit Microsofts Ziel der vollständigen Umstellung im Jahr 2033 übereinstimmt, außer Betrieb genommen werden.
Harter Stopp	2035	RSA, ECDSA und klassisches DH sind gemäß NIST IR 8547 nicht zulässig. Nichts, was quantenanfällig ist, sollte in produktiven Vertrauenspfaden verbleiben.

Was dies über die Zukunft von AD CS aussagt

Hier gibt es ein wichtiges Signal zweiter Ordnung, das Beachtung verdient. Ein Jahrzehnt lang ging man davon aus, dass AD CS keine nennenswerten Investitionen mehr erhalten würde, und die Plattformentscheidungen wurden entsprechend getroffen. Die Bereitstellung eines aktuellen NIST-konformen Signaturalgorithmus (mit einer veröffentlichten, mehrstufigen Roadmap für ML-KEM, zusammengesetzte Zertifikate und die Registrierungsdienste) ist kein typisches Wartungsverhalten.

Der Zeitpunkt fällt auch mit einer weniger offensichtlichen Veränderung im Ökosystem öffentlicher Vertrauenszertifizierungsstellen zusammen: Öffentliche Zertifizierungsstellen entfernen die Client-Authentifizierungs-EKU aus TLS-Zertifikaten, da Root-Programme Server- und Client-Vertrauen trennen. Dies bedeutet, dass die riesige Welt von mTLS (Service Meshes, Geräteflotten, B2B-API-Authentifizierung) – ob geplant oder nicht – zu privaten Zertifizierungsstellen migriert. Eine private Zertifizierungsstellenplattform, die in der Betriebssystemlizenz enthalten ist, sich in Active Directory integriert und nun mit Post-Quantum-Algorithmen signiert, ist plötzlich eine sehr sinnvolle Lösung für diese Workloads. AD CS übersteht den Übergang zu PQC nicht nur, sondern nutzt ihn, um wieder aktiv mitzuwirken.

Wie kann Verschlüsselungsberatung helfen?

Alles oben Genannte reduziert sich auf ein Sequenzierungsproblem: Man muss den vorhandenen Bestand kennen, die Funktionalität nachweisen, den Austausch automatisieren und die bereits festgelegten Termine einhalten. Genau darauf basiert die tägliche Arbeit von Encryption Consulting: Wir haben über 100 Fortune-500-Unternehmen bei der Bewertung, dem Design und dem Betrieb ihrer kryptografischen Infrastrukturen unterstützt, und unsere PQC-Beratungsdienste wurden genau für diesen Übergang entwickelt.

Wo Teams stecken bleiben	Wie wir helfen
„Wir wissen eigentlich nicht, wo in unserer Umgebung quantenanfällige Kryptographie vorkommt.“	Unser PQC-Beratungsauftrag beginnt mit einer Quantenbedrohungsanalyse, CBOM Secure Erstellt eine automatisierte, kontinuierlich aktualisierte kryptografische Stückliste über Zertifikate, Schlüssel, Algorithmen und Protokolle hinweg: das Inventar, auf dem jede spätere Phase basiert.
„Wir brauchen einen nachvollziehbaren Fahrplan, kein wissenschaftliches Projekt.“	Wir liefern einen Fahrplan und eine Strategie zur Quantenbereitschaft, die auf die Richtlinien von NIST, CISA und NSA abgestimmt sind: gestaffelte Meilensteine, ein agiles Betriebsmodell für Kryptotechnologie und eine Machbarkeitsstudie zur Validierung von Kandidatenalgorithmen, bevor diese in die Produktion gehen.
„Unsere AD CS-Landschaft benötigt eine parallele, ordnungsgemäß konzipierte PQ-Hierarchie.“	Unsere PKI-Bewertung Die Design-/Implementierungsdienstleistungen umfassen Hierarchiearchitektur, HSM-Integration, CP/CPS-Entwicklung und Template-Governance, und PKI-as-a-Service Sie können die Post-Quanten-Generation auf FIPS 140-3 Level 3 HSMs hosten, wenn Sie sie lieber konsumieren als selbst bauen möchten.
„Wenn sich der Algorithmus ändert, müssen wir Zehntausende von Zertifikaten verschieben.“	CertSecure ManagerUnsere Plattform für das Management des Zertifikatslebenszyklus wurde mit Krypto-Agilität als Kern entwickelt: kontinuierliche Erkennung über AD CS, HashiCorp Vault, Cloud- und Appliance-Umgebungen hinweg, risikoprofilierte Bestandsaufnahme und automatische Erneuerung im Flottenmaßstab: So wird eine Algorithmusmigration zu einer Richtlinienänderung und nicht zu einem Projekt, das sich über mehrere Quartale erstreckt.
„Unsere Codesignatur muss den Übergang unbeschadet überstehen.“	CodeSign Secure bietet richtlinienbasierte, HSM-gestützte Signatur-Workflows für Windows, Linux, macOS und CI/CD-Pipelines: die natürliche Steuerungsebene für die Migration von Authenticode und Firmware-Signierung auf Post-Quanten-Algorithmen.

Häufig gestellte Fragen

Kann ich meine bestehende AD CS CA auf ML-DSA aktualisieren?

Nein. ML-DSA-Zertifizierungsstellen müssen neu installiert werden: Eine direkte Konvertierung oder eine Erneuerung mit neuem Algorithmus ist nicht möglich, da die Änderung des Public-Key-Algorithmus einen neuen Schlüssel und eine neue Zertifizierungsstellenidentität erfordert. Das unterstützte Muster ist eine parallele Post-Quantum-Hierarchie, die während der Workload-Migration neben Ihrer bestehenden PKI betrieben wird.

Macht ML-DSA in AD CS mein TLS quantensicher?

Noch nicht. ML-DSA deckt Signaturen ab: Zertifikats- und OCSP-Integrität, Codesignierung und Identitätsauthentifizierung. Die Vertraulichkeit von Sitzungen hängt vom Schlüsselaustausch ab, der ML-KEM über den TLS-Stack erfordert; aktuell bindet IIS nicht einmal ein ML-DSA-Serverzertifikat für HTTPS . Der Schutz von Daten während der Übertragung (Erfassung und spätere Entschlüsselung) wird erst mit der Schlüsselkapselungsphase erreicht, nicht mit dieser.

Auf welchen Parametersatz sollte ich mich standardisieren?

ML-DSA-65 (NIST-Kategorie 3) ist der pragmatische Standard für die Ausstellung von Zertifizierungsstellen und Endbenutzerzertifikaten. ML-DSA-87 sollte für Root-Zertifikate und langlebige Anker-Zertifikate reserviert werden, bei denen die maximale Sicherheitsmarge die Größe rechtfertigt. ML-DSA-44 ist als bewusste Ausnahme für größenbeschränkte Szenarien zu betrachten, in denen Kategorie 2 eine akzeptable Risikoentscheidung darstellt.

Warum kann ich keinen Hash-Algorithmus mehr auswählen?

Da FIPS 204 die Nachrichtenverarbeitung in das Signaturverfahren integriert, ist kein separater Hash- und anschließender Signierschritt zu konfigurieren. AD CS stellt dies mit der einzigen Option „NoHash“ dar. Denken Sie daran, diese Option bei skriptgesteuerten Installationen explizit anzugeben; die Standardeinstellungen der Setup-Engine bleiben RSA/SHA-256 und werden bei Auswahl eines ML-DSA-Schlüssels nicht automatisch korrigiert.

Wird Windows Server 2019 oder 2022 PQC-Unterstützung erhalten?

Es gibt keine Hinweise auf eine Rückportierung: PQC in AD CS ist eine Funktion von Windows Server 2025. Wenn Ihre Zertifizierungsstellen auf älteren Plattformen laufen, befindet sich das Betriebssystem-Upgrade nun auf dem kritischen Pfad nach der Quantenintegration und gehört in die Planung des nächsten Jahres, nicht in die der 2030er Jahre.

Wann müssen wir wirklich handeln?

Der Druck zur Abschaffung von RSA-2048 und ECDSA P-256 beginnt 2030 gemäß NIST IR 8547, mit einem endgültigen Verbot aller quantenanfälligen Public-Key-Algorithmen ab 2035. CNSA 2.0 treibt die Umsetzung dieses Themas bereits ab 2027 über das Beschaffungswesen voran. Entscheidend ist jedoch die Gültigkeitsdauer Ihrer Zertifikate: Langfristige Zertifikate, die heute ausgestellt werden, überschneiden sich bereits mit diesen Daten. Die Bestandsaufnahme sollte jetzt beginnen; der Algorithmuswechsel erfolgt dann nach Ihrem Zeitplan und nicht nach dem eines Auditors.

Fazit

Das Update vom Mai 2026 kann als Startschuss verstanden werden. AD CS kann nun eine vollständig postquantenbasierte Signaturebene (CA-Hierarchie, Ausstellung, OCSP, Codesignierung ) auf Basis standardisierter, NIST-konformer Kryptografie aufbauen. Schlüsselkapselung und zusammengesetzte Zertifikate sind bereits in der veröffentlichten Roadmap enthalten. Die technologische Frage hat sich von „Wann zieht Microsoft nach?“ zu „Wie gut ist meine IT-Infrastruktur darauf vorbereitet?“ verschoben.

Die Unsicherheit bezüglich Quantenhardware wirkt sich in beide Richtungen aus, der Zeitplan für die Einhaltung der Vorschriften jedoch nicht: 2030 und 2035 sind festgelegt, und die heute unterzeichneten Vertrauensanker werden auch zu diesen Zeitpunkten noch Gültigkeit haben. Organisationen, die diesen Übergang souverän meistern, behandeln ihn als Programm zur Steigerung der Krypto-Agilität: Zuerst die Bestandsaufnahme, dann die Automatisierung, erst an dritter Stelle die Algorithmen. Bauen Sie eine Laborhierarchie auf, identifizieren Sie Inkompatibilitäten, solange sie noch kostengünstig sind, und nehmen Sie den eigentlichen Umstieg in Kauf. So sah gutes PKI-Engineering schon immer aus.

Referenzen & weiterführende Literatur

• Post-Quanten-Kryptographie in AD CS – Übersicht (Microsoft Learn)
• Was ist ML-DSA-Unterstützung in AD CS? (Microsoft Learn)
• KB5087539: Sicherheitsupdate vom 12. Mai 2026 für Windows Server 2025
• Microsoft Security Community: Post-Quanten-Kryptografie-APIs jetzt allgemein auf Microsoft-Plattformen verfügbar