Post-Quantum-Kryptografie für ADCS — Roadmap und Pilotprojekt

Was mit dem Mai-2026-Update live geht, was noch fehlt, und wie ein sauberes Pilotprojekt aussieht

Kurzfassung vorab

Seit dem Mai-2026-Update für Windows Server 2025 ist Post-Quantum-Kryptografie in ADCS angekommen. ML-DSA-44, -65 und -87 stehen als Algorithmen im CA-Properties-Dropdown zur Auswahl — kein Beta, kein Insider-Preview, sondern reguläres Patch-Tuesday-Update. Damit beendet Microsoft die jahrelange Theorie-Phase, in der PQC für ADCS „demnächst" hieß. Jetzt geht echtes Pilotieren.

Das heißt nicht, dass du am Montag deine Produktiv-Root-CA umstellen sollst. Es heißt: Du kannst — und solltest — anfangen, eine isolierte Pilotumgebung aufzubauen, deine Anwendungslandschaft auf PQ-Tauglichkeit prüfen und die Crypto-Agility-Hausaufgaben endlich machen. Die ehrliche Roadmap dahinter umfasst vier Phasen, und die Reihenfolge ist nicht verhandelbar.

Abb. 1: Die PQC-Roadmap aus ADCS-Sicht — Mai 2026 markiert den Übergang von „theoretisch interessant" zu „technisch verfügbar".

1. Was sich Mai 2026 in ADCS geändert hat

Bis April 2026 war PQC für ADCS ein Roadmap-Punkt mit unklarer Liefermenge. Microsoft hatte im November 2025 die Cryptography API: Next Generation (CNG) auf Windows Server 2025 und Windows 11 für ML-KEM und ML-DSA freigeschaltet, aber ADCS selbst konnte mit den neuen Algorithmen noch nichts anfangen. Du konntest also auf der Maschine kryptografische Operationen mit PQ-Algorithmen ausführen, aber keine PQ-Zertifikate ausstellen. Das war so, als ob du einen V12-Motor in der Garage stehen hast, aber kein Auto drumherum.

Mit dem Patch-Tuesday-Update vom 12. Mai 2026 ändert sich genau das. Auf einer Issuing CA unter Windows Server 2025 erscheinen nach dem Update unter Provider Category „Key Storage Provider" drei neue Einträge im Algorithm-Name-Dropdown: ML-DSA-44, ML-DSA-65 und ML-DSA-87. Die Microsoft Software Key Storage Provider unterstützt sie nativ, HSM-Hersteller wie Thales, Utimaco und Yubico ziehen seit Wochen Firmware-Updates für die PQ-Algorithmen nach. Das Fundament für ein echtes Pilotprojekt steht.

Was du noch nicht bekommst: native PQC für Schlüsselkapselung im TLS-Handshake (Schannel-Integration ist angekündigt, aber nicht produktiv), öffentlich vertrauenswürdige PQ-TLS-Zertifikate (das CA/B Forum diskutiert das, finalisierte Baseline Requirements werden 2027 erwartet), und PQC-Support auf älteren Server-Versionen — Windows Server 2022 und früher bekommen keine PQ-Erweiterung mehr. Wer also PQ-Pilot machen will, muss erstens auf Windows Server 2025 sein und zweitens akzeptieren, dass interne Anwendungen die ersten Kunden sind.

2. NIST-Standards in fünf Minuten — die drei Algorithmen

NIST hat im August 2024 die ersten Post-Quantum-Standards finalisiert. Drei Algorithmen sind dabei für ADCS-Verantwortliche wirklich relevant — der Rest ist akademisch interessant, aber für die nächsten drei Jahre nicht produktiv. Kurzfassung:

Für den Pilot beschäftigst du dich also primär mit ML-DSA. Die drei Parameter-Sets ML-DSA-44, ML-DSA-65 und ML-DSA-87 unterscheiden sich nicht im Algorithmus, sondern in der Sicherheitsstufe — und damit in der Schlüssel- und Signaturgröße. Die Wahl hat handfeste Konsequenzen für CPU-Last, Bandbreite, MTU-Settings und Firewall-Toleranz.

Abb. 2: Die drei ML-DSA-Varianten im Vergleich — Größe, Sicherheit, Performance-Impact und der typische Einsatzort.

