Microsoft-Zertifikatswechsel bei Windows Update: Was IT-Verantwortliche jetzt tun müssen

Lesezeit: ca. 8 Minuten | Zielgruppe: IT-Administratoren, CISOs, Geschäftsführer | Stand: Oktober 2026

Einleitung: Warum dieser Zertifikatswechsel Ihr Unternehmen betrifft

Microsoft steht vor einem planmäßigen, aber für viele Unternehmen unterschätzten Infrastrukturwechsel: Ab Mai 2027 laufen die aktuell gültigen Zertifikate für Windows Update ab. Neue Zertifikate werden per Update ausgerollt – klingt zunächst unspektakulär, hat jedoch für Unternehmen mit restriktiven Netzwerkkonfigurationen, isolierten Systemen oder strengen Change-Management-Prozessen erhebliche operative Konsequenzen.

Wer nicht rechtzeitig handelt, riskiert, dass Windows-Endpunkte und Server künftig keine Sicherheitsupdates mehr erhalten – ein Szenario, das nicht nur die IT-Sicherheit gefährdet, sondern auch regulatorische Konsequenzen nach sich ziehen kann. Denn unter der EU-Richtlinie NIS2, die in Deutschland durch die Novelle des BSI-Gesetzes (BSIG) umgesetzt wird, sind Unternehmen verpflichtet, technische Schutzmaßnahmen auf aktuellem Stand zu halten.

Dieser Artikel erklärt, was hinter dem Zertifikatswechsel steckt, welche Pflichten für deutsche Unternehmen relevant sind und – vor allem – was Sie jetzt konkret tun sollten.

Technischer Hintergrund: Was steckt hinter dem Windows-Update-Zertifikatswechsel?

Zertifikate als Vertrauensanker für Updates

Windows Update nutzt digitale Zertifikate, um sicherzustellen, dass heruntergeladene Softwarepakete tatsächlich von Microsoft stammen und nicht manipuliert wurden. Diese Zertifikate werden von einer Certificate Authority (CA) – in diesem Fall Microsoft selbst – ausgestellt und haben eine begrenzte Gültigkeitsdauer.

Das Ablaufdatum ist dabei kein Versehen, sondern gelebte Sicherheitspraxis: Begrenzte Laufzeiten minimieren das Missbrauchspotenzial im Fall einer Kompromittierung. Zertifikate mit langer Laufzeit wären ein lohnendes Angriffsziel für staatliche Akteure oder organisierte Cyberkriminelle.

Warum ist das diesmal komplexer?

Normalerweise verläuft ein solcher Zertifikatswechsel im Hintergrund, ohne dass Administratoren eingreifen müssen. Diesmal kann es jedoch zu Problemen kommen, wenn:

• Systeme seit längerer Zeit keine Updates erhalten haben und deshalb das neue Root-Zertifikat noch nicht kennen
• Air-Gapped-Systeme oder WSUS-Umgebungen eingesetzt werden, bei denen Updates manuell importiert werden müssen
• TLS-Inspection-Firewalls oder Proxy-Server den Update-Verkehr filtern und eigene Zertifikatsprüfungen vornehmen
• Gruppenrichtlinien oder Security-Policies das Hinzufügen neuer Root-Zertifikate blockieren
• Ältere Windows-Versionen (z. B. Windows Server 2012 R2 oder Windows 10 vor bestimmten Patchständen) noch in Verwendung sind

In solchen Fällen kann es passieren, dass Windows Update nach dem Zertifikatsablauf im Mai 2027 stillschweigend fehlschlägt – ohne eindeutige Fehlermeldung für Endnutzer. Systeme bleiben dann unbemerkt ungepatcht.

Was Microsoft konkret tut

Microsoft liefert die neuen Zertifikate als Teil regulärer Updates aus. Systeme, die regelmäßig gepatcht werden und standardmäßige Netzwerkkonfigurationen nutzen, sollten den Wechsel automatisch vollziehen. Für alle anderen besteht Handlungsbedarf.

