Windows 11 26H2: Wie Microsoft Windows zur Plattform umbaut

Windows 11 26H2 ist da – aber was wurde eigentlich aktualisiert?

Ende September 2026 hat Microsoft Windows 11 Version 26H2 offiziell freigegeben. Wenige Tage später stand das Update auch auf meinen privaten Windows-11-Systemen bereit. Also folgte das inzwischen vertraute Prozedere: Update anstoßen, Installation abwarten, Rechner neu starten – fertig. Und dann? Der Desktop erscheint. Die Anwendungen sind noch da, wo sie vorher waren. Die gewohnte Arbeitsumgebung meldet sich zurück. Selbst der eigentliche Updateprozess fällt für einen Wechsel auf eine neue Windows-Version erstaunlich unspektakulär aus.

Natürlich gibt es Neuerungen: Windows 11 26H2 entwickelt unter anderem Sicherheit, Wiederherstellung, Hardwareunterstützung und Benutzeroberfläche weiter. Microsoft integriert Sysmon direkt in Windows, führt neue Sicherheitsmechanismen wie Administrator Protection ein und verändert zahlreiche Details an Explorer, Startmenü, Suche und Taskleiste. Die offizielle Übersicht der Neuerungen fällt entsprechend umfangreich aus. Trotzdem wäre es zu kurz gegriffen, Windows 11 26H2 lediglich anhand dieser Funktionen zu betrachten. Denn die vielleicht interessanteste Veränderung steckt nicht in einem neuen Menü, einer zusätzlichen Sicherheitsfunktion oder einer überarbeiteten Oberfläche. Sie zeigt sich bereits darin, wie 26H2 überhaupt auf den Rechner gelangt.

Von 25H2 zu 26H2 – per Schalter

Wer von Windows 11 25H2 auf 26H2 wechselt, installiert technisch betrachtet kein vollständig neues Betriebssystem. Microsoft verwendet für Windows 11 24H2, 25H2 und 26H2 eine gemeinsame Servicing-Basis. Viele der für 26H2 notwendigen Komponenten gelangen deshalb bereits mit den regulären kumulativen Updates auf bestehende Systeme. Dort können neue Funktionen zunächst vorhanden sein, ohne bereits vollständig aktiviert zu werden. Das eigentliche Upgrade übernimmt anschließend ein sogenanntes Enablement Package. Es aktiviert den neuen Funktionsstand und macht aus dem vorhandenen Windows schließlich Windows 11 26H2.

Das verändert die Perspektive auf ein Feature Update erheblich. Frühere Windows-Versionen waren stärker mit der Vorstellung eines klaren technischen Übergangs verbunden: Eine neue Version brachte neue Systemdateien, neue Funktionen und oftmals einen entsprechend umfangreichen Upgradeprozess mit. Bei Windows 11 verschwimmen diese Grenzen zunehmend. Das Betriebssystem entwickelt sich längst weiter, bevor die Versionsnummer wechselt.

Die Versionsnummer erzählt nur noch einen Teil der Geschichte

Diese Entwicklung kommt nicht überraschend. Bereits in den vergangenen Jahren hat Microsoft die Grenzen klassischer Windows-Versionen zunehmend aufgeweicht. Funktionen erscheinen über monatliche Updates, werden schrittweise aktiviert oder erreichen unterschiedliche Geräte zu unterschiedlichen Zeitpunkten. Auch die Versionsbezeichnungen selbst erzählen inzwischen unterschiedliche Geschichten.

Windows 11 26H1 habe ich in diesem Zusammenhang bereits als Beispiel für diesen Wandel betrachtet. Das Release richtet sich nicht als klassisches Feature Update an die bestehende Gerätebasis, sondern unterstützt insbesondere eine neue Generation von Hardwareplattformen. Im Beitrag Windows 11 26H1 im Überblick: Architekturwandel, KI-Hardware und die Zukunft von Windows habe ich deshalb bewusst zwischen Plattform- und Feature Release unterschieden.

26H2 ergänzt diese Entwicklung nun aus einer anderen Richtung. Hier geht es wieder um die breite installierte Basis von Windows 11. Doch auch dieses Release zeigt, dass die klassische Vorstellung von einer Windows-Version zunehmend an ihre Grenzen stößt. 26H2 ist deshalb nicht nur ein weiteres Windows-Update. Es ist ein gutes Beispiel dafür, wie grundlegend Microsoft die Weiterentwicklung von Windows verändert hat.

Mehr als eine What's-New-Liste

Genau an dieser Stelle setzt dieser Beitrag an. Natürlich werden wir uns ansehen, welche Funktionen Windows 11 26H2 mitbringt. Administrator Protection, Sysmon, neue Recovery-Funktionen und Änderungen an der Benutzeroberfläche verdienen eine genauere Betrachtung. Microsoft dokumentiert die Neuerungen und den aktuellen Zustand des Releases ausführlich in seiner What's-New-Dokumentation und im Windows Release Health Dashboard.

Die interessanteren Fragen liegen jedoch eine Ebene tiefer: Warum benötigt Microsoft überhaupt noch jährliche Windows-Versionen, wenn neue Funktionen kontinuierlich ausgeliefert werden? Welche Rolle spielen Versionsnummern künftig für Administration, Lifecycle und Support? Und was bedeutet diese Entwicklung für Unternehmen, die Windows bereitstellen, absichern und verwalten müssen? Schließlich führt 26H2 zu einer noch grundsätzlicheren Frage: Was ist Windows im Jahr 2026 eigentlich noch? Ein klassisches Desktop-Betriebssystem? Eine kontinuierlich weiterentwickelte Plattform? Die lokale Komponente eines wesentlich größeren Cloud-Ökosystems? Oder zunehmend eine Kombination aus all diesen Ebenen?

Um diese Fragen zu beantworten, reicht der Blick auf die sichtbaren Neuerungen von 26H2 nicht aus. Zunächst müssen wir verstehen, warum Microsoft im Jahr 2026 überhaupt zwei unterschiedliche Windows-11-Versionen mit den Bezeichnungen 26H1 und 26H2 benötigt – und warum diese beiden Releases trotz ihrer scheinbaren Nähe vollkommen unterschiedliche Aufgaben erfüllen.

26H1 und 26H2: Gleiche Jahreszahl, unterschiedliche Aufgaben

Wer die Versionsbezeichnungen von Windows aus den vergangenen Jahren gewohnt ist, könnte zunächst eine einfache Abfolge vermuten: Auf Windows 11 25H2 folgt 26H1 und anschließend 26H2. Schließlich lassen sich die Bezeichnungen intuitiv als Releases des ersten und zweiten Halbjahres 2026 lesen.

Technisch führt diese Interpretation jedoch in die falsche Richtung: Windows 11 26H1 und 26H2 tragen zwar dieselbe Jahreszahl im Namen, erfüllen aber unterschiedliche Aufgaben. Mehr noch: Sie basieren nicht einmal auf demselben Windows-Core. Während 26H1 gezielt für bestimmte neue Hardwareplattformen entwickelt wurde, führt 26H2 die reguläre Entwicklungslinie von Windows 11 24H2 und 25H2 fort. Damit liefert Microsoft ein interessantes Beispiel dafür, wie wenig eine Windows-Versionsnummer inzwischen allein über die technische Abstammung eines Systems aussagt.

26H1: Ein Windows für neue Hardware

Microsoft bezeichnet Windows 11 26H1 ausdrücklich nicht als Feature Update für Windows 11 25H2. Die Version wurde stattdessen entwickelt, um neue Hardware und insbesondere neue Prozessorgenerationen zu unterstützen. Zu den ersten Plattformen gehören Geräte mit Qualcomms Snapdragon-X2-Prozessoren. Deshalb wird 26H1 auch nicht als reguläres In-Place-Upgrade für bestehende Windows-11-Systeme angeboten. Es kommt auf ausgewählten neuen Geräten vorinstalliert zum Einsatz. Für Unternehmen bedeutet dies: Eine vorhandene Flotte mit Windows 11 24H2 oder 25H2 muss nicht zunächst auf 26H1 aktualisiert werden, um später den regulären Windows-Entwicklungspfad fortzusetzen. Microsoft hat 26H1 bewusst auf die dafür vorgesehenen Hardwareplattformen begrenzt.

Damit verändert sich die Bedeutung einer Versionsnummer. 26H1 markiert weniger einen neuen Funktionsstand für alle Windows-PCs als vielmehr einen eigenständigen Plattformzweig für neue Hardware. Genau diese Entwicklung hatte ich bereits im Beitrag Windows 11 26H1 im Überblick: Architekturwandel, KI-Hardware und die Zukunft von Windows betrachtet. 26H2 macht nun sichtbar, welche Konsequenzen diese Aufteilung für die weitere Windows-Entwicklung hat.

26H2: Der reguläre Entwicklungspfad geht weiter

Windows 11 26H2 übernimmt eine andere Aufgabe als 26H1. Microsoft bezeichnet die Version als das nächste jährliche Feature Update für Windows 11. Dabei setzt 26H2 auf derselben Servicing-Grundlage wie 24H2 und 25H2 auf. Auf entsprechend vorbereiteten Systemen genügt deshalb ein vergleichsweise kleines Enablement Package, um den neuen Versionsstand zu aktivieren.

Damit ergibt sich eine zunächst ungewöhnliche Situation. Ein PC mit Windows 11 25H2 kann regulär auf 26H2 wechseln. Ein Gerät mit dem numerisch scheinbar dazwischenliegenden Windows 11 26H1 kann diesen direkten Upgradepfad dagegen nicht nutzen. Der Grund liegt nicht in der Versionsnummer, sondern in der technischen Grundlage: 26H1 gehört nicht zur gemeinsamen Entwicklungslinie von 24H2, 25H2 und 26H2, sondern basiert auf einem anderen Windows-Core.

Die Abbildung macht diesen Unterschied sichtbar. Auf der regulären Entwicklungslinie bilden 24H2, 25H2 und 26H2 eine gemeinsame Servicing-Familie. Quality Updates können Funktionen und Komponenten bereits vorbereiten, bevor ein Enablement Package den nächsten Versionsstand aktiviert. 26H1 verläuft dagegen auf einem eigenen Architekturzweig. Für diese Geräte ist nicht der direkte Wechsel auf 26H2 vorgesehen, sondern ein späterer Upgradepfad auf ein zukünftiges Windows-Release.

Damit verliert die vermeintlich eindeutige Reihenfolge der Versionsnummern einen Teil ihrer Aussagekraft. 25H2 kann technisch näher an 26H2 liegen als das numerisch dazwischenliegende 26H1. Die Versionsnummer sagt deshalb nicht mehr automatisch aus, welches Windows-Release technisch auf welchem anderen Release aufbaut.

Wenn die Versionsnummer zur Plattforminformation wird

Für Administrator:innen ist diese Unterscheidung mehr als eine akademische Besonderheit. Klassische Versionslogik lässt sich nicht mehr ohne Weiteres auf Windows 11 übertragen. Bislang konnte eine Versionsnummer mehrere Informationen gleichzeitig transportieren: Sie bezeichnete einen Entwicklungsstand, einen Funktionsumfang, einen Supportzeitraum und häufig auch eine bestimmte technische Basis. Mit 26H1 und 26H2 beginnen sich diese Bedeutungen voneinander zu lösen. 26H1 beschreibt vor allem einen hardwarebezogenen Plattformzweig. 26H2 beschreibt dagegen den nächsten regulären Feature-, Servicing- und Lifecycle-Stand der bestehenden Windows-11-Linie.

Das hat praktische Konsequenzen. Bei Inventarisierung, Deployment und Lifecycle-Planung genügt es zunehmend nicht mehr, lediglich zu prüfen, welche vermeintlich neueste Windows-Version installiert ist. Hardwareplattform, Windows-Core, unterstützter Upgradepfad und jeweiliger Lifecycle müssen gemeinsam betrachtet werden. Für größere Umgebungen wird damit die Frage wichtiger, welche Windows-Linie zu welchem Gerät gehört, statt ausschließlich nach der höchsten Versionsnummer zu suchen.

Zwei Releases als Ausdruck einer größeren Veränderung

26H1 und 26H2 lassen sich deshalb als zwei Seiten derselben Entwicklung verstehen. Auf der einen Seite muss Windows neue Hardwarearchitekturen unterstützen. Gerade moderne KI-PCs verbinden CPU, GPU, NPU, neue Sicherheitsfunktionen und herstellerspezifische Plattformtechnologien enger miteinander. Microsoft benötigt dafür die Möglichkeit, den technischen Unterbau von Windows weiterzuentwickeln, ohne zwangsläufig die gesamte bestehende Gerätebasis auf diesen neuen Core zu migrieren.

Auf der anderen Seite erwartet das bestehende Windows-Ökosystem Kontinuität. Unternehmen verwalten Millionen vorhandener Geräte, Anwendungen müssen kompatibel bleiben und Administrator:innen benötigen planbare Wartungs- und Supportzeiträume. Genau hier setzt 26H2 die bestehende Linie fort.

26H1 steht damit exemplarisch für Plattformentwicklung, während 26H2 stärker für Kontinuität innerhalb der bestehenden Plattform steht. Diese Trennung könnte für Windows langfristig wichtiger werden als die klassische Vorstellung, dass jedes neue Release zwangsläufig das vorherige ablösen muss. Schon heute zeigt sich: Windows kann sich technisch in unterschiedliche Richtungen entwickeln und für Benutzer:innen dennoch als gemeinsame Windows-11-Plattform erscheinen.

