Windows 11: Microsoft schaltet ab Oktober automatisch eine Kernel-Schutzfunktion scharf

Ein Sicherheits-Feature, das seit Jahren existiert, aber auf vielen Windows-11-Rechnern nie eingeschaltet wurde, geht ab diesem Monat ohne Zutun der IT-Abteilung in Betrieb. Microsoft hat im Windows-Message-Center (öffnet in neuem Tab) angekündigt, dass Windows-Qualitätsupdates ab Oktober 2026 Memory Integrity auf geeigneten Geräten automatisch aktivieren – und, falls noch nicht geschehen, gleich die zugrunde liegende Virtualization-based Security (VBS) mit. Für Unternehmen mit eigener Geräteflotte heißt das: Ein Update kann plötzlich Treiber blockieren, die bisher anstandslos liefen.

Was Microsoft konkret ankündigt

Im Windows-Message-Center heißt es wörtlich, beginnend im Oktober 2026 würden Windows-Qualitätsupdates damit anfangen, „memory integrity protection on eligible devices" zu aktivieren, und – falls noch nicht aktiv – auch VBS einschalten, „helping make additional security capabilities available". Dieselbe Formulierung stammt aus dem Tech-Community-Beitrag von Peter Waxman (öffnet in neuem Tab), Group Program Manager bei Microsoft, der die Ankündigung am 1. September 2026 veröffentlicht hat.

Memory Integrity ist dabei kein neues Feature. Es handelt sich, wie Microsoft Learn (öffnet in neuem Tab) erläutert, um eine VBS-Funktion, die mithilfe des Windows-Hypervisors eine isolierte virtuelle Umgebung schafft und darin die Codeintegrität von Kernel-Mode-Treibern prüft – nur wer diese Prüfung besteht, darf auf Kernel-Ebene ausgeführt werden. Das Verfahren ist auch als Hypervisor-protected Code Integrity (HVCI) bekannt und existierte ursprünglich unter dem Namen Device Guard. Neu ist nicht die Technik, sondern dass sie jetzt auf Millionen Geräten automatisch greift, die bislang qualifiziert, aber nicht aktiviert waren.

Welche Geräte betroffen sind

Nach Recherche von Windows Latest (öffnet in neuem Tab) rollt die Änderung über das Oktober-Patchday-Update aus und betrifft Geräte, die folgende Mindestanforderungen erfüllen: einen Intel-Prozessor ab der 8. Generation oder einen AMD-Prozessor ab Zen 2, mindestens 8 GB RAM bei x64-Systemen, eine SSD ab 64 GB, aktivierte Virtualisierung im Firmware-Setup sowie Treiber, die bereits als kompatibel mit Memory Integrity bestätigt sind. Secured-Core-PCs – eine Zertifizierungsstufe, die Microsoft und Gerätehersteller vor allem für Business- und Enterprise-Hardware vergeben – laufen laut Windows Latest bereits heute mit aktivierter Funktion.

Wichtig für die Planung: Microsoft führt vor der Aktivierung laut eigener Ankündigung eine Readiness-Prüfung pro Gerät durch und berücksichtigt dabei Hardwarefähigkeiten, Kompatibilität, Performance-Faktoren und die Windows-11-Systemanforderungen. Geräte, auf denen Memory Integrity bereits bewusst deaktiviert wurde – per Gruppenrichtlinie, Intune oder manuellem Registry-Eintrag –, werden laut Windows Latest von der automatischen Aktivierung ausgenommen: Der Rollout ist als Opt-out-durch-bestehende-Richtlinie angelegt, nicht als erzwungenes Überschreiben.

Wo es wehtun kann: Treiberkompatibilität

Microsoft warnt in der eigenen Dokumentation selbst unmissverständlich: „Some applications and hardware device drivers may be incompatible with memory integrity. This incompatibility can cause devices or software to malfunction and in rare cases may result in a boot failure (blue screen)." Diese Inkompatibilitäten können laut Microsoft sowohl beim Aktivieren selbst als auch danach auftreten.

