Microsoft behandelt post-quantenfeste Authentifizierung nicht mehr als fernes Forschungsthema. Das Unternehmen hat nach eigenen Angaben sein Quantum Safe Program beschleunigt und peilt nun an, kritische Produkte und Dienste bis 2029 auf Post-Quantum-Kryptografie umzustellen. Der zuvor kommunizierte Zielpunkt lag bei 2033. Für Unternehmen ist daran weniger die Jahreszahl allein relevant. Entscheidend ist, dass Microsoft den Übergang in die operative Phase schiebt.
Am 27. August 2026 hat Microsoft nach eigenen Angaben ein PQC TLS Pilot Program gestartet. Es soll zugelassenen Zertifizierungsstellen aus dem Microsoft Trusted Root Program ermöglichen, post-quantenfeste TLS-Hierarchien und die Ausgabe entsprechender Zertifikate praktisch zu erproben. Verwendet wird dabei ML-DSA-87, eine Variante des Module-Lattice-Based Digital Signature Algorithm. Als Beteiligte nennt Microsoft ComSign, DigiCert, HARICA, IdenTrust Services, Sectigo, Shanghai Electronic Certification Authority und SSL.com.
Die Hauptfolge liegt nicht bei einzelnen Algorithmen. Sie liegt in den Zertifikatsketten, die Unternehmen über Jahre aufgebaut haben. Authentifizierung hängt an CAs, Zwischenzertifikaten, Hardware Security Modules, Load Balancern, Appliances, Verzeichnisdiensten, internen Anwendungen, mobilen Clients, eingebetteten Systemen und Betriebsprozessen. Viele dieser Abhängigkeiten sind nicht vollständig dokumentiert. Genau dort beginnt das Problem.
Standardisierung löst noch keine Migration
Die technische Grundlage ist inzwischen klarer als noch vor wenigen Jahren. Das US-Normungsinstitut NIST hat am 13. August 2024 die ersten drei finalen Standards für Post-Quantum-Kryptografie veröffentlicht: FIPS 203 für ML-KEM, FIPS 204 für ML-DSA und FIPS 205. Damit sind zentrale Bausteine festgelegt. Daraus folgt aber nicht, dass Unternehmensinfrastrukturen bereit sind.
Operativer Pfad zur PQC-Zertifikatsmigration
Die Grafik zeigt den praktischen Ablauf von der bestehenden PKI über Inventarisierung und parallele PQC-CA bis zu Tests und späterer Migration.
Bei Verschlüsselung wird häufig auf das Risiko verwiesen, dass Daten heute abgegriffen und später mit leistungsfähigeren Quantencomputern entschlüsselt werden könnten. Bei Authentifizierung ist die Lage anders. Zertifikate entscheiden darüber, ob ein System einem anderen System vertraut. Wenn diese Vertrauensbeziehungen nicht funktionieren, brechen Verbindungen nicht abstrakt, sondern konkret: TLS-Verbindungen schlagen fehl, Geräte akzeptieren Zertifikate nicht, interne Dienste starten nicht, Automatisierungsketten bleiben hängen.
Das macht die Migration schwerer planbar. Ein Algorithmuswechsel ist in einer isolierten Bibliothek relativ überschaubar. Ein Wechsel in einem Zertifikatsökosystem berührt Ausgabe, Speicherung, Validierung, Laufzeiten, Sperrlisten, Monitoring, Compliance-Vorgaben und Notfallprozesse. Zusätzlich müssen Clients und Server dieselben Formate, Signaturen und Zertifikatsgrößen verarbeiten können. Schon kleine Inkompatibilitäten können produktive Systeme stören.
ADCS zeigt den operativen Aufwand
Microsoft hat Active Directory Certificate Services nach eigenen Angaben im Mai 2026 um die Fähigkeit erweitert, post-quantenfeste Zertifikate zu erzeugen. Das ist für viele Unternehmen relevant, weil ADCS in internen Windows-Umgebungen häufig die zentrale PKI-Komponente ist. Der wichtige operative Punkt: Bestehende Zertifizierungsstellen lassen sich nach aktuellem Microsoft-Stand dafür nicht einfach per In-place-Upgrade umstellen. Erforderlich sind neu erstellte CAs, die parallel betrieben werden.
Das verändert die Projektlogik. Unternehmen müssen nicht nur eine Softwareversion aktualisieren. Sie müssen neue Zertifikatsketten aufbauen, Vertrauensanker verteilen, Richtlinien prüfen und testen, welche Anwendungen mit welchen Zertifikaten umgehen können. Parallelbetrieb ist dabei kein Randdetail. Er ist die praktische Voraussetzung, um PQC-Unterstützung zu testen, ohne bestehende Authentifizierung zu beschädigen.
Für IT-Teams bedeutet das zunächst Bestandsarbeit. Welche Systeme beziehen Zertifikate aus welcher CA? Welche Zertifikate haben lange Laufzeiten? Welche Anwendungen pinnen bestimmte Zertifikate oder akzeptieren nur bestimmte Algorithmen? Welche Appliances werden vom Hersteller noch gepflegt? Welche Maschinen können nur mit manuellen Zertifikatsprozessen versorgt werden? Ohne diese Übersicht wird eine PQC-Migration zu einem Blindflug.
Testumgebungen werden wichtiger als Roadmaps
Hersteller-Roadmaps bleiben notwendig, reichen aber nicht aus. Ein Lieferant kann Unterstützung für einen Standard ankündigen, ohne dass die Kombination aus Unternehmensrichtlinien, Zertifikatsprofilen, Zwischenzertifikaten und Clientverhalten bereits funktioniert. Microsofts Pilotprogramm zielt deshalb auf praktische Erfahrung im Zertifikatsbetrieb. Das ist der richtige Schwerpunkt: Nicht die Existenz eines Standards entscheidet über Einsatzfähigkeit, sondern Interoperabilität.
Unternehmen sollten den Übergang deshalb nicht zuerst als Beschaffungsprojekt behandeln. Zuerst braucht es nicht-produktive Testumgebungen mit realistischen Zertifikatsketten. Dort lässt sich prüfen, ob Webserver, Proxies, VPN-Gateways, E-Mail-Systeme, Geräteverwaltung, interne APIs und Identitätsdienste PQC-Zertifikate verarbeiten können. Ebenso wichtig ist die Frage, ob Überwachung, Inventarisierung und Erneuerung der Zertifikate angepasst werden müssen.
Eine Besonderheit liegt bei langlebiger Infrastruktur. Industrieanlagen, medizinische Geräte, Netzwerktechnik oder eingebettete Systeme werden oft deutlich länger betrieben als klassische Server. Wenn solche Systeme feste kryptografische Annahmen enthalten, kann ein späterer Wechsel teuer oder unmöglich werden. Für diese Bereiche ist frühes Testen weniger eine Sicherheitsübung als eine Lebenszyklusprüfung.
Crypto-Agility wird praktisch messbar
Der Begriff Crypto-Agility wird häufig allgemein verwendet. In diesem Fall lässt er sich konkreter fassen: Kann eine Organisation kryptografische Verfahren austauschen, ohne jedes System einzeln und manuell anfassen zu müssen? Gibt es ein vollständiges Zertifikatsinventar? Lassen sich Zertifikatsprofile zentral steuern? Sind Erneuerungen automatisiert? Werden Abhängigkeiten zu Herstellern dokumentiert? Gibt es klare Verfahren für Rückfall und Parallelbetrieb?
Diese Fragen betreffen Anbieter und Kunden gleichermaßen. Anbieter von Sicherheitssoftware, Appliances, Cloud-Diensten und Unternehmensanwendungen müssen zeigen, wie ihre Produkte mit PQC-Zertifikaten umgehen. Kunden dürften diese Fähigkeit nicht nur in Compliance-Fragebögen abfragen, sondern in technischen Tests. Zertifizierungsstellen erhalten eine größere Rolle, weil ihre Infrastruktur, ihre Prozesse und ihre Unterstützung neuer Zertifikatsprofile direkt auf die Migrationsfähigkeit ihrer Kunden wirken.
Microsoft profitiert in diesem Prozess von seiner Stellung in Unternehmensinfrastrukturen. Windows, Entra, ADCS, Entwicklerplattformen und Cloud-Dienste bilden viele Berührungspunkte mit Zertifikatsverwaltung. Das heißt aber nicht, dass Microsoft die Migration allein steuert. Die eigentliche Arbeit liegt verteilt bei CAs, Softwareherstellern, Geräteanbietern, IT-Abteilungen und Sicherheitsdienstleistern.
Der frühe Aufwand vermeidet spätere Betriebsrisiken
Die knappe Schlussfolgerung ist operativ: Unternehmen sollten jetzt ihre Zertifikatslandschaft erfassen und PQC-Zertifikate außerhalb der Produktion testen. Nicht, weil morgen alle heutigen Verfahren wertlos wären. Sondern weil die Umstellung von Authentifizierungssystemen Jahre dauert und viele Abhängigkeiten erst sichtbar werden, wenn man sie testet.
Microsofts beschleunigter Zeitplan bis 2029 erhöht den Druck auf diese Vorarbeit. Wer erst auf verpflichtende Vorgaben, auslaufende Produkte oder kurzfristige Herstellerankündigungen reagiert, wird weniger Spielraum haben. Die Arbeit beginnt bei unspektakulären Dingen: Inventar, Test-CA, Zertifikatsprofile, Clientprüfung, Herstellerabfragen, Parallelbetrieb. Genau diese Details entscheiden darüber, ob post-quantenfeste Authentifizierung später eine geplante Migration wird oder eine Serie von Betriebsstörungen.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