Damit stellt sich allerdings die nächste Frage: Wie eng sind 24H2, 25H2 und 26H2 technisch tatsächlich miteinander verbunden? Die Antwort führt direkt unter die Oberfläche des Feature Updates – zum gemeinsamen Servicing-Unterbau von Windows 11.

Unter der Haube: Warum 24H2, 25H2 und 26H2 zusammengehören

Die Bezeichnungen Windows 11 24H2, 25H2 und 26H2 vermitteln zunächst den Eindruck dreier aufeinanderfolgender Betriebssystemversionen. Technisch liegen diese Releases jedoch wesentlich enger beieinander. Microsoft spricht von einem gemeinsamen Kernbetriebssystem mit identischen Systemdateien. 24H2, 25H2 und 26H2 verwenden außerdem denselben Servicing-Zweig. Dadurch kann Microsoft Änderungen über die regulären monatlichen Updates gleichzeitig in die gemeinsame Plattform einbringen. Ein Rechner muss also nicht erst auf 26H2 aktualisiert werden, damit sämtliche dafür benötigten Komponenten auf dem System vorhanden sind.

Das erklärt auch die persönliche Erfahrung beim Wechsel von 25H2 auf 26H2: Der eigentliche Versionswechsel kann erstaunlich schnell erfolgen, weil ein wesentlicher Teil der technischen Vorbereitung bereits vorher stattgefunden hat. Um dieses Modell zu verstehen, lohnt sich deshalb eine Trennung zwischen drei Dingen, die bei klassischen Betriebssystem-Upgrades enger miteinander verbunden waren: Auslieferung, Aktivierung und Versionswechsel.

Ein gemeinsamer Core statt drei getrennter Betriebssysteme

Microsoft beschreibt die technische Beziehung zwischen 24H2, 25H2 und 26H2 bemerkenswert deutlich: Die Versionen verwenden ein gemeinsames Kernbetriebssystem und einen identischen Satz von Systemdateien. Das bedeutet nicht, dass auf jedem Gerät zu jedem Zeitpunkt exakt derselbe Funktionsumfang verfügbar ist. Vielmehr schafft Microsoft eine gemeinsame technische Basis, auf der unterschiedliche Windows-Versionen betrieben und gewartet werden können.

Ein gutes Indiz liefern die kumulativen Updates selbst. Das Preview Update KB5124010 vom September 2026 gilt beispielsweise gleichzeitig für Windows 11 24H2, 25H2 und 26H2. Je nach Version entstehen dabei unterschiedliche Buildnummern, obwohl Microsoft die zugrunde liegenden Qualitätsverbesserungen gemeinsam ausliefert. Für Administrator:innen verändert das die Perspektive auf eine Windows-Version. Die sichtbare Versionsbezeichnung ist nicht mehr zwangsläufig gleichbedeutend mit einem vollständig separaten Bestand an Betriebssystemdateien. Unterhalb der Versionsgrenzen existiert zunehmend eine gemeinsam gewartete Windows-Plattform.

Wenn eine neue Funktion schon auf dem Rechner liegt

Besonders interessant wird dieses Modell bei neuen Funktionen. Microsoft kann Bestandteile von 26H2 bereits mit monatlichen Quality Updates an Rechner mit 24H2 oder 25H2 verteilen. Dort befinden sie sich zunächst in einem inaktiven Zustand. Microsoft verwendet dafür selbst die Begriffe inactive und dormant – also inaktiv beziehungsweise ruhend: Der Programmcode ist bereits auf dem System vorhanden, wird aber noch nicht ausgeführt oder für Benutzer:innen bereitgestellt.

Damit werden Auslieferung und Nutzung zeitlich voneinander getrennt. Ein Rechner kann technisch bereits Komponenten einer kommenden Windows-Version besitzen, ohne dass diese für Benutzer:innen verfügbar sind. Erst zu einem späteren Zeitpunkt aktiviert Microsoft die vorgesehenen Funktionen. Das ist ein erheblicher Unterschied zum klassischen Bild eines Feature Updates. Früher verband sich damit vor allem die Vorstellung, dass neue Funktionen mit dem Upgrade auf den Rechner gelangen. Im heutigen Servicing-Modell können sie dagegen bereits vorher vorhanden sein. Das Feature Update transportiert damit nicht mehr zwangsläufig die gesamte Veränderung. Es bestimmt zunehmend, welcher bereits vorbereitete Funktionsstand aktiv werden soll.

Das Enablement Package als Master-Switch

An dieser Stelle kommt das Enablement Package ins Spiel. Microsoft bezeichnet das Aktivierungspaket für 26H2 anschaulich als kleinen Master-Switch. Das Paket schaltet die bereits vorhandenen, aber bislang ruhenden Funktionen frei und hebt das System damit auf Windows 11 26H2. Deshalb unterscheidet sich ein solches Upgrade deutlich von einem vollständigen Betriebssystemwechsel. Für geeignete Systeme mit 24H2 oder 25H2 genügt das Enablement Package. Microsoft nennt für den Wechsel in den meisten Szenarien lediglich einen Neustart.

Allerdings setzt dieser scheinbar kleine Schalter einen vorbereiteten Systemzustand voraus. Für das 26H2-Aktivierungspaket verlangt Microsoft mindestens das entsprechende kumulative Update vom September 2026 oder einen neueren Stand. Das verdeutlicht die eigentliche Architektur: Die monatlichen Updates bereiten die Plattform vor. Das Enablement Package aktiviert den vorgesehenen Versionsstand. Der Umfang des heruntergeladenen Feature Updates sagt deshalb immer weniger darüber aus, wie groß die vorausgegangene technische Veränderung tatsächlich war.

Aus einem Upgrade wird eine Zustandsänderung

Damit lässt sich auch der Wechsel von 25H2 auf 26H2 anders beschreiben als ein klassisches Betriebssystem-Upgrade. Der Rechner erhält nicht erst mit dem Feature Update sämtliche Bestandteile der neuen Version. Viele Komponenten und Funktionen können bereits zuvor über die monatlichen Updates auf das System gelangt sein und dort zunächst inaktiv bleiben. Gleichzeitig entwickelt Microsoft den gemeinsamen Windows-Core kontinuierlich weiter.

Das Enablement Package setzt auf diesem bereits vorbereiteten Zustand auf. Es aktiviert den vorgesehenen Funktionsstand und macht aus dem kontinuierlich aktualisierten System den definierten Versionsstand Windows 11 26H2. Aus dem klassischen Upgrade wird damit zunehmend eine Zustandsänderung innerhalb einer bereits weiterentwickelten Plattform.

Die Abbildung zeigt diese beiden Ebenen: Sichtbar wechseln die Versionsstände von 24H2 über 25H2 zu 26H2. Darunter bleibt der gemeinsame Windows-Core jedoch nicht unverändert, sondern entwickelt sich über monatliche Updates kontinuierlich weiter. Die Versionsgrenzen markieren bestimmte freigegebene Zustände dieser Plattform. Gemeinsamer Core darf deshalb allerdings nicht mit Versionsnummer spielt keine Rolle mehr verwechselt werden. Mit 26H2 beginnt beispielsweise ein neuer Support-Lifecycle. Gleichzeitig können Funktionen mit dem Versionswechsel standardmäßig aktiviert werden, obwohl die dafür notwendigen Komponenten technisch bereits zuvor auf dem System vorhanden waren.

Die Versionsnummer verliert also nicht ihre Bedeutung. Ihre Bedeutung verändert sich. Sie beschreibt zunehmend weniger den Zeitpunkt, an dem sämtliche neuen Dateien auf einen Rechner gelangen. Stattdessen kennzeichnet sie einen definierten Funktions-, Support- und Servicing-Stand innerhalb der kontinuierlich weiterentwickelten Windows-Plattform.

Weniger Aufwand – aber nicht ohne Tests

Für Unternehmen bietet dieses Modell offensichtliche Vorteile. Microsoft nennt selbst einen geringeren Validierungsaufwand als einen Vorteil der gemeinsamen Plattform. Da kein vollständiges Betriebssystem ausgetauscht werden muss, sinken außerdem Installationsdauer und Ausfallzeit. Das bedeutet jedoch nicht, dass Unternehmen ein Enablement Package ungeprüft verteilen sollten. Schließlich können mit der Aktivierung Funktionen wirksam werden, die vorher zwar bereits als Code vorhanden waren, sich aber noch nicht auf den produktiven Betrieb ausgewirkt haben. Richtlinien, Sicherheitsfunktionen oder veränderte Standardwerte können dadurch plötzlich relevant werden.

Genau hier liegt eine wichtige Unterscheidung: Technische Kontinuität reduziert den Aufwand eines Upgrades. Sie beseitigt nicht automatisch dessen betriebliche Auswirkungen. Auf diese Konsequenz werden wir später noch ausführlicher zurückkommen. Gerade für Administrator:innen wird es zunehmend wichtig, nicht nur den eigentlichen Versionswechsel zu testen, sondern die kontinuierliche Veränderung der gemeinsamen Plattform im Blick zu behalten.

Das Feature Update kommt nicht mehr allein

24H2, 25H2 und 26H2 zeigen damit exemplarisch, wie weit sich Windows vom klassischen Release-Modell entfernt hat. Neue Funktionen können über monatliche Updates ausgeliefert werden. Ihre Aktivierung kann zu einem anderen Zeitpunkt erfolgen. Ein Enablement Package kann einen neuen Versionsstand freischalten. Gleichzeitig beginnt mit diesem Versionsstand ein neuer Lifecycle.

Aus einem früher vergleichsweise klaren Ereignis – eine neue Windows-Version erscheint – wird dadurch ein Zusammenspiel mehrerer Mechanismen. Für die technische Verwaltung ist das effizient. Für die Einordnung von Veränderungen wird es jedoch anspruchsvoller. Denn die entscheidende Frage lautet nicht mehr nur, wann ein Feature Update installiert wird. Ebenso wichtig ist, wann Microsoft neue Funktionen auf die Plattform bringt und wann diese tatsächlich aktiv werden.

Diese technische Entwicklung verändert allerdings noch etwas anderes: unser Erleben einer neuen Windows-Version. Über viele Jahre war ein neues Windows ein klar erkennbarer Einschnitt. Auf eine längere Entwicklungs- und Erwartungsphase folgte ein neues Betriebssystem, das anschließend über Jahre den Arbeitsalltag prägte. Heute verschwimmen diese Grenzen zunehmend. Funktionen erscheinen schrittweise, Veränderungen werden frühzeitig öffentlich sichtbar und der eigentliche Versionswechsel kann schließlich so unspektakulär verlaufen wie das eingangs beschriebene Upgrade auf Windows 11 26H2.

Bevor wir deshalb mit Continuous Innovation betrachten, welches Entwicklungs- und Bereitstellungsmodell hinter diesem Wandel steht, lohnt sich ein kurzer Blick zurück: Wie wurde aus dem Erscheinen einer neuen Windows-Version, auf das teilweise jahrelang hingefiebert wurde, ein beinahe alltäglicher Bestandteil des laufenden Betriebs?

Continuous Innovation: Wenn das Feature Update sein Feature-Monopol verliert

Mit dem gemeinsamen Servicing-Unterbau von 24H2, 25H2 und 26H2 verändert sich nicht nur der technische Ablauf eines Upgrades. Auch die Frage, wann Windows eigentlich neue Funktionen erhält, lässt sich nicht mehr eindeutig mit dem Erscheinen einer neuen Version beantworten. Microsoft entwickelt Windows inzwischen kontinuierlicher weiter. Funktionen können über monatliche Updates auf Geräte gelangen, zunächst inaktiv bleiben und später schrittweise freigeschaltet werden. Andere Neuerungen erscheinen unabhängig vom jährlichen Versionswechsel. Das Feature Update bildet deshalb nicht mehr zwangsläufig den Moment, an dem sämtliche Veränderungen eines Jahres erstmals auf einem System eintreffen.

Diese Entwicklung beschreibt Microsoft mit dem Konzept der Continuous Innovation. Dahinter steckt mehr als eine höhere Updatefrequenz. Microsoft löst die Weiterentwicklung von Windows zunehmend von einzelnen großen Release-Zeitpunkten. Damit verliert das Feature Update eine Rolle, die es seit den Windows-10-Tagen nahezu selbstverständlich besaß: das Monopol auf neue Windows-Funktionen.

Als eine neue Windows-Version noch ein Ereignis war

Über viele Jahre ließ sich die Entwicklung von Windows vergleichsweise einfach nachvollziehen. Eine neue Version brachte eine neue Oberfläche, zusätzliche Funktionen und technische Veränderungen. Wer von Windows 7 auf Windows 8 oder später auf Windows 10 wechselte, konnte den Versionssprung kaum übersehen. Entsprechend eindeutig war die Erwartung: Neue Funktionen gehörten zu einer neuen Windows-Version.

Ganz neu ist die Idee, ein bestehendes Windows nachträglich um Funktionen zu erweitern, allerdings nicht. Bereits mit Windows Vista Ultimate experimentierte Microsoft mit einem Ansatz, der aus heutiger Perspektive wie ein früher Vorläufer kontinuierlicher Funktionsbereitstellung wirkt. Über die sogenannten Windows Ultimate Extras konnten zusätzliche Funktionen nachträglich über Windows Update bereitgestellt werden. Ein bekanntes Beispiel war Windows DreamScene, das Videos als animierten Desktop-Hintergrund ermöglichte.

