Microsoft weist im Security Blog darauf hin, dass die Vorbereitung auf Post-Quantum-Kryptografie nicht bei verschlüsselten Daten endet. Auch die Authentifizierung über Zertifikate muss geprüft werden: Zertifikatsketten, Vertrauensanker, PKI-Dienste, Anwendungen, Geräte und Sicherheitsmodule können von neuen Algorithmen und größeren Zertifikaten betroffen sein. Für kleinere Unternehmen ist das kein Grund für hektische Umstellungen, aber ein guter Anlass, Zertifikatsabhängigkeiten endlich sichtbar zu machen.
Warum Zertifikate jetzt auf die Prüfliste gehören
Microsoft beschreibt Post-Quantum-Authentifizierung als mehrjährigen Übergang, nicht als einzelnes Update. Das Risiko liegt weniger darin, dass sofort ein neues Zertifikat ausgerollt werden müsste. Kritisch ist vielmehr, dass viele Unternehmen nicht vollständig wissen, welche Systeme Zertifikate ausstellen, speichern, prüfen oder verteilen. Genau dort entstehen später Kompatibilitätsprobleme, wenn Algorithmen, Zertifikatsgrößen oder Kettenlängen wechseln.
Für die tägliche IT-Arbeit heißt das: Nicht die Kryptografie selbst steht zuerst im Mittelpunkt, sondern die Betriebsfähigkeit. Ein Zertifikat kann technisch korrekt sein und trotzdem Probleme verursachen, wenn eine Appliance die Kette nicht lesen kann, eine Altanwendung größere Zertifikate ablehnt oder ein Prüfwerkzeug einen neuen Algorithmus nicht kennt.
Wo Abhängigkeiten in KMU häufig versteckt sind
Auch Unternehmen mit 10 bis 250 Arbeitsplätzen nutzen mehr Zertifikatslogik, als auf den ersten Blick sichtbar ist. Typische Stellen sind:
- öffentliche TLS-Zertifikate für Website, Kundenportal, VPN oder Remotezugriff,
- interne Zertifikate für WLAN, Gerätezertifikate, Druckdienste oder Applikationsserver,
- Sicherheits- und Netzwerkgeräte, die TLS-Verbindungen prüfen oder eigene Zertifikate verteilen,
- Fachanwendungen, die Zertifikate für Clientauthentifizierung, API-Zugriff oder Dienst-zu-Dienst-Kommunikation nutzen.
Ein Microsoft Security Assessment sollte diese Punkte nicht erst dann aufnehmen, wenn ein Austauschtermin feststeht. Microsoft empfiehlt ausdrücklich, zertifikatsabhängige Systeme zu inventarisieren, Vertrauensbeziehungen zu dokumentieren, Anbieter-Roadmaps zu prüfen und sichere Testumgebungen aufzubauen.
Welche Fristen und Einschränkungen Microsoft nennt
Der Microsoft-Beitrag vom 8. Oktober 2026 verweist auf das PQC TLS Pilot Program des Microsoft Trusted Root Program. Dieses Pilotprogramm wurde laut Microsoft am 27. August 2026 gestartet und nimmt bis Ende 2026 weitere berechtigte Zertifizierungsstellen in rollierenden Zulassungen auf. Es richtet sich aber nicht an den produktiven Webbetrieb: Die Pilotzertifikate sind nicht öffentlich vertrauenswürdig, nicht für Produktionsszenarien und nicht für öffentlich erreichbare Websites gedacht.
Für Tests mit ML-DSA-Zertifikaten nennt Microsoft außerdem konkrete Windows-Voraussetzungen. Unterstützte Testszenarien beginnen mit den Windows-11-Updates vom 28. Juli 2026: KB5101681 für Version 26H1 sowie KB5101684 für Version 25H2. Auf älteren oder nicht unterstützten Systemen können Prüfungen der Microsoft Certificate Trust List mit Fehlern wie NTE_BAD_ALGID scheitern.
Diese Daten sind keine Umstellungsfrist für KMU. Sie zeigen aber, ab wann Microsoft erste Testpfade im eigenen Vertrauensprogramm und auf bestimmten Windows-11-Ständen beschreibt. Wer Abhängigkeiten früh kennt, kann Anbieter gezielt fragen und muss später nicht unter Zeitdruck herausfinden, welche Komponente eine Zertifikatskette blockiert.
Was heute noch nicht getan werden sollte
Wichtig ist die Abgrenzung: Microsoft fordert keine sofortige Migration produktiver Zertifikate auf Post-Quantum-Algorithmen. Im Gegenteil, das Pilotprogramm ist ausdrücklich auf geschlossene Testumgebungen, kundenspezifische Anwendungen und Enterprise-Testbeds beschränkt. Unternehmen sollten deshalb keine öffentlichen Websites, produktiven VPNs oder Microsoft-365-Zugänge mit Pilotzertifikaten absichern. Sinnvoll ist stattdessen eine saubere Bestandsaufnahme, damit spätere Vorgaben nicht überraschend auf unbekannte Altlasten treffen.
Ebenso wenig sollten einzelne Testmeldungen als Kauf- oder Austauschsignal verstanden werden. Microsoft beschreibt eine begrenzte, experimentelle Unterstützung, keine allgemeine Produktionsfreigabe. Beschaffung, Austausch und Rollout bleiben deshalb Folgeentscheidungen nach einer technischen Prüfung, nicht der erste Schritt.
Konkrete nächste Schritte
Für die Microsoft-365-Beratung und technische Sicherheitsprüfung ergibt sich daraus ein überschaubarer Arbeitsplan:
- Zertifikatsquellen erfassen: öffentliche CA, interne CA, Geräte, Appliances, Cloud- und SaaS-Anbieter.
- Vertrauensketten dokumentieren: welche Systeme akzeptieren welche Root- oder Zwischenzertifikate?
- Langläufer markieren: Systeme mit langen Updatezyklen, ältere Windows-Versionen, Embedded-Geräte und Fachanwendungen.
- Anbieter befragen: ob Roadmaps, Testmöglichkeiten und Supportaussagen zu Post-Quantum-Zertifikaten vorliegen.
- Ein nicht produktives Testfenster planen, bevor Zertifikatsgrößen, Prüfpfade oder TLS-Inspektion im Alltag auffallen.
Offizielle Microsoft-Quellen
- Microsoft Security Blog: Post-quantum authentication
- Microsoft Trusted Root Program: PQC TLS Pilot Program Requirements
- Microsoft Trusted Root Program: PQC pilot root announcements
Wenn Sie wissen möchten, wo Zertifikate in Ihrer Microsoft-365- und Windows-Umgebung kritisch werden könnten, prüfen wir Inventar, Vertrauensketten und realistische Testschritte in einem Microsoft Security Assessment – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