Für IT-Abteilungen mit älterer oder spezialisierter Hardware – Fertigungs-Peripherie, Dongle-basierte Lizenzierung, ältere Scanner- oder Kartenleser-Treiber – ist das keine theoretische Warnung. Windows protokolliert erkannte Konflikte laut Windows Latest in der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle > Microsoft > Windows > CodeIntegrity > Operational", markiert mit der Ereignis-ID 3087, sobald ein Treiber als inkompatibel eingestuft wird. Das ist der erste Ort, an dem Sie nachsehen sollten, wenn ein Gerät nach dem Oktober-Update ungewohntes Verhalten zeigt.

Flottenweit prüfen, statt Gerät für Gerät

Wer nicht jedes Gerät einzeln über die Windows-Security-Oberfläche kontrollieren will, kann den Status laut Microsoft Learn (öffnet in neuem Tab) auch programmatisch abfragen. Aus einer administrativen PowerShell-Sitzung liefert

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

sowohl die auf dem Gerät verfügbaren Sicherheitseigenschaften als auch die tatsächlich aktiven – darunter Secure-Boot-Unterstützung, DMA-Schutz und die für Memory Integrity relevante Mode-Based-Execution-Control-Fähigkeit der CPU. Dieser Befehl lässt sich über jedes gängige Remote-Management-Werkzeug auf eine gesamte Geräteflotte ausrollen und liefert damit vor dem Oktober-Patchday eine Übersicht, welche Maschinen überhaupt zur automatischen Aktivierung infrage kommen und welche aufgrund fehlender Hardwarevoraussetzungen ohnehin außen vor bleiben.

Die Kehrseite: spürbare Performance-Einbußen auf älterer Hardware

The Verge (öffnet in neuem Tab) ordnet ein, warum Microsoft diese Funktion nicht pauschal seit Jahren aktiviert hat: Memory Integrity kann die Performance spürbar beeinträchtigen, insbesondere bei älteren Prozessoren ohne die passenden Virtualisierungs-Erweiterungen. Auf modernerer CPU-Generation falle der Effekt laut dem Bericht geringer aus. Für Büroarbeitsplätze mit Textverarbeitung und Browser dürfte der Unterschied kaum auffallen; für rechenintensive Anwendungen auf älteren Maschinen lohnt sich ein Blick vorab.

Was IT-Verantwortliche jetzt konkret prüfen sollten

• Aktuellen Status feststellen. Unter Windows Security > Gerätesicherheit > Kernisolierung zeigt der Schalter „Speicherintegrität" direkt an, ob die Funktion auf einem Gerät aktiv ist oder nicht.
• Zentrale Steuerung vorbereiten, statt reaktiv zu patchen. Laut Microsoft Learn lässt sich Memory Integrity über Intune – im Settings Catalog unter „Virtualization Based Technology" > „Hypervisor Enforced Code Integrity" – ebenso verwalten wie per Gruppenrichtlinie oder direkt per Registry-Schlüssel unter HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity. Wer die Funktion in der eigenen Flotte kontrolliert ausrollen will, kann das vorab über diese Kanäle steuern, statt auf das automatische Windows-Update-Verhalten zu warten.
• Eine Testgruppe vorschalten, bevor das Oktober-Update flächendeckend verteilt wird – insbesondere auf Geräten mit Fachanwendungen, Spezialtreibern oder älterer Peripherie, die nicht zur Standard-Office-Ausstattung gehört.
• Nach der Aktivierung das CodeIntegrity-Ereignisprotokoll kontrollieren, wenn ein Gerät nach dem Update Auffälligkeiten zeigt – Ereignis-ID 3087 benennt den konkret blockierten Treiber und spart damit die Fehlersuche per Ausschlussverfahren.
• UEFI-Lock-Option bewusst wählen. Wer Memory Integrity per Gruppenrichtlinie „mit UEFI-Lock" aktiviert, verhindert laut Microsoft Learn, dass die Funktion remote oder per Richtlinien-Update wieder deaktiviert werden kann – ein Rollback ist dann nur noch über den Zugriff auf das UEFI-BIOS-Menü möglich. Für Flotten, bei denen ein schneller Workaround bei Kompatibilitätsproblemen wichtiger ist als maximale Manipulationssicherheit, ist die Variante ohne UEFI-Lock die praktikablere Wahl.