Diese Erweiterungen waren auf die Ultimate Edition beschränkt und blieben überwiegend ergänzender oder dekorativer Natur. Eine kontinuierliche Weiterentwicklung der eigentlichen Windows-Plattform, wie wir sie heute kennen, entstand daraus noch nicht. Gerade im Unternehmensumfeld waren stabile, klar definierte Systemstände wichtiger als regelmäßig nachgelieferte Funktionen. Rückblickend lässt sich daher zumindest vermuten, dass sowohl das technische Bereitstellungsmodell als auch die Erwartungen an ein Betriebssystem für einen umfassenderen Ansatz noch nicht weit genug entwickelt waren.

Mit Windows 10 griff Microsoft den Grundgedanken in wesentlich größerem Maßstab auf. Windows as a Service brachte regelmäßig Feature Updates und kumulative Qualitätsupdates. Nun ging es nicht mehr um einzelne Extras einer Premium-Edition, sondern um die kontinuierliche Weiterentwicklung der Windows-Plattform selbst. Dennoch blieben die großen Funktionsupdates zunächst zentrale Ereignisse dieser Entwicklung.

Windows 11 führt diesen Ansatz inzwischen deutlich weiter. Neue Funktionen müssen nicht mehr auf das nächste jährliche Feature Update warten. Microsoft kann sie innerhalb einer bestehenden Version bereitstellen und kontrolliert aktivieren. Dadurch verliert der Versionswechsel einen Teil seiner früheren Bedeutung. Das bedeutet allerdings nicht, dass Windows-Versionen bedeutungslos werden. Vielmehr trennen sich Funktionen, die früher eng miteinander verbunden waren: Technische Weiterentwicklung, Funktionsbereitstellung und Versionswechsel finden nicht mehr zwangsläufig gleichzeitig statt.

Continuous Innovation: Windows verändert sich zwischen den Releases

Continuous Innovation bedeutet im Kern, dass Microsoft neue Windows-Funktionen und Verbesserungen bereitstellen kann, sobald sie für die jeweilige Plattform vorgesehen sind. Das Betriebssystem entwickelt sich dadurch auch innerhalb einer bestehenden Versionsnummer weiter. Ein Windows-11-System im Frühjahr und dasselbe System im Herbst können daher denselben Versionsnamen tragen und sich funktional dennoch unterscheiden. Dabei nutzt Microsoft mehrere Mechanismen. Neuerungen können Bestandteil regulärer kumulativer Updates sein. Bestimmte Funktionen werden zunächst kontrolliert an einen begrenzten Teil der Geräte verteilt. Andere Komponenten liegen bereits auf dem System und werden erst später aktiviert.

Für Benutzer:innen entsteht dadurch eine eher fließende Weiterentwicklung. Für Administrator:innen wird die Situation anspruchsvoller: Die installierte Versionsnummer allein beschreibt nicht mehr vollständig, welche Funktionen auf einem Gerät tatsächlich verfügbar sind. Windows 11 25H2 bezeichnet damit einen unterstützten Plattformstand – aber nicht zwangsläufig einen über seinen gesamten Lebenszyklus unveränderten Funktionsumfang.

Controlled Feature Rollout: Nicht alle erhalten alles gleichzeitig

Eine wichtige Rolle spielt dabei der Controlled Feature Rollout, kurz CFR. Microsoft kann neue Funktionen schrittweise für Teile der installierten Gerätebasis aktivieren, anstatt sie gleichzeitig auf allen kompatiblen Rechnern freizuschalten. Das hat einen praktischen Hintergrund: Eine Funktion kann unter realen Bedingungen zunächst auf einer begrenzten Anzahl von Systemen bereitgestellt werden. Treten Probleme auf, lässt sich die weitere Verteilung begrenzen, bevor eine wesentlich größere Gerätebasis betroffen ist.

Damit verändert sich jedoch auch die Vorstellung eines eindeutigen Release-Zeitpunkts. Zwei Rechner mit derselben Windows-Version und demselben grundsätzlichen Update-Stand müssen nicht zwingend zum selben Zeitpunkt über exakt denselben Funktionsumfang verfügen. Hinzu kommen administrative Steuerungsmöglichkeiten, mit denen Unternehmen bestimmte Neuerungen kontrollierter übernehmen können. Die Frage ‚Welche Windows-Version läuft auf dem Gerät?‘ bleibt deshalb wichtig, reicht für eine vollständige Bestandsaufnahme aber zunehmend nicht mehr aus. Ebenso relevant wird: Welcher Funktions- und Policy-Stand ist tatsächlich aktiv?

Monatliches Update und Feature Update wachsen zusammen

Diese Entwicklung lässt sich besonders gut an 26H2 erkennen. Wie im vorherigen Kapitel beschrieben, können monatliche Updates bereits Komponenten bereitstellen, die später Bestandteil des neuen Versionsstandes werden. Das Enablement Package aktiviert anschließend den vorbereiteten Zustand. Damit verschwimmt die traditionelle Grenze zwischen Quality Update und Feature Update. Das monatliche Update wartet und korrigiert nicht mehr ausschließlich eine statische Betriebssystemversion. Es kann gleichzeitig die technische Grundlage für kommende Funktionen weiterentwickeln. Das Feature Update wiederum muss diese Funktionen nicht mehr vollständig neu installieren.

Beide Mechanismen übernehmen damit unterschiedliche Aufgaben innerhalb desselben Entwicklungsprozesses: Servicing hält die Plattform aktuell und entwickelt sie weiter. Enablement aktiviert einen vorgesehenen Zustand. Die Versionsnummer kennzeichnet einen definierten Release- und Supportstand. Gerade diese Trennung erklärt, warum ein Feature Update heute wesentlich kleiner und unspektakulärer ausfallen kann als frühere Windows-Upgrades.

Das Feature Update bleibt – aber seine Aufgabe verändert sich

Es wäre deshalb vorschnell, aus Continuous Innovation das Ende des Feature Updates abzuleiten. Die jährlichen Windows-Versionen erfüllen weiterhin wichtige Aufgaben. Sie schaffen einen klar bezeichneten Plattformstand, definieren Supportzeiträume und geben Unternehmen Orientierung für Deployment und Lifecycle-Management.

Verändert hat sich vielmehr ihr Schwerpunkt. Das Feature Update ist nicht mehr zwangsläufig der große Container, in dem Microsoft die Neuerungen eines Jahres sammelt und anschließend gemeinsam ausliefert. Viele Veränderungen erreichen die Windows-Plattform bereits vorher über monatliche Updates, während Funktionen vorbereitet, schrittweise aktiviert oder über Controlled Rollouts bereitgestellt werden. Das Feature Update wird damit zunehmend zu einem Meilenstein innerhalb einer kontinuierlich weiterentwickelten Plattform.

Die Abbildung trennt die Aufgaben dieses Modells bewusst voneinander. Continuous Innovation steht für die fortlaufende Entwicklung neuer Funktionen und Verbesserungen. Servicing pflegt und erweitert die technische Plattform über die laufenden Updates. Controlled Rollouts steuern, wann vorbereitete Funktionen tatsächlich auf Geräten verfügbar werden. Das Feature Update markiert schließlich einen klar bezeichneten Versionsstand mit einem definierten Lifecycle. Diese Prozesse greifen ineinander, fallen aber nicht mehr zwangsläufig auf denselben Zeitpunkt.

Genau darin liegt der entscheidende Perspektivwechsel: Eine neue Windows-Version lässt sich nicht mehr allein daran messen, wie viele neue Funktionen unmittelbar nach dem Feature Update sichtbar werden. Ein Teil der Veränderung kann längst auf dem System angekommen sein, ein anderer erst später aktiviert werden. Wer Windows 11 26H2 nur nach den unmittelbar sichtbaren Neuerungen beurteilt, betrachtet deshalb lediglich einen einzelnen Zeitpunkt innerhalb einer kontinuierlichen Entwicklung.

Vom Produktrelease zur kontinuierlichen Plattform

Aus dieser Perspektive wirkt das unspektakuläre Upgrade vom Beginn dieses Beitrags plötzlich weniger ungewöhnlich. Windows muss nach dem Wechsel auf 26H2 nicht vollkommen anders aussehen, weil seine Weiterentwicklung längst nicht mehr ausschließlich in diesem einen Moment stattfindet. Das Feature Update aktiviert und markiert einen neuen Plattformzustand innerhalb eines Entwicklungsprozesses, der bereits vorher begonnen hat und anschließend weiterläuft.

Damit verändert sich auch die Erwartung an eine neue Windows-Version. Die entscheidende Frage lautet nicht mehr ausschließlich: ‚Was ist in 26H2 neu?‘ Ebenso wichtig wird: ‚Wie verändert Microsoft Windows zwischen 25H2, 26H2 und dem nächsten Release?‘ Das Feature Update verliert damit nicht seine Relevanz. Aber es verliert zunehmend sein Feature-Monopol. Und genau diese Entwicklung führt zu einer grundsätzlicheren Frage. Wenn Windows immer stärker zu einer kontinuierlich gepflegten Plattform wird, während Anwendungen, Daten und Dienste gleichzeitig in Browser, Cloud und mobile Ökosysteme wandern: Welche Bedeutung besitzt das klassische Desktop-Betriebssystem im Jahr 2026 überhaupt noch?

Qualität, Performance und Zuverlässigkeit: Microsofts Schwerpunkt 2026

Bis hierhin könnte der Eindruck entstehen, Windows 11 26H2 wirke vor allem deshalb unspektakulär, weil Microsoft neue Funktionen inzwischen kontinuierlicher verteilt. Das Servicing-Modell erklärt tatsächlich einen wichtigen Teil davon. Doch möglicherweise kommt 2026 noch ein zweiter Faktor hinzu. Im März 2026 formulierte Pavan Davuluri, Executive Vice President Windows and Devices bei Microsoft, ungewöhnlich deutlich, worauf sich die Windows-Entwicklung im laufenden Jahr konzentrieren soll: Performance, Reliability und Craft – also Leistung, Zuverlässigkeit und die sorgfältige Ausgestaltung des Benutzererlebnisses.

Bemerkenswert ist dabei der Ausgangspunkt. Microsoft verweist ausdrücklich auf Rückmeldungen aus der Windows-Community, die das Unternehmen in den vorausgegangenen Monaten ausgewertet habe. Die daraus abgeleiteten Maßnahmen betreffen keineswegs nur neue Funktionen. Vielmehr geht es um grundlegende Eigenschaften eines Betriebssystems: Geschwindigkeit, Stabilität, Ressourcenverbrauch, Bedienbarkeit und Verlässlichkeit.

Das verschiebt den Blickwinkel. Ein Betriebssystem entwickelt sich schließlich nicht nur dann weiter, wenn ein neues Symbol auf der Taskleiste erscheint oder eine zusätzliche Anwendung hinzukommt. Auch ein schnellerer Explorer, geringerer Speicherverbrauch oder ein zuverlässiger funktionierender Treiber sind Weiterentwicklung. Nur lässt sie sich schlechter auf einem Screenshot zeigen.

Performance beginnt bei den Grundlagen

Microsoft nennt für 2026 eine ganze Reihe solcher Verbesserungen. Windows soll weniger Systemressourcen beanspruchen und dadurch mehr Leistung für Anwendungen freigeben. Gleichzeitig soll der grundlegende Speicherbedarf sinken. Auch zentrale Komponenten stehen auf der Agenda. Der Datei-Explorer soll schneller starten, Navigation und Suche sollen mit geringerer Verzögerung reagieren und das Kopieren großer Dateien zuverlässiger funktionieren. Teile der Windows-Oberfläche werden weiter auf WinUI 3, Microsofts modernem Framework für die Entwicklung von Windows-Benutzeroberflächen, umgestellt, um Latenzen und Overhead auf Plattformebene zu reduzieren.

Das sind keine spektakulären Funktionen im klassischen Sinne. Im täglichen Betrieb können solche Veränderungen jedoch erheblich relevanter sein als ein weiteres sichtbares Feature. Microsoft berichtete Ende Juli bereits über erste Fortschritte. Dazu gehörten Verbesserungen an der Speicherverwaltung, an WinUI 3 sowie an Start, Suche und Datei-Explorer. Auch Start- und Anmeldezeiten sowie die Reaktionsfähigkeit verschiedener Systemkomponenten nennt Microsoft als Arbeitsfelder. Damit verändert sich auch die Frage, anhand derer wir eine neue Windows-Version beurteilen. Nicht nur: Was kann Windows jetzt zusätzlich? Sondern ebenso: Wie gut funktioniert das, was Windows bereits kann?

Zuverlässigkeit als Voraussetzung für Vertrauen

Noch deutlicher wird diese Verschiebung beim zweiten Schwerpunkt: Reliability. Microsoft bezeichnet Zuverlässigkeit als Grundlage für Vertrauen in die Plattform. Entsprechend reicht die angekündigte Arbeit tief in das Betriebssystem und sein Hardware-Ökosystem hinein. Betriebssystemabstürze sollen reduziert, die Qualität von Treibern und Anwendungen verbessert und alltägliche Verbindungen stabiler werden. Dazu gehören Bluetooth-Geräte ebenso wie USB, Drucker, Kameras und Audiohardware. Auch das Aufwachen von Geräten sowie Windows Hello stehen auf der Liste. Gleichzeitig soll Windows Update vorhersehbarer werden und Benutzer:innen stärker kontrollieren lassen, wann Updates und Neustarts stattfinden.

Gerade für Unternehmen ist dieser Punkt entscheidend. Eine neue Funktion kann interessant sein. Ein instabiler Treiber, ein problematisches Update oder eine unzuverlässige Dockingstation kann dagegen unmittelbar Arbeitsplätze beeinträchtigen. Qualität ist deshalb keine kosmetische Eigenschaft eines Betriebssystems. Sie ist Voraussetzung dafür, dass eine Plattform im produktiven Betrieb akzeptiert wird. Mit der im Mai gestarteten Driver Quality Initiative hat Microsoft diesen Anspruch inzwischen auch auf das Hardware- und Treiberökosystem ausgeweitet.

