Wer in den letzten Monaten Tickets wie „Netzlaufwerk nicht erreichbar", „Freigabe plötzlich weg" oder „Storage-Einstellungen öffnen sich nicht mehr" auf dem Tisch hatte – herzlich willkommen im Club.
Was zunächst wie mysteriöse Bugs wirkte, ist der Beginn einer konsequenten, versionsübergreifenden Sicherheitsstrategie. Und wer den Trend versteht, wird künftige Ticket-Wellen sehr viel schneller einordnen können – und am besten gar nicht erst entstehen lassen.
Dieser Artikel richtet sich an Admins und Supporter, die den technischen Alltag kennen – aber auch an alle, die gegenüber Geschäftsführung, Datenschutzbeauftragten oder Auditoren erklären müssen, warum diese Änderungen nicht nur sinnvoll, sondern in vielen Fällen regulatorisch notwendig sind.
—
Der Rahmen: Microsoft Secure Future Initiative trifft Regulatorik
Alle nachfolgenden Änderungen folgen der Microsoft Secure Future Initiative (SFI) – einem unternehmensweiten Umbauprogramm als Reaktion auf staatlich gesponserte Angriffe und massiv gestiegene Ransomware-Aktivität. Die Kernaussage: Sicherheit muss der Default sein, nicht eine Experten-Option.
Was viele noch nicht auf dem Schirm haben: Diese technischen Defaults sind gleichzeitig direkte Antworten auf regulatorische Anforderungen, die längst gelten:
ISO 27001:2022 (Annex A, neu strukturiert mit 93 Controls in 4 Bereichen) fordert unter A.8.20 aktive Netzwerksicherheitskontrollen und unter A.8.5 sichere Authentifizierung als Pflicht – nicht als OptionDSGVO Art. 32 verlangt „geeignete technische Maßnahmen" zum Schutz personenbezogener Daten – unsigniertes SMB in einer Umgebung mit Personaldaten ist schwer als „geeignet" zu verteidigenNIS2-Richtlinie (seit Oktober 2024 in nationales Recht umgesetzt) fordert von betroffenen Einrichtungen nachweisbare technische Härtungsmaßnahmen für Netzwerke und AuthentifizierungBSI IT-Grundschutz (SYS.2.2 / NET.1.1) macht konkrete Vorgaben zu sicherer Netzwerkkommunikation, die mit unsigniertem SMB nicht erfüllt werden
Wer also Windows 11 24H2+ ausrollt und die Default-Härtungen beibehält, macht seine Umgebung nicht nur sicherer – er schließt gleichzeitig Lücken in seiner Compliance-Dokumentation.
—
24H2: Die SMB-Revolution – Technik, Diagnose und Compliance-Relevanz
SMB Signing ist jetzt Pflicht – für alle Verbindungen
Ab Windows 11 24H2 müssen alle SMB-Verbindungen signiert sein – standardmäßig, ohne zusätzliche Admin-Konfiguration. Früher galt das nur für SYSVOL, NETLOGON und Domänencontroller. Ältere NAS-Systeme, Linux-Samba-Server mit veralteten Konfigurationen, Industrie-PCs und Embedded-Geräte, die SMB ohne Signing sprechen – die werden schlicht abgeblockt.
Warum ist das richtig? SMB Signing blockiert NTLM-Relay-Angriffe: Ein Angreifer im Netzwerk fängt einen SMB-Handshake ab und authentifiziert sich damit gegenüber anderen Systemen. In Penetrationstests war das jahrelang einer der ersten Griffe nach dem initialen Foothold.
Compliance-Einordnung:
ISO 27001:2022 A.8.20 (Netzwerksicherheit): Aktive, risikoorientierte Kontrollen über alle Netzwerkgrenzen – unsigniertes SMB widerspricht diesem Control direktISO 27001:2022 A.8.5 (Sichere Authentifizierung): Authentifizierungsmechanismen müssen Integrität gewährleistenDSGVO Art. 32 Abs. 1 lit. b: Sicherstellung der dauerhaften Integrität der Verarbeitungssysteme – NTLM-Relay-Angriffe bedrohen genau diese IntegritätBSI IT-Grundschutz NET.1.1 (Netzarchitektur und -design): Kommunikation im Netz muss authentifiziert und integritätsgesichert sein
🔧 Diagnose und Sofortmaßnahmen:
Welche Verbindungen laufen signiert?
„` Get-SmbConnection | Select-Object ServerName, ShareName, Signed „`
Signing-Status auf dem Server prüfen:
„` Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature „`
Wer verbindet sich ohne Signing? Event ID 3000 im Eventlog (Microsoft → Windows → SMBServer → Security) liefert alle unsignierten Verbindungen – goldwert für die Bestandsaufnahme und als Nachweis gegenüber Auditoren.
GPO-Pfad für Signing-Pflicht auf Windows-Dateiservern:
„` Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Lokale Richtlinien → Sicherheitsoptionen → "Microsoft-Netzwerkserver: Kommunikation digital signieren (immer)" → Aktiviert „`
Samba-Konfiguration (smb.conf):
„` [global] server signing = mandatory „`
Temporäre Ausnahme per Registry (nur als Übergangslösung – im ISMS dokumentieren und befristen!):
„` HKLMSYSTEMCurrentControlSetServicesLanmanWorkstationParameters RequireSecuritySignature = 0 „`
—
Guest Fallback abgeschaltet
Windows verbindet sich nicht mehr stillschweigend als „Guest" mit Freigaben, wenn normale Credentials scheitern. Praktisch für Consumer-NAS – aber auch eine Einfallstür für Man-in-the-Middle-Angriffe.
Compliance-Einordnung:
ISO 27001:2022 A.8.3 (Einschränkung des Informationszugangs) und A.5.15 (Zugangssteuerung): Anonyme, unkontrollierte Verbindungen widersprechen dem Least-Privilege-Prinzip und sind in einem ISMS nicht dokumentierbarDSGVO Art. 25 (Datenschutz durch Technikgestaltung / Privacy by Design): Systeme müssen so konzipiert sein, dass standardmäßig nur notwendige Daten zugänglich sind – Guest-Zugang ist das GegenteilNIS2: Zugangskontrollen sind explizit gefordert; anonyme Netzwerkzugänge gelten als nicht konform
Guest-Anmeldungen im Eventlog aufspüren:
„` Microsoft-Windows-SMBClient/Security → Event ID 31017 „`
Guest-Fallback deaktivieren:
„` Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Confirm:$false „`
—
SMB über QUIC – Dateifreigaben ohne VPN
SMB läuft jetzt optional über QUIC mit TLS 1.3 statt klassischem TCP. Sichere Dateifreigaben direkt über das Internet, ohne VPN-Overhead – für Remote-Work-Szenarien und Zero-Trust-Architekturen.
Compliance-Einordnung:
ISO 27001:2022 A.8.24 (Einsatz von Kryptographie): TLS 1.3 als aktueller Kryptostandard entspricht den Anforderungen moderner ISMS-Kryptokonzepte direktBSI TR-02102 (Kryptographische Verfahren): TLS 1.3 mit aktuellen Cipher Suites ist empfohlen, ältere TLS-Versionen werden aktiv abgeraten
QUIC-Status prüfen:
„` Get-SmbServerConfiguration | Select-Object EnableSMBQUIC „`
—
Authentication Rate Limiter gegen Brute Force
Ein eingebauter Rate Limiter für SMB-Authentifizierungsversuche bremst Brute-Force-Angriffe massiv aus. Event ID 551 im SMBServer-Log zeigt geblockte Versuche – und ist gleichzeitig ein wertvolles Audit-Log.
Compliance-Einordnung:
ISO 27001:2022 A.8.5 (Sichere Authentifizierung): Schutz gegen Brute-Force-Angriffe ist explizit als Kontrollziel genanntBSI IT-Grundschutz ORP.4 (Identitäts- und Berechtigungsmanagement): Anmeldeversuche müssen begrenzt und protokolliert werden
Aktivieren und konfigurieren:
„` Set-SmbServerConfiguration -InvalidAuthenticationDelayTimeInMs 2000 -Confirm:$false „`
GPO-Pfad:
„` Computerkonfiguration → Administrative Vorlagen → Netzwerk → Lanman Server → "Enable authentication rate limiter" „`
—
Remote Mailslots deaktiviert
Ein uraltes Broadcast-Protokoll – standardmäßig deaktiviert. In modernen AD-Umgebungen nicht mehr benötigt, aber eine potenzielle Angriffsfläche. Die Deaktivierung entspricht dem Prinzip der Angriffsflächen-Minimierung (ISO 27001:2022 A.8.8 – Management von technischen Schwachstellen).
„` Get-SmbServerConfiguration | Select-Object EnableMailslots „`
—
25H2: Härtung auf Kernel-Ebene
CLFS HMAC-Härtung – das Ende von Log-Manipulationsangriffen
Das Common Log File System (CLFS) war jahrelang ein Ziel für Privilege-Escalation-Exploits. Mit 25H2 werden Logfiles mit einem HMAC signiert – Manipulationen werden erkannt und abgewiesen.
Compliance-Einordnung:
ISO 27001:2022 A.8.15 (Protokollierung) und A.8.17 (Zeitsynchronisierung): Logfiles müssen integer und nicht manipulierbar sein – CLFS HMAC ist die technische Umsetzung dieses Controls auf Kernel-EbeneDSGVO Art. 32 Abs. 1 lit. b: Integrität der Verarbeitungssysteme – manipulierbare Logs gefährden die Beweiskraft bei DatenschutzvorfällenNIS2: Protokollierungsintegrität ist ein explizites Anforderungsmerkmal für Incident Detection
Wichtig: Der 90-Tage-Countdown läuft. Nach dem Update startet ein Learning Mode, in dem bestehende Logfiles automatisch signiert werden. Nach 90 Tagen schaltet CLFS in den Enforcement Mode – Logfiles ohne gültige Codes werden abgelehnt.
„` Applications and Services Logs → Microsoft → Windows → CLFS → Operational Event ID 1 = Learning Mode aktiv Event ID 2 = Enforcement Mode aktiv „`
—
Administrator Protection – das Ende des Dauer-Admin-Tokens
Prozesse erhalten Adminrechte nur noch für den Moment, in dem sie sie brauchen. Das temporäre, isolierte Token verschwindet danach. Token-Impersonation und Lateral Movement – beides Standardbausteine moderner Ransomware – werden damit strukturell erschwert.
Compliance-Einordnung:
ISO 27001:2022 A.8.2 (Privilegierte Zugriffsrechte): Privilegierte Rechte müssen kontrolliert, zeitlich begrenzt und protokolliert werden – das ist exakt das, was Administrator Protection umsetztISO 27001:2022 A.5.15 (Zugangssteuerung / Least Privilege): Dauerhafte Admin-Token widersprechen dem Least-Privilege-PrinzipBSI IT-Grundschutz ORP.4.A12: Privilegierte Accounts müssen restriktiv eingesetzt werdenNIS2: Zugangskontrolle und Least Privilege sind explizite Anforderungen für kritische Einrichtungen
Aktivieren (Preview, Windows 11 24H2+):
„` Einstellungen → Datenschutz & Sicherheit → Windows-Sicherheit → Kontoschutz → Administrator Protection → Aktivieren „`
Per Registry:
„` HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem TypeOfAdminApprovalMode = 2 „`
Helpdesk-Hinweis: Admins sehen jetzt häufiger explizite Elevation-Prompts – das ist Absicht, kein Bug. Schulungsunterlagen anpassen.
—
Post-Quantum Kryptographie – jetzt vorbereiten, nicht warten
Microsoft integriert post-quanten-sichere Algorithmen (ML-KEM / FIPS 203, ML-DSA / FIPS 204) in Windows-Kernkomponenten. Das Stichwort: Harvest now, decrypt later – Angreifer sammeln heute verschlüsselte Daten, um sie nach dem Quantendurchbruch zu entschlüsseln.
Compliance-Einordnung:
ISO 27001:2022 A.8.24 (Einsatz von Kryptographie): Kryptokonzepte müssen regelmäßig auf Aktualität geprüft werden – Post-Quantum-Readiness ist ab sofort ein legitimes Audit-ThemaDSGVO Erwägungsgrund 83: Angemessenes Schutzniveau unter Berücksichtigung des Stands der Technik – der Stand der Technik schließt PQC-Readiness zunehmend einBSI TR-02102: Die BSI-Technische Richtlinie zu kryptographischen Verfahren wird PQC-Algorithmen mittelfristig als empfohlen listen
Konkreter Handlungsbedarf heute: VPN- und TLS-Lösungen auf PQC-fähige Cipher-Suites prüfen, Hersteller-Roadmaps abfragen, im ISMS als bekanntes Risiko dokumentieren.
—
PowerShell 2.0 und WMIC dauerhaft entfernt
Beide waren klassische Living-off-the-Land-Werkzeuge in Angriffsketten. Jetzt sind sie weg.
Compliance-Einordnung:
ISO 27001:2022 A.8.8 (Management technischer Schwachstellen): Abkündigung veralteter Software-Komponenten mit bekannten Schwachstellen ist ein explizites Control-ZielBSI IT-Grundschutz SYS.2.1.A4 (Abschaltung nicht benötigter Dienste): Unnötige und unsichere Dienste/Tools müssen deaktiviert werden
WMIC-Altlasten in Skripten aufspüren:
„` Get-ChildItem -Path "C:Scripts" -Filter *.ps1 -Recurse | Select-String -Pattern "wmic" | Select-Object Filename, LineNumber, Line „`
Moderne Ersatzbefehle:
„` # Alt: wmic process list brief Get-CimInstance Win32_Process | Select-Object Name, ProcessId, WorkingSetSize
# Alt: wmic product get name,version Get-CimInstance Win32_Product | Select-Object Name, Version „`
—
Hotpatching für Enterprise ohne Neustart
Ab 25H2 Enterprise können Sicherheitsupdates in zwei von drei Monaten pro Quartal ohne Neustart eingespielt werden.
Compliance-Einordnung:
ISO 27001:2022 A.8.8 (Management technischer Schwachstellen): Patches müssen zeitnah eingespielt werden – Hotpatching verkürzt das Zeitfenster zwischen Patch-Veröffentlichung und Deployment drastischNIS2 Art. 21: Patch-Management ist explizit als Sicherheitsmaßnahme gefordert; verkürzte Patch-Zyklen verbessern die Nachweislage gegenüber Behörden
Aktivierung über Windows Autopatch oder Microsoft Intune.
—
26H2: Der Trend wird zur Strategie
26H2 ist geplant für Herbst 2026 – viele Änderungen rollen bereits jetzt über Monthly Updates für 24H2/25H2 aus.
Storage-Einstellungen hinter Admin-Prompt – seit Februar 2026 aktiv
Einstellungen → System → Speicher benötigt seit KB5077181 (Februar 2026 Patch Tuesday) eine UAC-Bestätigung. Standardnutzer sehen eine eingeschränkte Ansicht.
Compliance-Einordnung:
ISO 27001:2022 A.8.3 (Einschränkung des Informationszugangs): Systeminterne Informationen über Dateisystemstrukturen und Cache-Inhalte sind schützenswerte Informationen – der Admin-Prompt ist die technische UmsetzungISO 27001:2022 A.5.15 (Zugangssteuerung): Zugriff auf Systemkonfiguration nur für berechtigte Rollen
Prüfen ob der aktuelle Nutzer erhöhte Rechte hat:
„` ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) „`
Cleanup-Alternative für Standardnutzer:
„` Remove-Item "$env:TEMP*" -Recurse -Force -ErrorAction SilentlyContinue „`
—
Secure Boot Certificate Auto-Rollout
Ab Januar 2026 verteilt Windows neue Secure-Boot-Zertifikate automatisch. In BitLocker-Umgebungen kann das eine Recovery-Key-Abfrage auslösen.
Compliance-Einordnung:
ISO 27001:2022 A.8.24 (Kryptographie) und A.5.9 (Inventar von Informationen und anderen Assets): Zertifikate sind Assets – ihr Lebenszyklusmanagement muss im ISMS abgebildet seinDSGVO Art. 32: Verlust des Zugangs zu verschlüsselten personenbezogenen Daten durch fehlende Recovery Keys kann als meldepflichtiger Vorfall gewertet werden
BitLocker Recovery Keys exportieren und dokumentieren:
„` Get-BitLockerVolume | ForEach-Object { $_.KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'} | Select-Object @{N='Drive';E={$_.MountPoint}}, RecoveryPassword } „`
Recovery Keys aus Active Directory abrufen:
„` Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} ` -Properties msFVE-RecoveryPassword | Select-Object Name, msFVE-RecoveryPassword „`
—
WDS Hardening – Windows Deployment Services
WDS ist ein attraktives Angriffsziel: Manipulierte Images können kompromittierte Betriebssysteme flächendeckend ausrollen.
Compliance-Einordnung:
ISO 27001:2022 A.8.9 (Konfigurationsmanagement): Deployment-Infrastruktur muss gehärtet und konfigurationskontrolliert seinISO 27001:2022 A.5.22 (Überwachung, Überprüfung und Änderungsmanagement von Lieferantendienstleistungen): Drittanbieter-Images und Deployment-Quellen müssen vertrauenswürdig und verifizierbar seinBSI IT-Grundschutz SYS.2.1: Betriebssystem-Deployments müssen integritätsgesichert erfolgen
Mittelfristige Empfehlung: Migration von WDS auf Windows Autopilot oder MDT + ConfigMgr – WDS ist ein Auslaufmodell.
—
Erweiterte Support-Zeiträume: 24 und 36 Monate
Consumer-Editionen erhalten 24 Monate, Business-Editionen 36 Monate Support.
Compliance-Einordnung:
ISO 27001:2022 A.8.8 (Management technischer Schwachstellen): Systeme müssen innerhalb ihres Support-Zeitraums betrieben werden – End-of-Support ist in ISMS-Risikoregistern als Risiko zu führenDSGVO Art. 32: Systeme außerhalb des Hersteller-Supports gelten als technisch nicht mehr geeignet
—
Der Trend – und was er für die Windows-10-Migration bedeutet
Wer jetzt von Windows 10 auf Windows 11 migriert, springt direkt in eine Umgebung, die sicherheitstechnisch und regulatorisch deutlich anspruchsvoller ist als das, was man kennt. Keine schrittweise Gewöhnung – sofortiger Impact auf NAS, Drucker, Legacy-Applikationen, Deployment-Prozesse und Nutzer-Workflows.
Das ist aber auch eine Chance: Wer die Migration sauber plant, schließt gleichzeitig Compliance-Lücken, die beim nächsten ISO-27001-Audit oder nach einem DSGVO-Vorfall teuer werden könnten.
Migrations-Checkliste Windows 10 → Windows 11 24H2+ (technisch & compliance-seitig):
☐ SMB-Signing-Inventur – Event ID 3000 + Get-SmbConnection → Statement of Applicability (SoA) aktualisieren (ISO A.8.20)
☐ Samba-Konfigurationen auf server signing = mandatory setzen → Änderung im Change-Management dokumentieren (ISO A.8.9)
☐ Guest-Shares eliminieren oder mit Authentifizierung absichern → Zugangskontrollrichtlinie prüfen (ISO A.5.15, DSGVO Art. 25)
☐ PowerShell-Skripte auf PS 5.1/PS 7 prüfen, WMIC durch Get-CimInstance ersetzen → Softwareinventar aktualisieren (ISO A.8.8)
☐ Helpdesk-Runbooks aktualisieren: Storage UAC, Elevation-Abfragen erklären → Schulungsnachweis (ISO A.6.3)
☐ BitLocker Recovery Keys vollständig in AD / Intune dokumentieren → Kryptografiekonzept prüfen (ISO A.8.24, DSGVO Art. 32)
☐ CLFS-abhängige Systeme vor Ablauf des 90-Tage-Learning-Mode testen → Testprotokoll für ISMS-Dokumentation
☐ WDS-Umgebungen nach Hardening-Guide prüfen, Ablösung planen → Asset-Register aktualisieren (ISO A.5.9)
☐ Security Baseline 24H2 in GPO-Struktur einpflegen → Baseline in ISMS als implementierte Maßnahme dokumentieren
☐ Risikoregister aktualisieren – alle Ausnahmen (temporäres Signing-Opt-Out, Legacy-Systeme) als befristete Akzeptanzrisiken mit Behandlungsplan eintragen
—
Fazit: Technik und Compliance wachsen zusammen
Microsoft zieht mit 24H2, 25H2 und 26H2 etwas durch, das in der IT-Sicherheit überfällig war: sicheres Verhalten als Default, nicht als Kür. Jahrelange Kompromisse – unsigniertes SMB, Guest-Fallback, Dauer-Admin-Token, veraltete Protokolle – werden jetzt systematisch aufgelöst.
Was mich dabei fasziniert: Diese Defaults decken sich direkt mit dem, was ISO 27001:2022, DSGVO, NIS2 und BSI IT-Grundschutz schon länger fordern. Microsoft macht de facto Compliance-Arbeit im Betriebssystem – aber nur dann, wenn man die Defaults nicht wieder zurückdreht.
Als Admins und Supporter ist unsere Aufgabe nicht, die alten Zustände wiederherzustellen. Die Aufgabe ist, die Umgebungen auf ein Niveau zu heben, das diese Maßnahmen nicht mehr als Störung wahrnimmt – sondern als selbstverständlichen Boden. Wo heute Tickets reinkommen, lagen gestern Schwachstellen. Und wo gestern Schwachstellen lagen, lauert morgen der Auditbefund.
Habt ihr ähnliche Erfahrungen bei eurer Migration oder nach Patch-Tuesdays gemacht? Und wie geht ihr das Thema Compliance-Dokumentation dieser Änderungen in eurem ISMS an? Gerne in die Kommentare.
—
#Windows11 #ITSecurity #SMB #SysAdmin #ITSupport #WindowsServer #Microsoft #ISO27001 #DSGVO #GDPR #NIS2 #BSIGrundschutz #Cybersecurity #SecureFutureInitiative #Windows10Migration #PatchManagement #Compliance #ISMS
← Alle Beiträge