Patchday September 2026: Warum Sysadmins jetzt jede Plattform-Vertrauenskette neu prüfen müssen

Am 9. September 2026 flatterten bei mir zwischen halb neun und zehn Uhr morgens sieben Kundenanrufe rein. Alle die gleiche Frage: “Müssen wir das heute noch einspielen?” Die Antwort war ja. Microsoft hat mit dem September-Patchday 966 Schwachstellen geschlossen, zwei davon aktiv ausgenutzte Zero-Days. Das ist kein Rekord, den man mal eben mit der Wochenend-Wartung abarbeitet.

Was mich an diesem Patchday aber wirklich beschäftigt hat, war nicht die schiere Zahl. Es war die Frage, die danach bei mir hängen blieb: Wenn wir intern so eine Disziplin an den Tag legen, warum hört diese Disziplin an der Firewall auf?

Der 974-CVE-Patchday und was er über unsere Prüf-Routine verrät

Zwei aktiv ausgenutzte Zero-Days. Über 110 kritische Lücken. Windows, Exchange, SharePoint, SQL Server, alles dabei. CSO Online listet den vollen Umfang der September-2026-Welle und macht klar: Das war kein normaler Dienstag.

Bei uns im Haus läuft nach jedem Patchday dasselbe Ritual ab. Erst die Zertifikatsketten prüfen, weil ein fehlerhaft verlängertes Zertifikat nach einem CA-Neustart genauso viel Schaden anrichten kann wie die eigentliche Lücke. Dann die Lizenzstatus der betroffenen Systeme durchgehen, weil ungepatchte Legacy-Instanzen sich gerne genau dort verstecken, wo niemand mehr hinschaut. Und am Ende die Log-Integrität, um sicherzugehen, dass der Patch nicht nur installiert wurde, sondern auch tatsächlich greift.

Drei Schritte. Keine Abkürzung. Genau diese Routine ist der Punkt, um den es hier eigentlich geht.

Denn dieselbe Sorgfalt, die wir bei jedem internen System anwenden, wenden die wenigsten von uns bei externen Anbietern an, denen wir trotzdem Zugangsdaten oder Zahlungsdaten anvertrauen. Ein neuer Cloud-Dienst, ein Zahlungs-Gateway, sogar Plattformen außerhalb der klassischen IT-Bubble, etwa Online-Gaming-Anbieter mit eigener Zahlungsabwicklung. Wer dort ein Konto eröffnet, prüft selten die Lizenzierung oder die Herkunft der Infrastruktur mit derselben Genauigkeit wie den eigenen Patch-Status. Genau an dieser Stelle lohnt es sich, jetzt informieren zu heißen, bevor man dort Daten hinterlegt, für die man später keine Kontrolle mehr hat.

Glücksspiel bleibt Risiko. Wer sich dafür entscheidet, sollte nur mit Beträgen spielen, die er sich leisten kann zu verlieren, und im Zweifel Hilfe bei der BZgA oder unter www.check-dein-spiel.de suchen.

Warum Vertrauensketten größer sind als die eigene Domäne

Hier wird es interessant. Eine Vertrauenskette endet nicht am Domain Controller. Sie zieht sich durch jede API, jeden Drittanbieter, jedes Zertifikat, das irgendwo in der Lieferkette ausgestellt wurde.

Group-IB dokumentiert in einer aktuellen Analyse mehrere Gruppen, die gezielt Supply-Chain-Vertrauen ausnutzen, nicht die Zielsysteme direkt. Der Angriff läuft über den Umweg, über den Dienstleister, der selbst als vertrauenswürdig gilt. Das ist genau das Muster, das viele Admins bei der eigenen Infrastruktur inzwischen verinnerlicht haben. Bei externen Plattformen wird es aber oft komplett ignoriert.

Ein Beispiel aus der Praxis: Ein Kunde von mir hatte im August eine kritische RCE-Lücke in AD CS zu stopfen, CVSS 8.8, aus der Ferne ausnutzbar, ohne Interaktion. Wir haben das binnen 36 Stunden gepatcht. Zwei Wochen später hat derselbe Kunde einen neuen SaaS-Vertrag unterschrieben, ohne auch nur nach dem Sicherheitszertifikat des Anbieters zu fragen. Diese Diskrepanz sehe ich ständig. Intern wird jedes Detail seziert. Extern reicht ein Logo und ein SSL-Schloss im Browser.

Das ist keine böswillige Nachlässigkeit. Es ist schlicht, dass wir gelernt haben, unsere eigene Umgebung zu verteidigen, aber nie systematisch gelernt haben, fremde Umgebungen zu bewerten, bevor wir ihnen etwas anvertrauen.

Was eine echte Prüfroutine für Drittanbieter enthalten muss

Wenn ich mit Kunden über neue externe Dienste spreche, gebe ich mittlerweile eine kurze Checkliste mit, die sich fast eins zu eins an unserer internen Patchday-Routine orientiert:

• Wer stellt das Zertifikat aus, und läuft die Kette bis zu einer bekannten Root-CA zurück?
• Gibt es eine nachvollziehbare Lizenzierung oder Aufsicht, und lässt sich diese unabhängig verifizieren?
• Wie transparent kommuniziert der Anbieter über eigene Sicherheitsvorfälle?
• Existiert ein öffentlich einsehbares Advisory oder ein Ansprechpartner für Schwachstellenmeldungen?