‚Craft‘: Wenn weniger manchmal mehr bedeutet

Der dritte Schwerpunkt lässt sich mit Handwerkskunst oder handwerklichem Geschick übersetzen. Microsoft verwendet den Begriff Craft für die Sorgfalt und Qualität, mit der Funktionen gestaltet, umgesetzt und in das Gesamtsystem integriert werden. Es geht also nicht nur darum, was Windows kann, sondern auch darum, wie gut sich einzelne Funktionen in das Betriebssystem einfügen. Dazu gehören konsistentere Oberflächen, weniger Ablenkung, bessere Personalisierung und ein insgesamt ruhigeres Benutzendenerlebnis.

Besonders interessant ist dabei Microsofts Umgang mit künstlicher Intelligenz. Statt Copilot möglichst an vielen Stellen sichtbar zu platzieren, kündigte Microsoft an, KI gezielter dort einzusetzen, wo sie tatsächlich einen Nutzen bietet. Unnötige Copilot-Einstiegspunkte sollen reduziert werden. Auch Widgets, Benachrichtigungen und die Einrichtung neuer Geräte sollen weniger aufdringlich wirken. Das ist bemerkenswert, weil sich darin ein anderer Innovationsbegriff erkennen lässt. Mehr Funktionen bedeuten nicht zwangsläufig ein besseres Betriebssystem. Manchmal besteht Verbesserung darin, eine bestehende Funktion schneller zu machen, eine Oberfläche aufzuräumen oder eine Integration wieder zurückzunehmen. Innovation kann deshalb auch bedeuten, bewusster zu entscheiden, was Windows nicht zusätzlich benötigt.

Ist 26H2 deshalb so unspektakulär?

Damit kommen wir zurück zu Windows 11 26H2. Es wäre verführerisch, eine direkte Verbindung herzustellen: Microsoft konzentriert sich 2026 stärker auf Qualität – deshalb fällt das Feature Update 26H2 vergleichsweise unspektakulär aus. So eindeutig lässt sich diese Kausalität aus Microsofts Aussagen jedoch nicht ableiten. Das zurückhaltende Erscheinungsbild von 26H2 lässt sich bereits durch das veränderte Servicing-Modell erklären. Viele Funktionen gelangen über monatliche Updates und Controlled Feature Rollouts auf die Systeme. Das jährliche Feature Update muss deshalb nicht mehr das große Paket sichtbarer Neuerungen sein.

Trotzdem passt 26H2 auffällig gut in die von Microsoft für 2026 formulierte Richtung. Statt ausschließlich neue Funktionen in den Vordergrund zu stellen, investiert Microsoft parallel in Performance, Zuverlässigkeit, Treiberqualität, Ressourcenverbrauch und die Grundlagen der Windows-Oberfläche. Noch Ende Juli bekräftigte Davuluri diese Prioritäten und kündigte an, die entsprechenden Verbesserungen im weiteren Jahresverlauf breiter auszurollen. Deshalb lässt sich zumindest eine vorsichtige Einordnung formulieren: Vielleicht ist das unspektakuläre Feature Update nicht nur Resultat des neuen Servicing-Modells, sondern teilweise auch Ausdruck einer bewussten Rückbesinnung auf Qualität und Plattformpflege.

Ein gutes Betriebssystem muss nicht ständig überraschen

Das wäre letztlich eine interessante Verschiebung der Perspektive. Über Jahre haben wir neue Betriebssystemversionen vor allem anhand sichtbarer Neuerungen bewertet. Eine lange Feature-Liste signalisierte Fortschritt. Ein Update ohne spektakuläre Neuerungen wirkte dagegen schnell enttäuschend. Für eine etablierte Plattform wie Windows könnte inzwischen ein anderer Maßstab sinnvoller sein.

Wenn ein System schneller reagiert, weniger Arbeitsspeicher benötigt, zuverlässiger mit Hardware zusammenarbeitet, Updates weniger stören und zentrale Komponenten stabiler funktionieren, dann hat es sich verbessert – selbst wenn Benutzer:innen nach dem Neustart zunächst denselben Desktop sehen. Vielleicht ist gerade das eine der interessanteren Entwicklungen des Windows-Jahres 2026: Microsoft muss nicht nur beweisen, dass Windows immer mehr kann. Das Unternehmen muss beweisen, dass Windows das, was es bereits kann, immer besser beherrscht.

Was Windows 11 26H2 tatsächlich verändert

Nach Servicing, Continuous Innovation, Marktposition und Microsofts neuem Qualitätsfokus wird es Zeit für die naheliegende Frage: Was verändert Windows 11 26H2 eigentlich konkret? Eine einfache Liste neuer Funktionen würde allerdings genau das Problem erzeugen, das wir in den vorangegangenen Kapiteln beschrieben haben. Nicht alles, was heute mit 26H2 verbunden wird, kommt erst mit dem Feature Update auf den Rechner. Microsoft unterscheidet selbst zwischen Funktionen, die mit 26H2 für kommerzielle Systeme standardmäßig aktiviert werden, und Neuerungen, die seit 25H2 bereits über monatliche Updates in Windows eingeflossen sind. Dazu gehören unter anderem Sicherheitsfunktionen, Änderungen an der Anmeldung und Administration sowie Verbesserungen an Oberfläche und Hardwareunterstützung.

26H2 ist damit weniger eine Kiste voller neuer Funktionen als ein definierter Stand einer Plattform, die sich bereits während des Jahres weiterentwickelt hat. Genau aus dieser Perspektive lohnt sich der Blick auf die Neuerungen. Denn in ihrer Gesamtheit zeigen sie einige klare Entwicklungsrichtungen: weniger dauerhaft verfügbare administrative Rechte, bessere Beobachtbarkeit, höhere Widerstandsfähigkeit, eine schrittweise modernisierte Oberfläche und stärkere Unterstützung aktueller PC-Hardware. Und selbst das Entfernen alter Komponenten gehört inzwischen zu dieser Entwicklung.

Security und Privilege Management

Ein Schwerpunkt von Windows 11 26H2 liegt erneut auf der Absicherung privilegierter Zugriffe. Besonders deutlich wird das bei Administrator Protection. Die Funktion setzt an einem grundlegenden Problem klassischer Administrationsmodelle an: Administrative Berechtigungen sind häufig dauerhaft mit einem Benutzerkonto verbunden, obwohl sie nur für einzelne Aufgaben benötigt werden. Administrator Protection verschiebt dieses Prinzip in Richtung Just-in-Time Elevation. Benutzer:innen arbeiten zunächst ohne erhöhte Rechte. Erst wenn eine administrative Aufgabe ansteht, fordert Windows eine explizite Autorisierung an. Für den eigentlichen Vorgang erzeugt das System anschließend einen getrennten privilegierten Kontext. Nach Abschluss der Aufgabe bleibt das dafür verwendete Administratortoken nicht dauerhaft bestehen.

Die Abbildung zeigt, dass Microsoft dabei mehrere Sicherheitsprinzipien miteinander verbindet: Just-in-Time-Erhöhung, Profiltrennung, interaktive Autorisierung und Windows Hello. Entscheidend ist damit nicht nur, wer administrative Rechte besitzt, sondern zunehmend auch, für welche Aufgabe und für welchen Zeitraum diese Rechte tatsächlich bereitgestellt werden. Administrator Protection ist standardmäßig deaktiviert und lässt sich unter anderem über Microsoft Intune oder Gruppenrichtlinien konfigurieren.

Parallel entwickelt Microsoft weitere Schutzmechanismen weiter. Smart App Control kann nun aktiviert oder deaktiviert werden, ohne Windows dafür neu installieren zu müssen. Bei Passkeys unterstützt Windows externe Credential Manager. Windows Hello Enhanced Sign-in Security erweitert zudem die Unterstützung kompatibler Fingerabdrucksensoren. Die gemeinsame Richtung wird damit deutlich: Windows begrenzt privilegierte Zugriffe stärker und integriert moderne, möglichst passwortlose Authentisierung tiefer in die Plattform. Administrator Protection geht dabei jedoch über eine zusätzliche Sicherheitseinstellung hinaus. Die Funktion verändert ein Administrationsmodell, das Windows über Jahrzehnte geprägt hat. Deshalb lohnt sich anschließend ein genauerer Blick auf den Weg von lokaler Administration zur Just-in-Time Elevation.

Observability und Security Operations

Der Blick auf Sysmon hat gezeigt, welche Bedeutung Telemetrie und Beobachtbarkeit inzwischen für die Sicherheit eines Betriebssystems besitzen. Angriffe müssen nicht nur verhindert werden. Verdächtiges Verhalten muss ebenso erkannt, nachvollzogen und für weitere Analysen verfügbar gemacht werden. Mit der Integration von Sysmon erweitert Windows dafür seine eigene Grundlage. Security-Teams können detaillierte Systemereignisse erfassen und anschließend über das Windows Event Log oder angebundene Security-Plattformen auswerten. Entscheidend ist dabei weniger das einzelne Werkzeug als die dahinterstehende Entwicklung: Observability wird zunehmend zu einer Fähigkeit der Windows-Plattform selbst.

Diese Entwicklung beschränkt sich jedoch nicht auf Security Operations. Auch der Task-Manager gewinnt zusätzliche Möglichkeiten zur Beobachtung moderner Systeme. Auf geeigneter Hardware kann er beispielsweise die Nutzung einer Neural Processing Unit, kurz NPU, detaillierter darstellen. Damit wird eine Hardwarekomponente sichtbar, die mit KI-beschleunigten Anwendungen und Copilot+ PCs zunehmend an Bedeutung gewinnt. Zusätzliche Informationen helfen außerdem dabei, Prozesse und deren Sicherheitskontext besser einzuordnen. Dazu gehört beispielsweise die Information, ob eine Anwendung innerhalb eines AppContainers, also einer besonders eingeschränkten und isolierten Ausführungsumgebung von Windows, läuft.

Damit reicht die eingebaute Beobachtbarkeit inzwischen vom klassischen Ressourcenmonitoring über moderne Hardwarebeschleuniger bis hin zu sicherheitsrelevanter Telemetrie. Windows soll nicht nur verwalten, was auf einem System geschieht. Die Plattform soll zunehmend auch sichtbar machen, wie es geschieht.

Resilience und Recovery

Eine moderne Sicherheitsstrategie endet nicht mit Prävention und Erkennung. Systeme müssen sich auch dann zuverlässig wiederherstellen lassen, wenn etwas schiefgeht. 26H2 passt deshalb in eine Entwicklung, in der Microsoft Resilience und Recovery stärker als Bestandteil der Plattform behandelt. Ein sichtbares Beispiel ist die Sicherung von Windows-Einstellungen. Für geeignete kommerzielle Geräte wird diese mit 26H2 standardmäßig aktiviert. Unterstützte Einstellungen und Listen installierter Microsoft-Store-Apps können dadurch für Wiederherstellungs- und Geräteaustauschszenarien erhalten bleiben. Bereits konfigurierte administrative Richtlinien behalten dabei ihre Wirkung.

Der Gedanke dahinter reicht über ein klassisches Backup hinaus. In modernen, cloudverwalteten Umgebungen muss nicht zwangsläufig der komplette Zustand eines alten PCs konserviert werden. Entscheidend ist vielmehr, einen neuen oder wiederhergestellten Rechner möglichst schnell wieder in einen definierten und arbeitsfähigen Zustand zu versetzen. Damit nähert sich Windows einem Prinzip an, das aus moderner Geräteverwaltung bereits vertraut ist: Nicht der einzelne Rechner ist unersetzlich – entscheidend sind Identität, Richtlinien, Anwendungen und wiederherstellbare Einstellungen. Gerade für Unternehmen wird Recovery damit zunehmend Teil des Lifecycle- und Endpoint-Managements und weniger eine isolierte Reparaturmaßnahme am einzelnen PC.

Desktop, Explorer, Start und Search

Auch an der sichtbaren Windows-Oberfläche arbeitet Microsoft weiter. Die Veränderungen fallen jedoch eher evolutionär als revolutionär aus. Mit 26H2 werden für kommerzielle Geräte beispielsweise mehrere zuvor kontrollierte Funktionen standardmäßig aktiviert. Dazu gehören Verbesserungen im Datei-Explorer sowie anwendungsspezifische Aktionen über die Taskleiste. Benutzer:innen können dadurch bestimmte Funktionen einer Anwendung direkter aus der Taskleistenumgebung aufrufen. Hinzu kommen die bereits im vorherigen Kapitel beschriebenen Arbeiten an Explorer, Start und Suche. Dabei geht es nicht ausschließlich um neue Bedienelemente. Microsoft versucht gleichzeitig, Reaktionszeiten, Navigation und das Zusammenspiel der zugrunde liegenden UI-Komponenten zu verbessern.

Genau darin zeigt sich erneut der veränderte Charakter von Windows 11. Eine neue Version muss nicht zwangsläufig eine neue Desktop-Metapher oder ein vollständig überarbeitetes Startmenü präsentieren. Stattdessen verändert Microsoft einzelne Bestandteile schrittweise – und teilweise unabhängig vom jährlichen Feature Update. Für Benutzer:innen kann 26H2 deshalb vertraut aussehen und sich dennoch in vielen Details anders verhalten. Evolution ersetzt an dieser Stelle zunehmend den großen Oberflächenbruch.

Hardware, Connectivity und moderne PC-Plattformen