Die kurze Empfehlung: ML-DSA-65 für die Standardfälle, also Issuing-CA-Zertifikate, User- und Server-Zertifikate. ML-DSA-44 für ressourcenbeschränkte Endgeräte und Massen-Enrollment. ML-DSA-87 reservierst du für Root-CAs und Compliance-getriebene Bereiche, in denen CNSA 2.0 oder vergleichbare Vorgaben Level 5 zwingen. Wer ML-DSA-87 für jeden Webserver verwendet, hat anschließend ein Performance-Problem und keinen messbaren Sicherheitsgewinn.

3. Die ehrliche Roadmap — vier Phasen bis zur PQ-PKI

Die Phasenlogik, die ich seit etwa zwei Jahren mit Kunden durchziehe, ist seit Mai 2026 nicht obsolet geworden — sie hat im Gegenteil endlich ihren Endpunkt bekommen. Vier Phasen, eine klare Reihenfolge:

Abb. 3: Vier Phasen bis zur PQ-PKI — Crypto-Inventur, ECC-Trockenübung, Hybrid-Pilot, voller Rollout.

Phase 1 — CBOM-Inventur

Bevor du ML-DSA überhaupt anfasst, musst du wissen, welche Systeme heute welche Kryptografie nutzen. Cryptographic Bill of Materials nach CycloneDX 1.6 ist das Mittel der Wahl, eine ehrliche Excel-Liste tut es in der ersten Iteration auch. Erfasse pro System: Zweck, Algorithmus, Schlüssellänge, Hashverfahren, Zertifikatslebensdauer, Eigentümer. Dauer: zwei bis sechs Wochen, je nach Größe der Umgebung.

Phase 2 — ECC-Trockenübung

Niemand wechselt heute noch von RSA auf ECC, weil ECC neu ist — die meisten Umgebungen haben es ohnehin schon irgendwo. Aber ein vollständiger Algorithmenwechsel über alle Templates, Anwendungen und HSM-Konfigurationen hinweg ist die beste Generalprobe, die du für den späteren PQ-Wechsel bekommen kannst. Du findest in der Phase 80 Prozent der Stolperfallen, die dich später bei ML-DSA auch erwischen würden — und das mit etablierter Technologie, bei der jede Fehlermeldung googelbar ist.

Phase 3 — Hybrid-Pilot mit ML-DSA

Erst hier wird PQC konkret. Eine isolierte Test-Issuing-CA mit ML-DSA-65, drei bis vier Pilotanwendungen, sauberes Messen von Performance, MTU-Verhalten und Anwendungskompatibilität. Dauer: drei bis sechs Monate, weil du nicht nur die CA aufsetzen, sondern auch die Anwendungswelt einzeln durchgehen musst. Welche Browser akzeptieren ML-DSA-Zertifikate? Welche Reverse-Proxies fragmentieren bei 4 KB Signatur? Welche Firewall-Inspection wirft den Handshake weg, weil sie das unbekannte Format als Anomalie wertet?

Phase 4 — Volle PQ-PKI

Das ist der Endzustand: neue Root-CA mit ML-DSA-87, Hybrid- und reine PQ-Issuing-CAs parallel zur klassischen Welt, schrittweise Migration der Anwendungen. Realistischer Zeitrahmen: 2028 bis 2029, wenn nicht später. Bis dahin bleibt deine produktive PKI klassisch — das ist nicht peinlich, das ist verantwortungsbewusst.

4. Pilotumgebung — wie sie aussehen sollte

Die wichtigste Regel: Die Pilotumgebung ist von der Produktion entkoppelt. Keine Cross-Trust, keine gemeinsame AD-Domäne, im Idealfall ein eigenes Netzsegment. Das hat zwei Gründe: Erstens willst du nicht versehentlich einen halbgaren PQ-Algorithmus in einen produktiven Vertrauensanker bekommen. Zweitens willst du im Pilot Dinge ausprobieren dürfen, die in der Produktion absolut tabu wären — Algorithmen wechseln, Templates umstellen, Schlüssel neu generieren, das HSM aus und an stecken.

Abb. 4: Die typische Pilotarchitektur — links die unangetastete Produktion, rechts der isolierte PQ-Pilot mit eigener Root- und Issuing-CA.

Eine bewährte Komposition für den Pilot sieht so aus: Eine Test-Root-CA mit ML-DSA-87, die nur die Test-Issuing-CA signiert. Eine Test-Issuing-CA mit ML-DSA-65, die für die Pilotanwendungen Zertifikate ausstellt. Zwei bis drei Test-Webserver in verschiedenen Geschmacksrichtungen (IIS, Nginx, Apache) — das deckt die Realität deiner Produktion ab. Eine Handvoll Test-Clients auf verschiedenen Plattformen, weil die Browser- und Tooling-Unterstützung für ML-DSA noch sehr unterschiedlich aussieht.