Ein Muster, das sich wiederholt

Der Vorgang reiht sich in ein Muster ein, das in den vergangenen Monaten bei Windows-Updates im Unternehmensumfeld mehrfach auffiel: Microsoft verschiebt sicherheitsrelevante Standardeinstellungen zunehmend in Richtung „secure by default", ohne dass Administratoren aktiv etwas konfigurieren müssen – mit dem Kompromiss, dass genau diese Automatik in heterogenen Geräteflotten unvorhersehbare Nebenwirkungen erzeugen kann. Erst im September 2026 hatte ein anderes Sicherheitsupdate – KB5124008 – in reinen On-Premises-Active-Directory-Umgebungen dafür gesorgt, dass Geräte ihre Vertrauensbeziehung zur Domäne verloren und Nutzer sich nicht mehr anmelden konnten, weil eine neue Isolationsfunktion in Umgebungen griff, für die sie laut Microsoft nicht vorgesehen war. Beide Fälle haben dieselbe Grundstruktur: Eine Sicherheitsfunktion wird über ein reguläres Update automatisch schärfer gestellt, und wer seine Umgebung vorher nicht kennt, erfährt erst durch den Ausfall davon.

Memory Integrity selbst ist dabei keine neue oder experimentelle Funktion; vielmehr schließt Microsoft hier eine Lücke zwischen Geräten, die die Voraussetzungen seit Jahren erfüllen, und solchen, bei denen die Funktion durch ein Upgrade statt einer Neuinstallation nie automatisch eingeschaltet wurde. Im eigenen Ankündigungstext beschreibt Microsoft die Maßnahme zudem als Grundlage für künftige Sicherheitsfunktionen, die auf dieselbe isolierte VBS-Umgebung aufsetzen – darunter sogenannte Hotpatch-Updates, bei denen Sicherheitskorrekturen ohne Neustart eingespielt werden sollen. Wer Memory Integrity jetzt dauerhaft deaktiviert, verschiebt damit möglicherweise auch den eigenen Zugang zu solchen künftigen Erleichterungen im Patch-Management.

Was das für Ihre IT-Planung bedeutet

Für Unternehmen mit einer eigenen, nicht vollständig durch Intune oder Gruppenrichtlinien gesteuerten Geräteflotte ist die sinnvollste Reaktion nicht, die Funktion präventiv zu deaktivieren, sondern vor dem Rollout zu wissen, welche Geräte betroffen sein könnten und welche Treiber dort im Einsatz sind. Das betrifft insbesondere Betriebe mit Spezialsoftware oder Fachanwendungen, deren Treiber nicht im üblichen Update-Rhythmus großer Hersteller gepflegt werden – etwa in Fertigung, Labor oder im Gesundheitswesen, wo Gerätesteuerungen oft über Jahre unverändert laufen. Eine kurze Bestandsaufnahme der eigenen Hardware- und Treiberlandschaft, kombiniert mit einer Testgruppe vor dem flächendeckenden Rollout, kostet deutlich weniger Zeit als eine nachträgliche Fehlersuche über mehrere Standorte hinweg.

Wer die eigene IT-Infrastruktur durch uns betreuen lässt oder eine Einschätzung braucht, welche Systeme in der eigenen Flotte beim Oktober-Update genauer zu prüfen sind, kann uns gerne unverbindlich ansprechen.