Parallel verändert sich die Hardware, auf der Windows ausgeführt wird. Besonders deutlich zeigt sich das an der zunehmenden Bedeutung von NPUs, neuen Prozessorplattformen und KI-beschleunigten Anwendungen. Dass der Task-Manager inzwischen detailliertere Informationen zur NPU-Auslastung bereitstellt, ist deshalb mehr als eine kosmetische Ergänzung. Eine Hardwarekomponente, die vor wenigen Jahren auf typischen PCs kaum eine Rolle spielte, wird zunehmend zu einer regulär überwachten Systemressource.

Auch an anderen Stellen entwickelt Microsoft die Hardwareintegration weiter. Moderne Authentisierung kann beispielsweise kompatible externe Fingerabdrucksensoren stärker in Enhanced Sign-in Security einbeziehen. Parallel verbessert Microsoft – wie bereits im vorherigen Kapitel betrachtet – die Zuverlässigkeit von Bluetooth-, USB-, Kamera- und Audiokomponenten.

Diese Veränderungen wirken einzeln wenig spektakulär. Zusammen zeigen sie jedoch, wie Windows auf eine heterogener werdende PC-Landschaft reagieren muss. Der klassische x86-PC ist längst nicht mehr das einzige Entwicklungsziel. ARM-Plattformen, Copilot+ PCs, NPUs und neue Peripherieanforderungen erweitern die Hardwarebasis, die Windows zuverlässig abstrahieren und verwalten muss. Windows modernisiert deshalb nicht nur seine Oberfläche. Auch die Vorstellung davon, was ein Windows-PC technisch ist, verändert sich.

Entfernte und abgekündigte Komponenten

Zur Weiterentwicklung einer Plattform gehört schließlich nicht nur, neue Funktionen hinzuzufügen. Microsoft muss auch Technologien entfernen, die ihren Lebenszyklus erreicht haben. Ein anschauliches Beispiel liefert WMIC, die Windows Management Instrumentation Command-Line. Das Kommandozeilenwerkzeug war bereits seit längerer Zeit abgekündigt. Mit aktuellen Windows-11-Versionen ist WMIC nun nicht mehr als Feature on Demand verfügbar. Microsoft führt die Entfernung ausdrücklich auch in der Dokumentation zu 26H2 auf. Für moderne Administrationsskripte ist das konsequent. Die zugrunde liegende Windows Management Instrumentation verschwindet dadurch nicht. Betroffen ist das ältere Kommandozeilenwerkzeug wmic.exe. Für Automatisierung und Administration stehen insbesondere PowerShell und die entsprechenden CIM-Cmdlets als moderne Alternativen zur Verfügung.

Solche Bereinigungen sind wichtig, weil jahrzehntelange Abwärtskompatibilität zwangsläufig technische Altlasten erzeugt. Jede historische Schnittstelle, jedes alte Werkzeug und jede weiterhin unterstützte Komponente vergrößert die Plattform, die Microsoft testen, warten und absichern muss. Damit besitzt das Entfernen alter Technologien ebenfalls strategische Bedeutung. Die Modernisierung von Windows entscheidet sich nicht nur daran, was Microsoft hinzufügt – sondern zunehmend auch daran, wovon sich die Plattform trennen kann.

Mehr Veränderung, als der Desktop vermuten lässt

Damit schließt sich der Kreis zur Ausgangsfrage dieses Beitrags. Wer von Windows 11 25H2 auf 26H2 aktualisiert und anschließend lediglich auf den Desktop schaut, könnte sich fragen, was sich überhaupt verändert hat. Betrachtet man dagegen Sicherheit, Privilegien, Observability, Recovery, Hardwareunterstützung und die Bereinigung älterer Technologien, entsteht ein anderes Bild. 26H2 ist kein Feature-Feuerwerk. Es bündelt vielmehr einen Entwicklungsstand, der an vielen Stellen gleichzeitig ansetzt.

Und genau deshalb lohnt sich bei diesem Windows ein zweiter Blick. Die vielleicht wichtigsten Veränderungen befinden sich nicht dort, wo Benutzer:innen sie unmittelbar sehen – sondern dort, wo Windows Rechte vergibt, Ereignisse protokolliert, Systeme wiederherstellt, neue Hardware integriert und alte Technologien hinter sich lässt.

Ein kleines Update ist nicht automatisch eine kleine Änderung

Das Upgrade auf Windows 11 26H2 kann erstaunlich unspektakulär verlaufen. Ein kleines Enablement Package, ein Neustart – und schon meldet Windows einen neuen Versionsstand. Daraus könnte schnell der Eindruck entstehen, auch die technische Veränderung müsse entsprechend klein sein. Doch genau hier führt das neue Servicing-Modell in die Irre.

Wie wir bereits gesehen haben, können Funktionen und Programmcode durch vorherige monatliche Updates längst auf einem System vorhanden sein. Richtlinien können ebenfalls bereits konfiguriert sein. Das Enablement Package muss diese Komponenten deshalb nicht erneut übertragen. Es kann vielmehr einen neuen Zustand der vorhandenen Plattform herstellen. Die Größe eines Updatepakets sagt damit immer weniger darüber aus, wie groß die daraus resultierende Veränderung eines Systems tatsächlich ist.

Ein aktuelles Problem rund um Machine Identity Isolation zeigt sehr anschaulich, welche Konsequenzen das haben kann. Denn dabei geht es nicht um ein verändertes Startmenü oder eine zusätzliche Einstellung. Unter bestimmten Voraussetzungen kann ein domänengebundener Windows-PC nach der Aktualisierung seine Vertrauensstellung zur Active-Directory-Domäne verlieren.

Wenn auch der Computer eine Identität besitzt

Um die Tragweite zu verstehen, lohnt sich ein kurzer Blick auf Active Directory. Nicht nur Benutzer:innen besitzen dort eine Identität. Auch ein domänengebundener Windows-PC verfügt über ein eigenes Computerkonto und ein zugehöriges Kennwort. Diese Maschinenidentität spielt eine wichtige Rolle bei der sicheren Kommunikation zwischen Client und Domäne. Machine Identity Isolation soll genau diese Identität besser schützen. Die Funktion verlagert die Anmeldeinformationen des Computerkontos in Credential Guard und schützt sie damit über eine virtualisierungsbasierte Sicherheitsumgebung. Im Enforcement-Modus befindet sich das Geheimnis des Computerkontos nicht mehr im klassischen LSA-Kontext, sondern wird für die Computerauthentisierung über Credential Guard bereitgestellt.

Das folgt derselben Sicherheitslogik, die uns bereits beim Schutz von Benutzeridentitäten begegnet ist: Wertvolle Anmeldeinformationen sollen möglichst weit vom regulären Betriebssystemkontext isoliert werden. Machine Identity Isolation überträgt dieses Prinzip auf die Identität des Rechners selbst.

26H2 schaltet die Richtlinie nicht einfach ein

Der entscheidende Punkt des aktuellen Problems ist ungewöhnlich – und für unser Thema besonders interessant. Microsoft weist ausdrücklich darauf hin, dass Windows 11 26H2 Machine Identity Isolation Enforcement nicht unmittelbar aktiviert. Das Update führt jedoch dazu, dass Windows bereits vorhandene oder zuvor per Richtlinie konfigurierte Einstellungen für das Enforcement berücksichtigt.

Damit treffen mehrere Zustände aufeinander:

• Die technische Funktion ist im Betriebssystem vorhanden
• Eine entsprechende Konfiguration kann bereits auf dem Gerät existieren
• Erst ein späterer Update- beziehungsweise Versionsstand sorgt dafür, dass Windows diese Konfiguration tatsächlich berücksichtigt

Das ist Continuous Innovation und modernes Windows Servicing nicht als abstraktes Konzept, sondern als praktisches Beispiel. Der Versionswechsel bringt nicht zwangsläufig erst den gesamten benötigten Code auf den Rechner. Er kann stattdessen verändern, wie bereits vorhandener Code und bereits vorhandene Konfiguration miteinander interagieren.

Aus einer vorhandenen Richtlinie wird plötzlich ein Problem

Unter normalen Voraussetzungen soll Machine Identity Isolation die Sicherheit der Maschinenidentität erhöhen. Der aktuelle Implementierungsstand besitzt jedoch eine wichtige Abhängigkeit: Microsoft unterstützt die Funktion nur in Umgebungen mit Domain Controllern auf Windows Server 2025 Domain Functional Level oder höher. Existiert auf einem Gerät bereits eine Konfiguration, die Machine Identity Isolation im Enforcement-Modus aktiviert, obwohl die Active-Directory-Umgebung diese Voraussetzung nicht erfüllt, kann das nach der Aktualisierung erhebliche Folgen haben.

Betroffene, durch Credential Guard geschützte Computerkonten können ihren Secure Channel zur lokalen Active-Directory-Domäne verlieren. Eine interaktive Anmeldung mit gültigen Domänenanmeldedaten kann anschließend scheitern. Windows meldet dann unter Umständen, dass die Vertrauensstellung zwischen Arbeitsstation und Domäne nicht hergestellt werden konnte. Eine Anmeldung mit zwischengespeicherten Anmeldeinformationen kann weiterhin funktionieren. Aus einer zuvor vorhandenen Einstellung wird damit durch einen veränderten Plattformzustand plötzlich ein betriebliches Problem.

Ein kleines Paket kann einen großen Zustandswechsel auslösen

Genau dieses Beispiel verändert die Perspektive auf das Enablement Package. Wenn neue Funktionen bereits durch vorherige Updates auf dem Rechner liegen, besteht die entscheidende Veränderung nicht zwangsläufig im Kopieren großer Mengen neuer Dateien. Ebenso wichtig ist die Frage, welche Fähigkeiten nach dem Versionswechsel aktiv sind und welche vorhandenen Einstellungen nun ausgewertet werden. Das erklärt auch, warum Unternehmen ein Enablement Package nicht allein aufgrund seiner geringen Größe als risikoarmes Update behandeln sollten. Das Enablement Package mag klein sein. Die Zustandsänderung, die es auslöst, muss es nicht sein.

Machine Identity Isolation macht diese Aussage ungewöhnlich konkret. Ein kurzer Installationsvorgang kann das Zusammenspiel zwischen Credential Guard, Computerkonto, Gruppenrichtlinien und Active Directory verändern. Damit wird aus einem scheinbar kleinen Windows-Update eine Veränderung, die unmittelbar die Authentisierung eines Geräts gegenüber der Unternehmensinfrastruktur berühren kann.

Testen müssen wir nicht nur neuen Code

Für Administrator:innen ergibt sich daraus eine wichtige Konsequenz. Klassische Updatebewertung konzentriert sich häufig auf die Frage, welche neuen Komponenten installiert werden und ob Anwendungen oder Treiber damit kompatibel bleiben. Im neuen Windows-Modell reicht diese Perspektive nicht mehr aus.

Ebenso wichtig werden Fragen wie:

• Welche Funktionen befinden sich bereits auf unseren Geräten?
• Welche Richtlinien sind für diese Funktionen bereits konfiguriert?
• Welche Einstellungen werden mit dem neuen Versionsstand erstmals wirksam?
• Welche Abhängigkeiten bestehen zu Active Directory, Intune, Security-Produkten oder anderen Infrastrukturkomponenten?

Damit verschiebt sich auch die Bedeutung von Pilotgruppen und gestaffelten Rollouts. Getestet wird nicht lediglich ein neues Softwarepaket. Getestet wird der neue Zustand, der aus Betriebssystem, vorhandenen Komponenten, Richtlinien und Infrastruktur entsteht.

Das eigentliche Risiko liegt im Zusammenspiel

Machine Identity Isolation ist dabei kein Argument gegen Continuous Innovation oder Enablement Packages. Ebenso wenig zeigt der Fall, dass kleine Updates grundsätzlich riskanter wären als klassische Feature Updates. Er zeigt etwas anderes. Je stärker Microsoft Auslieferung, Aktivierung und Konfiguration voneinander trennt, desto weniger lässt sich die Tragweite eines Updates anhand seiner sichtbaren Größe beurteilen.

Das verändert auch die Aufgabe von IT-Abteilungen. Sie müssen nicht mehr nur fragen: ‚Was installiert Microsoft mit diesem Update?‘ Mindestens ebenso wichtig wird: ‚Was verändert sich dadurch am Zustand unserer Windows-Systeme?‘ Damit bekommt der unspektakuläre Wechsel auf Windows 11 26H2 eine ganz andere Bedeutung. Hinter einem kleinen Enablement Package kann eine Plattform stehen, deren Komponenten bereits vorbereitet sind und deren Verhalten sich mit einem Versionswechsel neu zusammensetzt. Klein ist dann nur noch das Paket – nicht zwangsläufig die Veränderung.

Was das neue Windows-Modell für Unternehmen bedeutet

Über viele Jahre ließ sich Windows-Management vergleichsweise klar an Versionswechseln ausrichten. Eine neue Windows-Version erschien, Unternehmen testeten Anwendungen und Treiber, definierten einen Rollout und brachten anschließend möglichst viele Systeme auf einen einheitlichen Stand. Selbst unter Windows 10 blieb dieses Denken zunächst erhalten. Die Abstände zwischen den Releases wurden kürzer, doch Feature Updates bildeten weiterhin gut erkennbare Zeitpunkte für umfangreichere Veränderungen.

Continuous Innovation, Controlled Feature Rollouts und Enablement Packages verändern diese Logik. Neue Funktionen können heute mit monatlichen Updates auf Systeme gelangen, zunächst inaktiv bleiben und später freigeschaltet werden. Andere Veränderungen erreichen Geräte schrittweise über kontrollierte Rollouts. Gleichzeitig markieren Feature Updates weiterhin neue Support- und Lifecycle-Stände. Damit verteilen sich technische Veränderungen auf mehrere Zeitpunkte.