Beim HSM kommt eine ehrliche Frage: brauchst du im Pilot wirklich eines? Antwort: nein, nicht zwingend. Der Microsoft Software Key Storage Provider reicht, um die Algorithmen zu evaluieren und Anwendungen zu testen. Wenn du aber realistische HSM-Performance messen willst — und das solltest du, weil ML-DSA-Operationen deutlich langsamer sind als RSA — dann brauchst du im Pilot dieselbe HSM-Klasse wie später in der Produktion. YubiHSM 2 ab Firmware 2.5 unterstützt ML-DSA, Thales Luna und Utimaco SecurityServer ab den 2026er Firmware-Releases ebenfalls. Wer ein älteres HSM hat, sollte die Pilotphase nutzen, um beim Hersteller den Upgrade-Pfad zu klären.

5. Pilot-CA aufsetzen — PowerShell mit Augenmaß

Nach dem Mai-2026-Update geht das Setup einer PQ-Issuing-CA in vier Schritten: Maschine vorbereiten, ADCS-Rolle installieren, CA konfigurieren mit ML-DSA als Schlüsselalgorithmus, prüfen ob das Setup wirklich PQ macht. Der folgende Block ist die Kurzfassung — produktiv würdest du natürlich noch CRL-Distributionspoint, AIA, Backup und Monitoring sauber einrichten. Aber zum Reinriechen reicht das.

Wer das Skript zum ersten Mal laufen lässt und keine ML-DSA-Einträge in der CA-Konsole sieht, hat in 90 Prozent der Fälle vergessen, den Provider Category Dropdown auf „Key Storage Provider" umzustellen. Microsoft hat die PQ-Algorithmen nicht in den älteren Cryptographic Service Provider eingehängt, sondern nur in den moderneren KSP. Wer alte Templates aus der Standalone-Welt importiert, fällt manchmal in diese Falle.

6. Typische Stolperfallen im PQ-Pilot

Ein paar Punkte, die in den ersten echten Pilotprojekten immer wieder auftauchen — kompakt für die Vorab-Vermeidung:

Praxis-Beispiel · Trendforge Digital GmbH

Die Trendforge Digital GmbH, Tech-Scaleup mit 400 Mitarbeitern und entwicklungsgetriebener Cloud-Affinität, hat im April 2026 — also einen Monat vor dem ADCS-Update — die CBOM-Inventur abgeschlossen. Ergebnis: 1.840 aktive Zertifikate auf 12 internen Systemen, davon 14 Prozent noch mit RSA-2048-SHA-1-Verkettungen (Altlasten aus einer 2019er Migration, die unentdeckt durchlief). Die Phase 2 — ECC-Trockenübung — lief zwischen Mai und August 2026 und brachte vier Templates ans Licht, die nicht auf ECC migrierbar waren, weil die anhängenden Java-Anwendungen den Bouncy-Castle-Provider auf einem Stand von 2017 hatten.

Den Hybrid-Pilot startete Trendforge ab September 2026. Eine PQ-Test-Issuing-CA mit ML-DSA-65 auf Windows Server 2025, ein YubiHSM 2 mit aktueller Firmware, drei Test-Webserver hinter dem internen Nginx-Reverse-Proxy. Die ersten Messungen zeigten überraschend hohe MTU-Probleme über das interne MPLS — der Reverse-Proxy fragmentierte ML-DSA-Signaturen bei 4 KB, weil ein altes Pufferlimit ungeprüft seit Jahren so eingestellt war. Das Fixen war eine Konfigurationszeile, das Finden hätte ohne den Pilot ein peinliches Outage-Ticket nach Phase 4 gegeben.

Stand Mitte 2027: Trendforge betreibt parallel die klassische ADCS-Hierarchie und die PQ-Pilotumgebung, hat fünf interne Anwendungen vollständig auf Hybrid-Zertifikate umgestellt und plant für Anfang 2028 den Beginn der Phase 4. Das Investment in die Pilotphase: knapp 25 Tage externe Begleitung plus zwei interne FTEs für vier Monate. Im Verhältnis zum sonst drohenden Last-Minute-Migrationsdrama in 2029 ist das Komfortzone.

Verwandte Themen

Häufige Fragen (FAQ)

Was ist der Unterschied zwischen ML-DSA-44, ML-DSA-65 und ML-DSA-87?