Das dauert fünf Minuten. Es hat aber schon mehr als einmal verhindert, dass ein Kunde einen Vertrag mit einem Anbieter unterschreibt, dessen Infrastruktur seit Monaten kein Update mehr gesehen hat.

Interessant ist auch der Blick auf regulatorische Fälle. Bußgeldentscheidungen wie das gegen notebooksbilliger.de zeigen, dass Aufsichtsbehörden zunehmend genauer hinschauen, wie Plattformen mit Daten umgehen, unabhängig von der Branche. Wer diese Fälle verfolgt, merkt schnell, dass Datenschutzverstöße selten aus einem einzigen großen Fehler entstehen. Sie summieren sich aus vielen kleinen, ungeprüften Vertrauensentscheidungen.

Die Verbindung zwischen Secure Boot, Cloud PKI und dem täglichen Rauschen

Dieses Jahr allein hat gleich mehrere große Vertrauensverschiebungen gebracht. Die Secure-Boot-Zertifikatstransition läuft seit Juni, die alten 2011er-Zertifikate werden schrittweise durch die 2023er-Generation ersetzt. Parallel dazu ist Microsoft Cloud PKI seit diesem Jahr in vielen E5-Tenants automatisch aktiv, ohne dass Admins das bewusst eingeschaltet hätten.

Beide Themen haben etwas gemeinsam: Sie verschieben die Frage “wem vertraue ich” von einer einmaligen Entscheidung zu einem laufenden Prozess. Man kann nicht mehr sagen “das haben wir 2020 geprüft und ist gut”. Man muss regelmäßig nachschauen, wer eigentlich gerade die Schlüssel in der Hand hält.

Genau dieses Denken fehlt komplett, sobald wir den Rahmen der eigenen Organisation verlassen. Bei einem neuen Cloud-Vertrag schaut kaum jemand nach, ob der Anbieter zwischenzeitlich die Infrastruktur gewechselt hat oder ob die Zertifikatskette noch dieselbe ist wie beim Onboarding vor zwei Jahren.

Praktische Konsequenz für den Alltag

Meine Empfehlung nach diesem Patchday ist simpel, auch wenn sie unbequem klingt: Jede Plattform, der eine Zugangsdaten- oder Zahlungsbeziehung anvertraut wird, verdient dieselbe Prüfroutine wie ein interner Server nach einem kritischen Patch. Zertifikatskette, Herkunft, Lizenzstatus, Reaktionszeit bei Vorfällen.

Wer sich fragt, wo man anfangen soll: Fangen Sie mit den Diensten an, die am meisten Vertrauen genießen, obwohl sie am wenigsten geprüft wurden. Das ist erfahrungsgemäß nicht die neue Fachabteilungs-Software, sondern genau die Dienste, die “schon immer so liefen”.

Wer sich näher mit den aktuellen Kryptographie-Anforderungen für Windows-Umgebungen beschäftigen will, findet dazu mehr in der aktualisierten Kryptographie-Richtlinie. Und wer noch nicht sauber dokumentiert hat, wie die eigene CA-Infrastruktur aktuell aussieht, sollte das vor dem nächsten Patchday nachholen, nicht danach.

Häufige Fragen zum September-Patchday 2026

Wie viele Schwachstellen wurden im September-2026-Patchday geschlossen? Microsoft hat 966 CVEs adressiert, davon zwei aktiv ausgenutzte Zero-Days und über 110 als kritisch eingestufte Lücken. Betroffen waren unter anderem Windows, Exchange, SharePoint und SQL Server.

Reicht es, nur die als kritisch markierten Lücken sofort zu patchen? Nein. Kritisch eingestufte CVEs verdienen Priorität, aber aktiv ausgenutzte Zero-Days mit niedrigerer CVSS-Bewertung sind oft gefährlicher im Alltag. Priorisierung sollte sich an Exploitability und Reichweite orientieren, nicht nur am Score.

Was hat ein Patchday mit der Prüfung externer Anbieter zu tun? Beides läuft auf dieselbe Frage hinaus: Wem vertraue ich meine Zugangsdaten an, und wie aktuell ist deren Sicherheitslage wirklich? Die interne Prüfroutine nach einem Patchday lässt sich eins zu eins auf externe Plattformen übertragen.

Wie oft sollte man Zertifikatsketten von Drittanbietern neu prüfen? Mindestens einmal jährlich, besser bei jedem größeren Sicherheitsvorfall in der Branche des Anbieters. Zertifikate laufen ab, CAs wechseln, und Infrastrukturen werden migriert, oft ohne dass Kunden aktiv informiert werden.

Was tun, wenn ein Anbieter keine transparente Sicherheitskommunikation bietet? Das ist ein Warnsignal, kein Detail. Anbieter ohne öffentliches Advisory oder erreichbaren Sicherheitskontakt sollten kritisch hinterfragt werden, bevor man ihnen Zugangs- oder Zahlungsdaten anvertraut.

Der nächste Patchday kommt bestimmt, wahrscheinlich schon im Oktober mit ähnlichem Umfang. Die eigentliche Hausaufgabe liegt aber nicht im nächsten Patch-Zyklus, sondern darin, endlich dieselbe Prüf-Disziplin auf jede Plattform anzuwenden, der man aktuell blind vertraut.