Für Unternehmen entsteht daraus eine zentrale Konsequenz: Wer Windows nur vor dem jährlichen Feature Update testet, testet Windows zunehmend zum falschen Zeitpunkt. Modernes Windows-Management muss deshalb nicht nur Versionswechsel beherrschen. Es muss kontinuierliche Veränderung kontrollierbar machen.

Deployment-Ringe werden zum dauerhaften Frühwarnsystem

Gestaffelte Rollouts sind kein neues Konzept. Im heutigen Windows-Modell verändert sich jedoch ihre Bedeutung. Deployment-Ringe dienen nicht mehr nur dazu, ein großes Feature Update kontrolliert von einer kleinen Pilotgruppe bis in die breite Produktivumgebung zu verteilen. Entscheidend ist deshalb weniger die Anzahl der Ringe als deren Zusammensetzung. Gerade die frühen Gruppen müssen Unterschiede der tatsächlichen Windows-Landschaft abbilden: verschiedene Hardwaregenerationen und Gerätetypen, geschäftskritische Anwendungen, spezielle Treiber und Peripheriegeräte, VPN-Clients, Security-Produkte sowie unterschiedliche Benutzerprofile. Nur dann können diese Systeme ihre eigentliche Aufgabe erfüllen: Probleme sichtbar machen, bevor eine Veränderung die breite Produktivumgebung erreicht.

Damit werden Deployment-Ringe zu einem dauerhaften Beobachtungs- und Steuerungsmechanismus. Monitoring und Telemetrie liefern Informationen über Gerätezustand, Fehler und Kompatibilitätsprobleme. Diese Erkenntnisse fließen in die Bewertung des Rollouts ein. Bei Auffälligkeiten lässt sich die weitere Bereitstellung anhalten oder anpassen, bevor die nächste Gruppe erreicht wird. Vor allem aber endet dieser Prozess nicht mehr mit dem Wechsel von 25H2 auf 26H2. Quality Updates, Feature Updates und schrittweise aktivierte Funktionen können dieselben kontrollierten Wege durch die Windows-Landschaft nehmen.

Aus einem klassischen Deployment-Prozess entsteht damit ein kontinuierlicher Feedback-Loop aus Bereitstellen, Beobachten, Bewerten und Steuern. Die entscheidende Frage lautet deshalb nicht mehr ausschließlich: ‚Wie verteilen wir eine neue Windows-Version?‘, sondern zunehmend: ‚Wie lassen wir Veränderungen kontrolliert durch unsere Windows-Landschaft wandern?‘

Update- und Release-Management wachsen zusammen

Damit verschwimmen auch die Grenzen zwischen klassischem Patch- und Release-Management. Sicherheitsupdates müssen weiterhin zeitnah verteilt werden. Gleichzeitig können monatliche Updates Änderungen enthalten, die über reine Fehlerkorrekturen hinausgehen. Funktionen können vorbereitet, bestehende Komponenten verändert oder Voraussetzungen für spätere Aktivierungen geschaffen werden. Das Release-Management darf deshalb nicht erst beginnen, wenn Microsoft ein neues Feature Update veröffentlicht.

Unternehmen benötigen vielmehr einen kontinuierlichen Prozess, der unterschiedliche Arten von Veränderungen bewertet: sicherheitskritische Aktualisierungen, Qualitätsverbesserungen, neue Funktionen, kontrollierte Rollouts und schließlich neue Windows-Versionen. Dabei geht es nicht darum, jede Änderung monatelang in einem Testlabor festzuhalten. Ein solcher Ansatz würde dem Sicherheitsbedarf moderner Systeme widersprechen. Vielmehr müssen Unternehmen festlegen, welche Veränderungen wie lange kontrolliert werden dürfen und welche aufgrund ihrer Kritikalität schnell ausgerollt werden müssen. Modernes Update-Management wird damit zu einer Balance aus Geschwindigkeit und Kontrolle.

Intune und Gruppenrichtlinien steuern mehr als Einstellungen

Gleichzeitig wächst die Bedeutung zentraler Richtlinien. Microsoft Intune und klassische Gruppenrichtlinien bestimmen längst nicht mehr nur, welches Hintergrundbild angezeigt wird oder welche Einstellungen Benutzer:innen verändern dürfen. Policies können Sicherheitsfunktionen aktivieren, Rollouts beeinflussen und darüber entscheiden, wie sich bereits vorhandene Komponenten verhalten.

Der Fall Machine Identity Isolation aus dem vorherigen Kapitel zeigt, warum das relevant ist. Eine Richtlinie kann bereits auf einem System vorhanden sein, bevor ein späterer Windows-Stand ihre Wirkung verändert oder überhaupt berücksichtigt. Damit wird die Konfiguration selbst zu einem Bestandteil des Release-Managements. Vor einem größeren Versionswechsel reicht es deshalb nicht aus, lediglich den neuen Windows-Build zu betrachten.

Administrator:innen müssen ebenso wissen:

• Welche Richtlinien sind aktuell konfiguriert?
• Welche Funktionen beeinflussen sie?
• Ändert Microsoft deren Verhalten mit einem Update?
• Welche alten Einstellungen sind möglicherweise noch auf Geräten vorhanden?

Damit werden Policy-Inventarisierung und Policy-Lifecycle zu wichtigen Bestandteilen eines modernen Windows-Betriebs.

Security Baselines sind kein einmaliges Projekt

Ähnliches gilt für Security Baselines. Eine einmal definierte Sicherheitskonfiguration kann nicht automatisch über Jahre unverändert bestehen bleiben. Windows entwickelt neue Schutzmechanismen, verändert Standardeinstellungen und entfernt oder ersetzt ältere Technologien. Administrator Protection ist dafür ein gutes Beispiel. Neue Sicherheitsfunktionen können das bisherige Modell administrativer Rechte grundlegend verändern. Unternehmen müssen deshalb prüfen, ob bestehende Baselines weiterhin zur aktuellen Plattform passen.

Dabei gilt jedoch nicht automatisch: neuer ist gleich besser für jede Umgebung. Sicherheitsfunktionen besitzen technische Voraussetzungen und können Auswirkungen auf Anwendungen, Administrationsprozesse oder vorhandene Infrastruktur haben. Eine neue Baseline sollte deshalb ebenso getestet werden wie andere Änderungen an der Plattform. Security Baselines werden damit selbst Teil eines kontinuierlichen Lifecycle. Windows verändert seine Sicherheitsarchitektur – und die Sicherheitskonfiguration eines Unternehmens muss sich kontrolliert mit ihr weiterentwickeln.

Anwendungen und Treiber bleiben der entscheidende Praxistest

Bei aller Veränderung bleibt eine klassische Aufgabe bestehen: Anwendungen und Treiber müssen weiterhin funktionieren. Allerdings verändert sich auch hier der Zeitpunkt des Testens. Wenn relevante Änderungen bereits mit monatlichen Updates eintreffen können, reicht ein großer Kompatibilitätstest kurz vor dem jährlichen Feature Update nicht mehr aus. Besonders geschäftskritische Anwendungen sollten kontinuierlich gegen die Windows-Stände getestet werden, die sich durch die Deployment-Ringe bewegen.

Dabei müssen Unternehmen nicht zwangsläufig jede Anwendung jeden Monat vollständig manuell prüfen. Automatisierte Tests, Telemetrie, Helpdesk-Daten und gezielte Pilotgruppen können helfen, Auffälligkeiten früh zu erkennen. Besonders wichtig bleiben Systeme mit spezieller Hardware, älteren Treibern oder Anwendungen, die tief in Windows eingreifen. Denn gerade dort kann eine scheinbar kleine Plattformänderung unerwartete Auswirkungen besitzen. Der Testgegenstand ist deshalb zunehmend nicht mehr nur Windows 11 26H2. Er lautet vielmehr: Unsere Anwendungen, unsere Treiber und unsere Konfiguration auf dem jeweils aktuellen Zustand der Windows-Plattform.

Controlled Feature Rollouts verändern die Planbarkeit

Eine zusätzliche Herausforderung entsteht durch Controlled Feature Rollouts. Nicht jede neue Funktion erreicht alle Geräte gleichzeitig. Microsoft kann Funktionen schrittweise für bestimmte Gruppen freigeben und den Rollout anhand der gewonnenen Erkenntnisse erweitern oder anpassen. Aus Sicht Microsofts reduziert dieses Verfahren das Risiko eines flächendeckenden Problems. Für Unternehmen entsteht jedoch eine neue Herausforderung: Zwei nominell ähnlich aktualisierte Systeme müssen nicht zwangsläufig exakt denselben Funktionsumfang besitzen.

Versionsnummer und Patchstand erzählen damit nicht mehr immer die gesamte Geschichte. Für Support und Troubleshooting wird deshalb wichtiger, den tatsächlichen Zustand eines betroffenen Systems zu kennen. Administrator:innen müssen gegebenenfalls nicht nur fragen, welcher Build installiert ist, sondern auch, welche Funktionen auf diesem Gerät bereits aktiviert wurden. Controlled Feature Rollouts erhöhen damit die Möglichkeit einer kontrollierten Einführung – gleichzeitig reduzieren sie die Einfachheit eines vollständig homogenen Windows-Zustands.

Change Management beginnt vor der sichtbaren Veränderung

Diese technische Entwicklung hat auch organisatorische Folgen. Eine neue Funktion kann Benutzer:innen erreichen, ohne dass zuvor ein klassisches Feature Update mit entsprechend hoher Aufmerksamkeit stattgefunden hat. Dadurch wächst die Bedeutung eines kontinuierlichen Change Managements. Nicht jede kleine Änderung benötigt eine unternehmensweite Kommunikationskampagne. Änderungen an Anmeldung, Sicherheitsdialogen, Explorer, Startmenü oder administrativen Abläufen können jedoch unmittelbar Supportanfragen erzeugen.

IT-Abteilungen müssen deshalb früher entscheiden, welche Änderungen lediglich technisch getestet und welche zusätzlich kommunikativ begleitet werden sollten. Das gilt besonders dann, wenn eine Veränderung zwar technisch klein erscheint, aber einen vertrauten Arbeitsablauf verändert. Continuous Innovation bedeutet deshalb nicht nur Continuous Deployment. Für Unternehmen bedeutet es in gewissem Umfang auch Continuous Change Management.

Der Lifecycle bleibt der feste Rahmen

Bei all dieser kontinuierlichen Veränderung verliert das Feature Update dennoch nicht seine Bedeutung. Mit einer neuen Windows-Version beginnt weiterhin ein neuer Support-Lifecycle. Für Unternehmen bleibt deshalb entscheidend, welche Versionen eingesetzt werden, wie lange Microsoft sie unterstützt und wann der Wechsel auf einen neueren Stand erfolgen muss.

Genau darin liegt die neue Doppelrolle des Feature Updates. Es ist immer weniger der einzige Zeitpunkt, zu dem Windows neue Funktionen erhält. Gleichzeitig bleibt es ein wichtiger Lifecycle-Marker für den unterstützten Zustand der Plattform. Unternehmen müssen deshalb zwei Zeithorizonte gleichzeitig beherrschen: den kontinuierlichen Strom aus Updates und Funktionsänderungen – und die längerfristige Planung unterstützter Windows-Versionen. Das eine ersetzt das andere nicht.

Aus Release-Management wird Plattform-Management

Windows 11 26H2 zeigt damit, dass sich nicht nur Microsofts Entwicklungsmodell verändert. Auch Unternehmen müssen ihre Vorstellung davon anpassen, was es bedeutet, Windows zu betreiben. Deployment-Ringe, Richtlinien, Security Baselines, Kompatibilitätstests und Change Management sind keine voneinander getrennten Aufgaben. Sie greifen zunehmend ineinander. Der gemeinsame Nenner ist der Zustand der Plattform.

Unternehmen müssen wissen, welche Windows-Version eingesetzt wird, welche Updates installiert sind, welche Funktionen aktiviert wurden, welche Policies wirken und welche Abhängigkeiten zur eigenen Infrastruktur bestehen. Damit verschiebt sich die Perspektive erneut. Die zentrale Frage lautet nicht mehr ausschließlich: ‚Wann rollen wir die nächste Windows-Version aus?‘, sondern: Wie halten wir eine sich kontinuierlich verändernde Windows-Plattform kontrolliert, sicher und nachvollziehbar? Genau deshalb gilt für modernes Windows-Management mehr denn je: Wer Windows nur vor dem jährlichen Feature Update testet, testet Windows zunehmend zum falschen Zeitpunkt.

Was ist heute eigentlich eine Windows-Version?

Windows 95, Windows XP oder Windows 7 ließen sich vergleichsweise einfach als eigenständige Windows-Versionen begreifen. Eine neue Version erschien, wurde installiert und ersetzte irgendwann ihren Vorgänger. Doch dieses vertraute Verständnis reicht für das heutige Windows kaum noch aus. Genau diese Entwicklung begleitet uns inzwischen durch eine ganze Reihe von Beiträgen in diesem Blog.

Beim Übergang von Windows 10 zu Windows 11 haben wir betrachtet, wie sich Releasezyklen, Supportmodelle und Hardwareanforderungen verändern. Der Blick auf Windows 11 im Modern Workplace hat anschließend gezeigt, dass sich ein moderner Windows-Arbeitsplatz nicht mehr allein über das Betriebssystem definiert. Identität, Geräteverwaltung, Richtlinien und Cloud-Dienste sind ebenso Teil dieser Plattform. Mit den Copilot+ PCs kam eine weitere Ebene hinzu: Neue Prozessorarchitekturen und NPUs verzahnen Hardware und Windows enger mit lokalen KI-Funktionen. Der Beitrag zu Windows 11 26H1 führte diese Entwicklung schließlich bis zu einem Windows-Zweig weiter, dessen Versionsnummer nicht primär ein klassisches Feature Update, sondern eine neue technische Plattform für kommende Hardware beschreibt.

Parallel haben wir im Beitrag Windows im Wandel: Von Bare Metal bis Cloud Management verfolgt, wie sich auch Installation, Updates und Verwaltung verändern: vom individuell erzeugten Betriebssystem-Image hin zu Provisioning, Identität und cloudgestütztem Management. Und schließlich stand bereits die Frage im Raum, ob nach Windows 11 überhaupt noch ein klassisches Windows 12 folgen muss – oder ob Microsoft Windows zunehmend als kontinuierlich weiterentwickelte Plattform versteht.

Windows 11 26H2 führt diese bislang getrennt betrachteten Entwicklungslinien zusammen. Denn die Versionsnummer beschreibt heute nicht mehr zwangsläufig ein neues Betriebssystem im klassischen Sinne. Sie kann einen Architekturzweig kennzeichnen, einen Servicing-Stand markieren, Funktionen aktivieren und einen neuen Lifecycle beginnen. Die scheinbar einfache Frage ‚Welche Windows-Version ist installiert?‘ besitzt deshalb weiterhin eine eindeutige technische Antwort. Nur sagt diese Antwort längst nicht mehr alles darüber aus, welches Windows tatsächlich vor uns steht.

Windows 11: Aus dem Service wird eine kontinuierliche Plattform

Windows 11 führt das mit Windows 10 begonnene Servicing-Modell weiter, verändert aber dessen Mechanik. Continuous Innovation, monatliche Updates und Controlled Feature Rollouts verteilen neue Funktionen zunehmend über das gesamte Jahr. Programmcode kann bereits auf einem Rechner vorhanden sein, bevor Microsoft die zugehörige Funktion aktiviert. Ein späteres Enablement Package kann schließlich einen neuen Versionsstand freischalten, ohne das Betriebssystem vollständig neu installieren zu müssen. Damit verliert das Feature Update sein früheres Feature-Monopol.

Diese Entwicklung haben wir bereits im Beitrag Windows 12, Windows 11 26H1 und die Zukunft von Windows aus einer anderen Perspektive betrachtet. Dort stand die Frage im Mittelpunkt, ob Microsoft überhaupt noch einen klassischen Versionssprung zu einem Windows 12 benötigt – oder ob Windows 11 zunehmend zur langfristig weiterentwickelten Plattform wird. 26H2 macht dieses Plattformmodell nun praktisch greifbar.

Die Windows-Version verschwindet dadurch keineswegs. Ihre Bedeutung verändert sich jedoch. Sie beschreibt zunehmend einen definierten Zustand innerhalb einer Plattform, die sich auch zwischen den großen Versionswechseln weiterentwickelt. Das erklärt zugleich die eingangs geschilderte Erfahrung beim Wechsel von 25H2 auf 26H2: Ein neuer Versionsstand muss nicht mehr mit einem sichtbar neuen Windows einhergehen. Eine neue Windows-Version kann heute weniger ein neues Produkt als ein neuer definierter Zustand derselben Plattform sein.

Modern Workplace: Windows endet nicht mehr am Betriebssystem

Parallel verändert sich eine zweite Grenze: die zwischen Betriebssystem und Arbeitsplatz. Im Beitrag Windows 11 im Modern Workplace – Identität, Geräteverwaltung und Sicherheit mit Entra ID und Intune haben wir bereits betrachtet, dass sich ein moderner Windows-Arbeitsplatz nicht mehr allein über das lokal installierte Betriebssystem definiert. Identität, Gerät, Richtlinien und Cloud-Dienste greifen zunehmend ineinander.

Microsoft Entra ID verbindet Benutzer:innen und Geräte mit der Organisation. Intune liefert Konfigurationen, Anwendungen und Sicherheitsrichtlinien. Microsoft 365 stellt Dienste und Daten bereit. Der konkrete Arbeitsplatz entsteht damit aus dem Zusammenspiel einer vorhandenen Windows-Plattform mit der jeweiligen organisatorischen Identität und Verwaltung.

Parallel verändert sich auch die Bereitstellung dieses Arbeitsplatzes. Wie im Beitrag Windows im Wandel: Von Bare Metal bis Cloud Management – Wie sich Installation, Updates und Verwaltung verändert haben betrachtet, führt der Weg zunehmend von individuell erzeugten Betriebssystem-Images zum cloudgestützten Provisioning. Ein Rechner kann mit einem weitgehend standardisierten Windows ausgeliefert werden und erhält seinen konkreten Unternehmenszustand anschließend über Identität, Richtlinien, Anwendungen und Management.

Damit verändert sich auch die Aussagekraft einer Versionsnummer. Zu wissen, dass ein Rechner Windows 11 26H2 ausführt, beantwortet noch nicht, welches Windows die Benutzer:innen tatsächlich vorfinden. Entscheidend ist ebenso, welche Policies wirken, welche Sicherheitsfunktionen aktiviert sind, welche Anwendungen bereitgestellt werden und mit welchen Cloud-Diensten das Gerät verbunden ist. Die Windows-Version bleibt damit eine wichtige technische Information – sie ist aber nur noch eine Ebene des tatsächlichen Gerätezustands.

Copilot+ PC: Wenn auch die Hardware Teil der Plattform wird

Mit den Copilot+ PCs kommt eine weitere Ebene hinzu: die Hardware selbst. Im Beitrag Windows 11 und die Herausforderungen an die Hardware – Was Copilot+ PCs verändern haben wir betrachtet, wie Microsoft mit dieser Geräteklasse neue Anforderungen an Prozessoren, Arbeitsspeicher und insbesondere die lokale KI-Beschleunigung definiert. Die Neural Processing Unit, kurz NPU, wird damit zu einer weiteren spezialisierten Rechenressource, die Windows erkennen, verwalten und Anwendungen zur Verfügung stellen muss. Dadurch erweitert sich erneut unser Verständnis einer Windows-Plattform.

Nach Betriebssystem, Servicing, Identität und Management gewinnt nun auch die zugrunde liegende Hardwarearchitektur stärker an Bedeutung. Prozessor, NPU, Treiber, Sicherheitsfunktionen, lokale KI-Verarbeitung und Cloud-Dienste bilden gemeinsam die technische Grundlage für Funktionen, die sich nicht mehr unabhängig voneinander betrachten lassen. Damit bekommt auch die Frage nach einer Windows-Version eine zusätzliche Dimension. Wenn neue Hardwaregenerationen andere technische Grundlagen im Betriebssystem benötigen, muss die Windows-Entwicklung nicht zwangsläufig auf einer einzigen linearen Versionsfolge stattfinden. Unterschiedliche Gerätegenerationen können unterschiedliche Plattformzweige benötigen, obwohl sie weiterhin unter demselben Produktnamen Windows 11 erscheinen.

Genau an diesem Punkt wird Windows 11 26H1 besonders interessant. Denn dort wird aus der Verbindung von Windows und neuer Hardware schließlich eine neue Bedeutung der Versionsnummer selbst.

26H1: Die Versionsnummer wird zum Architekturzweig

Genau diese Entwicklung zeigt sich bei Windows 11 26H1. Im Beitrag Windows 11 26H1 im Überblick: Architekturwandel, KI-Hardware und die Zukunft von Windows haben wir ausführlich betrachtet, warum 26H1 trotz seiner Bezeichnung nicht einfach der zeitliche Vorgänger von 26H2 ist. Microsoft entwickelte diesen Windows-Zweig für neue Hardwareplattformen und die dafür notwendigen Änderungen am Betriebssystem. Für bestehende 25H2-Systeme ist 26H1 dagegen kein reguläres Feature Update.

Damit bekommt die Versionsnummer eine neue Bedeutung: Sie kann einen technischen Architekturzweig innerhalb der Windows-Entwicklung kennzeichnen. Das widerspricht unserem über Jahre erlernten Verständnis einer Versionsfolge. Wer 26H1 liest, erwartet intuitiv, dass anschließend 26H2 folgt und derselbe Rechner beide Stationen nacheinander durchläuft. Genau das muss heute nicht mehr gelten. Die Versionsbezeichnung beschreibt damit nicht mehr ausschließlich die Position eines Betriebssystems auf einer zeitlichen Achse. Sie kann ebenso anzeigen, auf welcher technischen Entwicklungsgrundlage ein Windows-System basiert.

26H1 macht damit besonders deutlich, wie wenig die klassische Vorstellung einer Windows-Version inzwischen ausreicht. Denn erstmals müssen wir bei einer Windows-11-Versionsnummer nicht nur fragen: ‚Wann ist diese Version erschienen?‘, sondern ebenso: ‚Für welche technische Plattform ist diese Version eigentlich bestimmt?‘

26H2: Version als Servicing-, Aktivierungs- und Lifecycle-Meilenstein

Windows 11 26H2 zeigt die andere Seite dieses neuen Versionsmodells. Während 26H1 einen eigenen Architekturzweig für neue Hardwareplattformen kennzeichnet, steht 26H2 in der gemeinsamen Entwicklungslinie von 24H2 und 25H2. Diese Versionen teilen sich eine Servicing-Grundlage und werden über die laufende Windows-Wartung kontinuierlich weiterentwickelt. Neue Komponenten können deshalb bereits über monatliche Updates auf einen Rechner gelangen und dort zunächst inaktiv bleiben. Das Enablement Package aktiviert anschließend den vorgesehenen Funktionsstand und macht aus einem entsprechend vorbereiteten System Windows 11 26H2.

Die Versionsnummer erfüllt damit mehrere Aufgaben gleichzeitig. Sie kennzeichnet einen definierten Servicing-Stand innerhalb einer kontinuierlich gepflegten Plattform. Sie markiert einen Aktivierungszustand, bei dem bereits vorhandene Funktionen für die neue Version freigeschaltet werden. Und sie eröffnet einen neuen Lifecycle, an dem sich Unternehmen bei Support, Deployment und Migrationsplanung orientieren können.

Damit stehen 26H1 und 26H2 für zwei unterschiedliche Bedeutungen einer Windows-Version. Bei 26H1 lautet die entscheidende Frage: ‚Für welche technische Plattform ist diese Version bestimmt?‘ Bei 26H2 dagegen: ‚Welchen definierten Zustand hat die kontinuierlich weiterentwickelte Windows-Plattform erreicht?‘ Beide Versionen tragen die Jahreszahl 2026. Beide heißen Windows 11. Und dennoch beschreiben ihre Versionsnummern unterschiedliche technische Zusammenhänge. Gerade diese Gegenüberstellung zeigt, wie grundlegend sich verändert hat, was eine Windows-Version heute überhaupt bedeutet.

Von der Versionsnummer zum Plattformzustand

Führen wir die Entwicklungslinien der vergangenen Beiträge zusammen, entsteht ein deutlich anderes Bild von Windows als noch vor einigen Jahren. Mit Windows 10 veränderte sich zunächst der Releasezyklus. Unter Windows 11 löste Microsoft die Weiterentwicklung stärker vom einzelnen Feature Update. Im Modern Workplace erweiterten Identität und cloudgestütztes Management den Windows-Arbeitsplatz über das lokal installierte Betriebssystem hinaus. Mit den Copilot+ PCs gewann schließlich auch die Hardwareplattform mit Prozessorarchitektur, NPU und lokaler KI-Verarbeitung zusätzlich an Bedeutung.

Windows 11 26H1 und 26H2 führen diese Entwicklung an einen Punkt, an dem selbst die Versionsnummer nicht mehr zwangsläufig dieselbe technische Aussage besitzt. 26H1 kennzeichnet einen Architekturzweig für neue Hardwareplattformen. 26H2 beschreibt dagegen einen definierten Servicing-, Aktivierungs- und Lifecycle-Zustand innerhalb der gemeinsamen Entwicklungslinie von 24H2, 25H2 und 26H2.

Die Abbildung macht deshalb bewusst keine einfache Versionsfolge aus 26H1 und 26H2. Beide tragen dieselbe Jahreszahl und gehören zu Windows 11, erfüllen innerhalb der Windows-Entwicklung jedoch unterschiedliche Aufgaben. Gleichzeitig zeigt die Servicing-Linie von 24H2 über 25H2 zu 26H2, warum auch ein kleines Enablement Package einen neuen definierten Plattformzustand markieren kann. Quality Updates können Komponenten bereits vorbereiten, Funktionen zunächst inaktiv bleiben und anschließend kontrolliert oder mit einem Enablement Package freigeschaltet werden.

Versionsnummern werden dadurch keineswegs bedeutungslos. Für Support, Lifecycle, Compliance und Verwaltung bleiben sie wichtige technische Informationen. Nur dürfen wir aus einer Versionsnummer nicht mehr automatisch ableiten, dass sie ein vollständig neues und klar abgegrenztes Betriebssystem beschreibt. Die Versionsnummer wird zunehmend zu einer Koordinate innerhalb einer sich kontinuierlich verändernden Windows-Plattform. Und wie bei jeder Koordinate benötigen wir weitere Angaben, um ihre tatsächliche Position einordnen zu können. Erst Architektur, Build, Servicing-Stand, aktivierte Funktionen, Hardware und Managementkontext zeigen, welches Windows sich tatsächlich hinter dieser Koordinate befindet.

‚Welche Windows-Version?‘ reicht nicht mehr

Damit verändert sich schließlich auch eine der ältesten Fragen im IT-Support: Welche Windows-Version ist installiert? Die Antwort bleibt wichtig. Sie reicht jedoch immer seltener aus, um den tatsächlichen Zustand eines Windows-Systems zu beschreiben.

Welcher Build und welche Updates sind installiert? Welche Funktionen wurden bereits aktiviert? Welche Richtlinien wirken auf dem Gerät? Welche Sicherheitsmechanismen sind eingeschaltet? Auf welcher Hardwareplattform läuft Windows? Wie wird das Gerät verwaltet? Und in welchem Lifecycle befindet sich dieser konkrete Stand? Die Versionsnummer liefert damit weiterhin eine wichtige Koordinate. Erst die weiteren Informationen zeigen jedoch, welcher technische Plattformzustand sich tatsächlich dahinter verbirgt.

Genau an diesem Punkt laufen die Entwicklungslinien der vergangenen Windows-Beiträge zusammen. Von Windows 10 und Windows as a Service über Windows 11 und den Modern Workplace bis zu Copilot+ PCs, 26H1 und 26H2 hat sich Windows nicht einfach von einer Version zur nächsten entwickelt. Verändert hat sich vielmehr, was eine Windows-Version überhaupt beschreibt. Früher stand sie weitgehend für einen klar abgegrenzten Stand des Betriebssystems. Heute ist sie Teil eines Zusammenspiels aus Architektur, Hardware, Build, Servicing, aktivierten Funktionen, Identität, Richtlinien, Cloud-Diensten, Management und Lifecycle.

Und vielleicht erklärt genau das am besten, warum sich der Wechsel von Windows 11 25H2 auf 26H2 am Anfang dieses Beitrags so unspektakulär anfühlte. Nicht, weil sich Windows nicht mehr verändert. Sondern weil sich Windows inzwischen anders verändert, als wir es jahrzehntelang von einer neuen Windows-Version erwartet haben.

Windows verändert sich – nur nicht mehr auf einen Schlag

Am Anfang dieses Beitrags stand ein erstaunlich unspektakulärer Vorgang: Windows 11 25H2. Windows Update. Ein kleines Enablement Package. Neustart. Windows 11 26H2. Danach erscheint der vertraute Desktop. Die Anwendungen sind noch da, wo sie vorher waren. Startmenü, Taskleiste und Datei-Explorer sehen weitgehend vertraut aus. Kein neues Windows-Erlebnis begrüßt die Benutzer:innen und kaum etwas vermittelt das Gefühl, gerade eine neue Betriebssystemversion installiert zu haben.

Nach allem, was wir inzwischen betrachtet haben, erscheint genau diese Ereignislosigkeit in einem anderen Licht. Denn Windows 11 26H2 ist nicht deshalb interessant, weil Microsoft mit diesem Feature Update möglichst viele sichtbare Neuerungen ausliefert. Es ist interessant, weil sich daran erkennen lässt, wie sehr sich die Weiterentwicklung von Windows selbst verändert hat. Was früher in einem großen Versionswechsel gebündelt wurde, verteilt sich heute auf monatliche Updates, Controlled Feature Rollouts, Enablement Packages und unterschiedliche Architekturzweige. Der Versionswechsel ist nur noch ein Teil dieser Entwicklung.

Windows verändert sich zwischen den Versionen

Continuous Innovation hat den klassischen Release-Zeitpunkt entmachtet. Neue Funktionen können heute auf einem Rechner eintreffen, bevor eine neue Windows-Version erscheint. Sie können zunächst inaktiv bleiben und später freigeschaltet werden. Andere Funktionen erreichen Systeme über kontrollierte Rollouts. Ein Enablement Package aktiviert schließlich einen neuen definierten Plattformzustand und eröffnet zugleich einen neuen Lifecycle.

Damit verändert sich Windows nicht mehr hauptsächlich von Version zu Version. Windows verändert sich zunehmend zwischen den Versionen. 26H2 macht diesen Wandel besonders sichtbar, gerade weil das eigentliche Upgrade so wenig spektakulär ausfallen kann. Das Feature Update verschwindet dadurch nicht. Es bekommt lediglich eine andere Aufgabe. Es ist weniger der große Container für sämtliche Neuerungen und zunehmend ein Meilenstein innerhalb einer kontinuierlich weiterentwickelten Plattform.

Kleine Updates können große Veränderungen bedeuten

Gleichzeitig haben wir gesehen, warum ein unspektakulärer Installationsvorgang nicht mit einer unbedeutenden technischen Veränderung verwechselt werden darf. Machine Identity Isolation liefert dafür ein besonders anschauliches Beispiel. Programmcode kann bereits vorhanden sein. Richtlinien können bereits konfiguriert sein. Ein späterer Versions- oder Updatestand verändert schließlich, wie Windows diese vorhandenen Komponenten miteinander verbindet.

Deshalb gilt: Das Enablement Package mag klein sein. Die Zustandsänderung, die es auslöst, muss es nicht sein. Für Unternehmen verändert sich damit auch das Testen von Windows. Deployment-Ringe, Richtlinien, Security Baselines, Applikations- und Treibertests sowie Change Management müssen eine Plattform begleiten, deren Veränderung nicht mehr ausschließlich an einem jährlichen Release-Termin stattfindet. Oder anders formuliert: Wer Windows nur vor dem jährlichen Feature Update testet, testet Windows zunehmend zum falschen Zeitpunkt.

Auch die unsichtbaren Veränderungen zählen

26H2 zeigt außerdem, dass Weiterentwicklung nicht zwangsläufig durch ein neues Startmenü oder eine spektakuläre Anwendung sichtbar werden muss. Microsoft arbeitet an Performance, Zuverlässigkeit und handwerklicher Qualität. Administrative Privilegien sollen stärker isoliert und nur bei Bedarf bereitgestellt werden. Sysmon wandert vom zusätzlichen Sysinternals-Werkzeug in die Windows-Plattform. Recovery, Telemetrie und moderne Hardwareunterstützung entwickeln sich weiter. Gleichzeitig verschwinden ältere Komponenten wie WMIC.

Manche dieser Veränderungen werden Benutzer:innen unmittelbar bemerken. Andere entfalten ihre Bedeutung erst für Administrator, Security-Teams oder Entwickler. Gerade darin zeigt sich jedoch ein gereifterer Blick auf ein Betriebssystem. Ein gutes Windows muss nicht bei jedem Feature Update anders aussehen. Es muss zuverlässig funktionieren, aktuelle Hardware unterstützen, Angriffsflächen reduzieren, verwaltbar bleiben und gleichzeitig jahrzehntelange Kompatibilitätsanforderungen bewältigen. Weiterentwicklung muss nicht immer sichtbar sein, um relevant zu sein.

Von der Windows-Version zur Windows-Plattform

Am Ende führt uns 26H2 deshalb zu einer wesentlich größeren Frage als der nach einzelnen neuen Funktionen: Was ist heute eigentlich eine Windows-Version? Windows 10 etablierte Windows as a Service. Windows 11 entwickelte daraus eine kontinuierlich gepflegte Plattform. Modern Workplace verband Betriebssystem, Identität, Gerät, Richtlinien und Cloud. Copilot+ PCs ergänzen spezialisierte Hardware und lokale KI-Beschleunigung. 26H1 zeigt schließlich, dass eine Versionsnummer sogar einen eigenen Architekturzweig kennzeichnen kann. 26H2 steht dagegen für einen definierten Servicing-, Aktivierungs- und Lifecycle-Zustand innerhalb einer bereits laufend veränderten Plattform.

Damit verliert die Versionsnummer nicht ihre Bedeutung. Aber sie erzählt nicht mehr die ganze Geschichte. Wer verstehen möchte, welches Windows tatsächlich vor einem steht, muss inzwischen tiefer schauen: auf Build und Updates, aktivierte Funktionen, Hardware, Richtlinien, Sicherheitskonfiguration, Management und Lifecycle.

Vielleicht war das unspektakuläre Update genau der Punkt

Und damit sind wir wieder bei dem Rechner, der nach seinem Neustart plötzlich Windows 11 26H2 ausführt. Auf dem Bildschirm hat sich kaum etwas verändert. Doch unter dieser vertrauten Oberfläche steht ein Windows, dessen Entwicklungsmodell mit dem klassischen Bild einer neuen Betriebssystemversion immer weniger gemeinsam hat. Vielleicht war deshalb meine erste Reaktion auf das Update die falsche Frage. Nicht: ‚Was ist denn jetzt eigentlich neu?‘, sondern: ‚Warum muss eine neue Windows-Version heute überhaupt noch sichtbar neu aussehen?‘

Windows 11 26H2 liefert darauf keine einzelne spektakuläre Antwort. Stattdessen zeigt es eine Plattform, die sich kontinuierlich verändert, Funktionen vorbereitet und aktiviert, neue Hardware integriert, Sicherheitsarchitekturen weiterentwickelt und gleichzeitig versucht, für Benutzer:innen möglichst vertraut zu bleiben. Und vielleicht ist genau das die wichtigste Neuerung von Windows 11 26H2: Nicht eine einzelne Funktion verändert Windows grundlegend, sondern die Art und Weise, wie Windows sich überhaupt verändert.

Quellenangaben

• (Abgerufen am 4. Oktober 2026)
  

  Microsoft: Windows 11 26H2, Servicing und Release-Modell

  • Microsoft Learn: What's new in Windows 11, version 26H2
  • Microsoft Learn: Windows 11 Insider Experimental (Future Platforms) Preview Build 29680.1000
  • Microsoft Learn: Windows 11, version 26H2 known issues and notifications
  • Microsoft: Windows 11, version 26H2 update history
  • Microsoft: Windows Roadmap
  • Pavan Davuluri (Microsoft): Our commitment to Windows quality
  • Stephen Lines (Microsoft): Releasing Windows 11, version 26H2 to the Release Preview Channel

  Microsoft Pluton und hardwaregestützte Sicherheit

  • David Weston (Microsoft): Microsoft präsentiert mit dem Pluton-Prozessor den Sicherheitschip für die Windows-PCs der Zukunft
  • Microsoft Learn: Microsoft Pluton security processor

  Marktanteile und Betriebssystem-Trends

  • Statcounter Global Stats: Desktop Operating System Market Share Worldwide
  • Procurri: Global OS Market Share 2025: Key Stats, Trends, and Insights for Mobile and Desktop
  • Christy Tila (Statista): Global market share held by operating systems for desktop PCs from January 2013 to June 2026
  • Statista: Market share of the leading operating systems in Germany from 2009 to 2025
  • Christy Tila (Statista): Monthly market share held by Windows operating system for desktop PCs worldwide from January 2017 to August 2026, by version
  • University of Wollongong: Understanding operating systems
  • Steam: Steam-Hard- & Softwareumfrage: September 2026

  Windows 11 26H2: Einordnung, Rollout und bekannte Probleme

  • Dirk Knop (Heise): Windows-Einstellungsbackup wird Standardoption in Windows 11 26H2
  • Günter Born (Borns IT- und Windows-Blog): Windows 11 26H2 freigegeben (29. Sept. 2026)
  • Günter Born (Borns IT- und Windows-Blog): Windows 11 26H2: Upgrade per Enablement Update KB5121794
  • Hans-Christian Dirscherl (PC-WELT): Microsoft warnt: Diese Anwender sollten Windows 11 26H2 vorerst nicht installieren
  • Joerg Geiger (CHIP): Neue Windows-11-Version: Umsteigen oder lieber noch warten?
  • Martin Geuß (Dr. Windows): Kommentar zu Windows 11 Version 26H2: Eine verpasste Gelegenheit
  • Marvin Fuhrmann (t3n): Windows-Update 26H2 ist da – und mit ihm drei fiese Bugs

  Zukunft von Windows, Plattformstrategie und Linux

  • Abhijith M B (Windows Latest): Google researcher explains why Windows NT "puts Linux to shame," and imagines an alternate history where it won
  • Abhijith M B (Windows Latest): Microsoft’s then-CEO called Linux a cancer, and now Windows 11 ships Linux containers with upgraded WSL
  • Chris Hoffman (PCMag): I Asked Microsoft About Windows 12. Here's What It Would (and Wouldn't) Say
  • Chris Hoffman (PCMag): I Saw the Future of Windows at Microsoft Build, and It's Unrecognizable
  • Der Standard: Open-Source-Experte: "Microsoft wird auf Linux am Desktop umsteigen"
  • Mikael Markander (Computerworld): Microsoft adds support for Linux containers in WSL
  • Zac Bowden (Windows Central): Windows 11 version 27H2: Microsoft's next major platform upgrade for the masses in 2027?

  Weitere Perspektiven und Community-Beiträge

  • Laurie Kirk (LinkedIn): Say what you will about Windows OS…
  • VS Tech (YouTube): Microsoft Is Slowly Turning Windows Into Linux — Here’s the Proof You Missed

  Weiterlesen hier im Blog

  • Von Windows 10 zu Windows 11: Copilot+ PCs, LTSC 2024 und was das Supportende 2025 bedeutet
  • Windows 11 26H1 im Überblick: Architekturwandel, KI-Hardware und die Zukunft von Windows
  • Windows 11 im Modern Workplace: Identität, Geräteverwaltung und Sicherheit mit Entra ID und Intune
  • Windows 11 und die Herausforderungen an die Hardware – Was Copilot+ PCs verändern
  • Windows 12, Windows 11 26H1 und die Zukunft von Windows: Plattform statt Versionssprung
  • Windows im Wandel: Von Bare Metal bis Cloud Management – Wie sich Installation, Updates und Verwaltung verändert haben