NIS2-Relevanz und Pflichten für deutsche Unternehmen

Patch-Management als regulatorische Pflicht

Die NIS2-Richtlinie (EU 2022/2555), in Deutschland durch die BSIG-Novelle verankert, verpflichtet betroffene Unternehmen explizit zu technischen und organisatorischen Maßnahmen zum Schutz ihrer Netzwerk- und Informationssysteme. Dazu gehört nach Artikel 21 NIS2 ausdrücklich:

• Patch- und Schwachstellenmanagement (Art. 21 Abs. 2 lit. e)
• Sicherheit der Lieferkette, einschließlich der Zuverlässigkeit genutzter Softwareanbieter (Art. 21 Abs. 2 lit. d)
• Kontinuierliche Überwachung kritischer Systeme

Ein Szenario, in dem Windows-Systeme mangels funktionierender Update-Infrastruktur über Wochen ohne Sicherheitspatches betrieben werden, würde diese Anforderungen direkt verletzen.

Meldepflichten bei Sicherheitsvorfällen

Sollte es durch ausgefallene Updates zu einer Sicherheitslücke kommen, die aktiv ausgenutzt wird, greift die NIS2-Meldepflicht:

Zuständige Behörde für die meisten Branchen in Deutschland ist das Bundesamt für Sicherheit in der Informationstechnik (BSI). Das BSI hat bereits in der Vergangenheit auf ähnliche Zertifikatsprobleme hingewiesen – etwa beim Let's-Encrypt-Root-Ablauf 2021 – und empfiehlt proaktives Zertifikatsmonitoring als Mindeststandard.

Wer ist von NIS2 betroffen?

Betroffen sind sowohl wesentliche Einrichtungen (z. B. Energie, Gesundheit, Wasserversorgung, digitale Infrastruktur) als auch wichtige Einrichtungen (z. B. Maschinenbau, Chemie, Lebensmittel, Post und Kurierdienste) ab bestimmten Unternehmensgrößen (in der Regel ab 50 Mitarbeitenden oder 10 Mio. Euro Jahresumsatz). Auch Unternehmen, die nicht direkt unter NIS2 fallen, sollten die folgenden Maßnahmen aus eigenem Interesse umsetzen.

5 konkrete Schutzmaßnahmen für IT-Administratoren

1. Inventur aller Windows-Systeme nach Patchstand

Erstellen Sie zunächst eine vollständige Übersicht aller Windows-Endpunkte und Server in Ihrer Umgebung. Identifizieren Sie Systeme, die:

• Seit mehr als 60 Tagen kein Update erhalten haben
• Windows-Versionen nutzen, die End of Life erreicht haben oder sich dem EOL-Datum nähern
• Nicht in regulären WSUS- oder Intune-Richtlinien enthalten sind (z. B. OT-Systeme, Kiosk-PCs, Legacy-Anwendungsserver)

Tools wie Microsoft Endpoint Configuration Manager, Intune oder Open-Source-Lösungen wie OCSng helfen bei der Inventarisierung.

2. Root-Zertifikatsspeicher gezielt prüfen und aktualisieren

Überprüfen Sie auf repräsentativen Systemen, ob das neue Microsoft-Root-Zertifikat bereits vorhanden ist. Dies geht per PowerShell:

Get-ChildItem -Path Cert:\LocalMachine\Root | 
Where-Object { $_.Subject -like "*Microsoft*" } | 
Select-Object Subject, NotAfter, Thumbprint

Für isolierte Systeme ohne Internetzugang: Importieren Sie Root-Zertifikate manuell über Gruppenrichtlinien (GPO → Computer Configuration → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities).

3. WSUS- und Proxy-Konfigurationen auf Kompatibilität prüfen

Wenn Sie Windows Server Update Services (WSUS) einsetzen, stellen Sie sicher, dass:

• Der WSUS-Server selbst Zugang zu windowsupdate.microsoft.com und update.microsoft.com hat
• TLS-Inspection-Geräte (Next-Gen-Firewalls, Proxys) die Microsoft-Update-URLs auf einer Whitelist für Certificate Pinning führen
• Der WSUS-Server das neue Zertifikat synchronisiert, bevor es auf Clients ausgerollt wird

Sprechen Sie hierzu frühzeitig mit Ihrem Netzwerkteam und Firewall-Hersteller.

4. Monitoring und Alerting für Update-Fehler einrichten

Stille Update-Fehler sind das eigentliche Risiko. Richten Sie ein aktives Monitoring ein, das Sie alarmiert, wenn:

• Ein System über 14 Tage kein Update erfolgreich installiert hat
• Windows Update Fehler-Codes zurückgibt (insbesondere 0x80072F8F, 0x800B0109 oder zertifikatsbezogene Fehler)
• Das Windows Update Agent Log (C:\Windows\WindowsUpdate.log) auf Handshake-Fehler hinweist

SIEM-Systeme wie Microsoft Sentinel, Splunk oder Elastic SIEM können solche Logs zentral auswerten. Für kleinere Umgebungen genügen oft schon automatisierte PowerShell-Reports per E-Mail.

5. Change-Management-Prozess jetzt starten

Stellen Sie sicher, dass der Zertifikatswechsel als formaler Change in Ihrem IT-Service-Management-System (z. B. ServiceNow, Jira Service Management) erfasst ist. Definieren Sie:

• Verantwortlichkeiten: Wer ist zuständig für Client-Systeme, Server, OT-Netz?
• Testplan: Welche Systeme werden zuerst aktualisiert (Pilotgruppe)?
• Rollback-Prozedur: Was passiert, wenn der Update-Test fehlschlägt?
• Kommunikationsplan: Wie werden Fachabteilungen und Management informiert?

Beginnen Sie damit nicht erst im April 2027 – ein Vorlauf von mindestens drei bis vier Monaten ist realistisch.

Fazit: Routinevorgang mit Ausnahme-Potenzial

Der Microsoft-Zertifikatswechsel ist technisch gesehen ein Routinevorgang. Für Unternehmen mit modernen, gepatchten und standardkonformen Umgebungen wird er kaum wahrnehmbar sein. Doch die Realität in vielen deutschen Betrieben sieht anders aus: Legacy-Systeme, komplexe Netzwerktopologien und ressourcenknappe IT-Teams sind die Regel, nicht die Ausnahme.

Genau deshalb ist frühzeitiges Handeln keine Überreaktion, sondern professionelles IT-Management. Und unter NIS2 ist es schlicht Pflicht.

Empfehlung: Setzen Sie das Thema jetzt auf die Agenda Ihres nächsten IT-Security-Meetings – nicht in sechs Monaten.

Call-to-Action: NIS2-Compliance strukturiert angehen

Vorfälle wie dieser zeigen, wie viele Einzelmaßnahmen ein vollständiges NIS2-Compliance-Programm umfasst: Patch-Management, Zertifikatsüberwachung, Meldeprozesse, Lieferkettenrisiken. Der manuelle Überblick über all diese Anforderungen ist aufwändig und fehleranfällig.

Spezialisierte NIS2-Compliance-Software hilft IT-Verantwortlichen dabei, Anforderungen zu strukturieren, den Umsetzungsstand zu dokumentieren und Meldepflichten fristgerecht nachzukommen. Tools wie Perseus, Reguvis NIS2-Manager oder vergleichbare GRC-Plattformen bieten vorgefertigte Kontrollrahmen auf Basis der BSI-Grundschutz-Methodik und der NIS2-Anforderungen. Eine Investition, die sich spätestens beim nächsten BSI-Audit oder im Ernstfall eines Sicherheitsvorfalls bezahlt macht.

Quellen: Heise Security (12.10.2026), BSI-Grundschutz-Kompendium 2023, EU-Richtlinie 2022/2555 (NIS2), BSIG-Novelle 2024, Microsoft Security Update Guide