Es ist immer derselbe Algorithmus, nur mit unterschiedlichen Parameter-Sets — also unterschiedlichen Sicherheitsstufen und damit unterschiedlichen Schlüssel- und Signaturgrößen. ML-DSA-44 entspricht NIST Level 2 (etwa AES-128), ML-DSA-65 entspricht Level 3 (AES-192), ML-DSA-87 entspricht Level 5 (AES-256). Für die meisten Unternehmen ist ML-DSA-65 die richtige Wahl; ML-DSA-87 nur wo Compliance es vorschreibt.

Brauche ich ein PQ-fähiges HSM für mein Pilotprojekt?

Im reinen Erkenntnis-Pilot nicht — der Microsoft Software Key Storage Provider reicht. Wenn du allerdings Performance-Messungen machen willst, die später auf die Produktion übertragbar sind, brauchst du dasselbe HSM-Modell, das du auch produktiv einsetzen würdest. YubiHSM 2 ab Firmware 2.5, Thales Luna und Utimaco SecurityServer ab ihren 2026er Releases unterstützen ML-DSA. Ältere Modelle bekommen die Algorithmen teilweise per Firmware-Update nach.

Kann ich PQC schon auf öffentlich vertrauenswürdigen TLS-Zertifikaten einsetzen?

Nein. Das CA/B Forum hat in den Baseline Requirements aktuell ausschließlich RSA und ECC für öffentlich vertrauenswürdige TLS-Zertifikate zugelassen. Eine Erweiterung um ML-DSA wird 2027 erwartet, vermutlich zusammen mit Composite-ML-DSA-Konstrukten. Solange das nicht durch ist, läuft ML-DSA in deiner internen PKI — und damit auf Komponenten, die deinem eigenen Vertrauensanker folgen.

Ab wann sollte ich anfangen, mich um PQC zu kümmern?

Heute, in dieser Reihenfolge: CBOM-Inventur (Phase 1), dann ECC-Trockenübung (Phase 2), dann Hybrid-Pilot (Phase 3). Wer 2026 mit Phase 1 startet, hat 2028 einen belastbaren Pilot und kann ab 2029 entspannt in den produktiven Rollout gehen. Wer 2028 erst mit Phase 1 anfängt, wird 2030 unter Zeitdruck Migrationsentscheidungen treffen müssen.

Funktioniert „Harvest now, decrypt later" wirklich oder ist das Hype?

Das ist kein Hype, sondern ein dokumentiertes Bedrohungsmodell von NSA, BSI und ENISA. Verschlüsselte Daten, die heute über Glasfaser oder via gehackten Cloud-Provider abgegriffen werden, kann ein hinreichend leistungsfähiger Quantencomputer in zehn bis fünfzehn Jahren entschlüsseln. Für Daten mit langer Schutzbedürftigkeit (Patente, Personalakten, Staatsgeheimnisse, Krankenakten) ist das ein reales Problem — heute. Für eine Tageszeitungsausgabe von 2026 eher weniger.

Wie unterscheiden sich Hybrid-Zertifikate von puren PQC-Zertifikaten?

Pure PQC-Zertifikate enthalten nur einen Schlüssel und eine Signatur, beides nach ML-DSA. Sie funktionieren nur in Anwendungen, die ML-DSA verstehen — was aktuell sehr wenige sind. Hybrid-Zertifikate (auch Composite-Zertifikate) enthalten zwei Schlüssel und zwei Signaturen: klassisch (RSA/ECC) und PQC parallel. Anwendungen, die nur klassisch können, ignorieren den PQ-Anteil und nutzen den RSA-Teil; PQ-fähige Anwendungen wählen den ML-DSA-Pfad. Die Details und den konkreten Aufbau im ADCS-Kontext zeigt Spoke 6.4.

Nächste Schritte mit boddenberg.de

PQC-Migration ist kein Thema, das du am Wochenende neben dem Backup-Job erledigst. Drei klar geschnittene Pakete, die in dem Bereich Sinn ergeben:

Wer parallel ein Auge auf seine TLS-Erneuerungsprozesse werfen will, schaut sich CertBinder an (siehe Spoke 5.2) — gerade in der Pilotphase ist atomare TLS-Erneuerung sehr nützlich, weil du Zertifikate häufiger als sonst austauschen wirst. Außerdem in Arbeit: das PKI-Buch „PKI und Zertifikate in modernen Microsoft-Umgebungen", das die Themen aus Pillar und Spokes in einem zusammenhängenden Werk vertieft.

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund