Der Dezember ist traditionell eine Zeit der Jahresendplanung und der Vorbereitung auf die Feiertage. Für IT-Sicherheitsexperten bedeutet er jedoch oft eine der letzten und intensivsten Herausforderungen des Jahres: den Microsoft Patch Tuesday Dezember 2025.

Microsoft hat in diesem Zyklus drei aktiv ausgenutzte Zero-Day-Schwachstellen sowie insgesamt 57 weitere Mängel behoben.

Dies macht den Patchday im Dezember zu einem Pflichttermin für jede Organisation. Wer jetzt zögert, setzt seine gesamte Infrastruktur einem unnötigen und hohen Risiko aus. Wir liefern Ihnen die vollständige Analyse, die notwendigen Details zu den kritischen Schwachstellen und einen klaren, schrittweisen Plan für die sofortige Umsetzung der Sicherheitsupdates Microsoft. Lesen Sie weiter, um Ihre Systeme effektiv zu schützen.

Die wichtigsten Zahlen: 3 Zero-Days und 57 Schwachstellen im Fokus

Der Umfang dieses Monats-Updates ist signifikant und unterstreicht die Notwendigkeit eines robusten Patch-Managements. Die offizielle Zählung des Microsoft Patch Tuesday Dezember 2025 umfasst die Behebung von 60 einzelnen Sicherheitslücken.

Die kritische Bilanz im Detail:

Die reine Anzahl der behobenen Fehler ist besorgniserregend, doch die Präsenz von 3 Zero-Day-Lücken Dezember ist ein direkter Aufruf zum Handeln. Zero-Day-Exploits sind die gefährlichste Kategorie von Schwachstellen, da sie bereits aktiv von Cyberkriminellen ausgenutzt werden, bevor der Hersteller das entsprechende Windows Update Dezember 2025 bereitstellt.

Detailanalyse der Zero-Day-Schwachstellen: Was Sie wissen müssen

Drei Schwachstellen, für die bereits öffentlich Exploits existieren und die aktiv in der Wildnis ausgenutzt werden, stehen im Zentrum dieses Patchday. Obwohl Microsoft die genauen CVE-Nummern und Details erst mit der Veröffentlichung bekannt gibt, können wir basierend auf den üblichen Klassifizierungen die potenziellen Risiken und Angriffsszenarien ableiten.

Sicherheitslücke im Windows Cloud Files Mini Filter Driver CVE-2025-62221

„Wenn Angreifer von einem Konto mit geringen Berechtigungen die vollständige Kontrolle über das System erlangen können, wird jeder kompromittierte Benutzer zu einem Einfallstor für die vollständige Übernahme.“

CVE-2025-62221 ist eine Sicherheitslücke vom Typ „Elevation of Privilege“ (EoP) im Windows Cloud Files Mini Filter Driver, einer Komponente, die von Windows zur Verwaltung von Cloud-synchronisierten Dateien und Platzhalterdateien verwendet wird. Diese Schwachstelle ermöglicht es Angreifern, die bereits über eingeschränkten lokalen Zugriff verfügen, ihre Berechtigungen auf SYSTEM zu erweitern. Microsoft hat eine aktive Ausnutzung bestätigt, was bedeutet, dass Angreifer diese Sicherheitslücke bereits in realen Angriffen nutzen.

CVSS-Score: 7,8

SCHWERWIEGENDHEIT: Wichtig

BEDROHUNG: Rechteausweitung

EXPLOITS: Diese Sicherheitslücke wird aktiv ausgenutzt. Obwohl kein vollständig öffentlicher Proof-of-Concept-Code veröffentlicht wurde, wurde die Ausnutzung von Sicherheitsteams beobachtet und wird als Teil gezielter Intrusion-Ketten verwendet. Sobald Angreifer lokalen Zugriff erhalten – selbst über geringfügige Zugangspunkte –, können sie mithilfe dieser Schwachstelle zuverlässig ihre Rechte ausweiten.

TECHNISCHE ZUSAMMENFASSUNG: Der Windows Cloud Files Mini Filter Driver behandelt bestimmte Dateisystemoperationen im Zusammenhang mit Cloud-gestützten Inhalten nicht ordnungsgemäß. Ein Angreifer kann diese Interaktionen manipulieren, um den Treiber dazu zu bringen, privilegierte Aktionen in seinem Namen auszuführen. Da der Treiber innerhalb des Windows-Kernels mit einem hohen Vertrauensniveau arbeitet, ermöglicht der Missbrauch dieser Schwachstelle Angreifern, Code mit erhöhten Berechtigungen auszuführen, geschützte Systemressourcen zu ändern, Sicherheitskontrollen zu deaktivieren oder dauerhaften Zugriff zu erlangen.

EXPLOITIERBARKEIT: Alle unterstützten Windows-Versionen, die den Cloud Files Mini Filter Driver verwenden, sind betroffen. Die Ausnutzung erfordert, dass der Angreifer Code lokal ausführt, aber sobald dies erreicht ist, kann er das anfällige Verhalten des Treibers auslösen, um die Berechtigungen auf SYSTEM zu erweitern. Dies macht ihn zu einer äußerst wertvollen Komponente in mehrstufigen Angriffsketten.

AUSWIRKUNGEN AUF DAS UNTERNEHMEN: Eine aktive Ausnutzung erhöht das Risiko erheblich. Angreifer können:

• Die vollständige Kontrolle über kompromittierte Systeme übernehmen.
• Erkennungs-Tools und Sicherheitsagenten deaktivieren.
• Lokal gespeicherte sensible Daten oder Anmeldedaten stehlen.
• Sich lateral über Netzwerke bewegen, um weitere Systeme zu kompromittieren.
• Eine hohe Persistenz mit hohen Berechtigungen herstellen, was die Reaktion auf Vorfälle erheblich erschwert.

Da Cloud-synchronisierte Dateifunktionen in Unternehmensumgebungen weit verbreitet sind, sind fast alle Organisationen gefährdet, wenn der Patch nicht schnell installiert wird.

WORKAROUND: Wenn sich die Installation des Patches verzögert:

• Beschränken Sie den lokalen Benutzerzugriff und stellen Sie sicher, dass Richtlinien für geringste Privilegien durchgesetzt werden.
• Beschränken Sie die Ausführung nicht vertrauenswürdiger Software, um zu verhindern, dass Angreifer den für lokale Exploits erforderlichen ersten Zugang erhalten.
• Reduzieren Sie vorübergehend die Abhängigkeit von Cloud-Synchronisierungsfunktionen, sofern dies betrieblich möglich ist.

Diese Maßnahmen verringern das Risiko, beseitigen jedoch nicht die zugrunde liegende Schwachstelle.

DRINGLICHKEIT: Dieser Patch muss schnell bereitgestellt werden, da die Schwachstelle bereits in der Praxis ausgenutzt wird, eine Rechteausweitung auf SYSTEM ermöglicht und leicht mit Phishing, Browser-Exploits, bösartigen Dokumenten oder anderen Low-Level-Einstiegspunkten kombiniert werden kann. Wenn Systeme nicht gepatcht werden, können Angreifer mit minimalen Hindernissen schnell die vollständige Kontrolle über Windows-Geräte erlangen.

PowerShell-Remote-Code-Ausführungs-Schwachstelle CVE-2025-54100

„Selbst eine als wichtig eingestufte RCE kann zu einem kritischen Einstiegspunkt werden, wenn Angreifer sie finden, bevor Verteidiger sie beheben.“

Diese Schwachstelle ermöglicht es Angreifern, aus der Ferne beliebigen Code auf betroffenen Systemen auszuführen, indem sie die Art und Weise ausnutzen, wie die Software bestimmte nicht vertrauenswürdige Eingaben verarbeitet. Obwohl sie als wichtig eingestuft ist, stellt sie aufgrund ihrer Fähigkeit, die Ausführung von Remote-Code zu ermöglichen, eine ernsthafte Bedrohung dar, die die Integrität und Stabilität des Systems gefährden kann, wenn sie nicht behoben wird.

CVSS-Score: 7,8

SCHWERWIEGENDHEIT: Wichtig

BEDROHUNG: Remote Code Execution (RCE)

EXPLOITS: Derzeit sind keine öffentlichen Exploits, Zero-Day-Aktivitäten oder Proof-of-Concept-Codes bekannt. Allerdings werden RCE-Schwachstellen nach ihrer Offenlegung häufig zum Ziel für die Entwicklung von Exploits.

TECHNISCHE ZUSAMMENFASSUNG: CVE-2025-54100 wird durch unzureichende Bereinigung und Validierung extern bereitgestellter Daten verursacht. Wenn eine manipulierte Anfrage verarbeitet wird, kann die anfällige Komponente den Speicher oder den Ausführungsfluss falsch verarbeiten, sodass Angreifer aus der Ferne beliebigen Code ausführen können. Die Codeausführung würde unter den Berechtigungen des betroffenen Dienstes erfolgen und möglicherweise Zugriff zum Ändern von Daten, Stören von Prozessen oder Eskalieren von Angriffen gewähren.

AUSNUTZBARKEIT: Systeme, auf denen betroffene Versionen der Software ausgeführt werden, sind anfällig. Angreifer würden diese Schwachstelle in der Regel ausnutzen, indem sie speziell gestaltete Netzwerkeingaben an den exponierten Dienstendpunkt senden und so ein unbeabsichtigtes Ausführungsverhalten verursachen.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Obwohl das Risiko der Remote-Codeausführung als „wichtig” eingestuft wird, kann es dennoch zu schwerwiegenden geschäftlichen Folgen führen, darunter Dienstausfälle, Datenmanipulation, Systeminstabilität oder die Gefahr einer tieferen Kompromittierung des Netzwerks. Unternehmen können bei Ausnutzung dieser Schwachstelle mit Produktivitätsverlusten, erhöhten Kosten für die Reaktion auf Vorfälle und Reputationsproblemen konfrontiert werden.

WORKAROUND: Wenn Patches nicht sofort angewendet werden können, beschränken Sie den Zugriff auf den betroffenen Dienst, verstärken Sie die Netzwerkgrenzen, reduzieren Sie die Exposition gegenüber nicht vertrauenswürdigen Netzwerken und überwachen Sie die Protokolle auf verdächtige Eingabemuster oder abnormales Verhalten.

DRINGLICHKEIT: Da diese Schwachstelle RCE ermöglicht – auch ohne derzeit öffentliche Exploits – sollte das Patchen Priorität haben. Es ist unerlässlich, Remote-Angreifern die Möglichkeit zur Codeausführung zu verwehren, um die Systemsicherheit aufrechtzuerhalten und das Risiko zu verringern, dass zukünftige Exploits dies zu einem hochriskanten Vektor machen.

Microsoft Office Remote Code Execution Vulnerability CVE-2025-62554

„Ein einziger Remote-Code-Fehler kann ein vertrauenswürdiges System zum Spielfeld eines Angreifers machen, wenn er nicht rechtzeitig gepatcht wird.“

Diese Sicherheitslücke ermöglicht es Angreifern, beliebigen Code auf betroffenen Systemen auszuführen, indem sie eine Schwachstelle in der Verarbeitung bestimmter externer Eingaben durch die Software ausnutzen. Eine erfolgreiche Ausnutzung könnte es einem Angreifer ermöglichen, die vollständige Kontrolle über das System zu übernehmen, Daten zu verändern, Dienste zu stören oder tiefer in das Netzwerk vorzudringen.

CVSS-Score: 8,4

SCHWERWIEGENDHEIT: Kritisch

BEDROHUNG: Remote-Code-Ausführung (RCE)

EXPLOITS: Derzeit sind keine öffentlichen Exploit-Codes, Zero-Day-Aktivitäten oder Proof-of-Concept-Demonstrationen bekannt. Allerdings führen RCE-Schwachstellen mit hoher Schwere häufig kurz nach ihrer Offenlegung zur Entwicklung von Exploits.

TECHNISCHE ZUSAMMENFASSUNG: CVE-2025-62554 entsteht durch eine unsachgemäße Validierung extern bereitgestellter Daten. Wenn eine speziell gestaltete Anfrage verarbeitet wird, behandelt die anfällige Komponente die Eingabe falsch und löst einen unbeabsichtigten Ausführungspfad aus. Dadurch können Angreifer beliebigen Code mit den Berechtigungen des kompromittierten Dienstes ausführen. Wenn dies ausgenutzt wird, kann dies zu Systemmanipulationen, Datenoffenlegung oder vollständigen Betriebsstörungen führen.

AUSNUTZBARKEIT: Alle Systeme, auf denen betroffene Versionen der anfälligen Software ausgeführt werden, sind gefährdet. Angreifer nutzen diese Art von Schwachstelle in der Regel aus, indem sie manipulierte Netzwerkanfragen an die exponierte Dienstschnittstelle senden und das System so zwingen, nicht autorisierten Code auszuführen.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Ein erfolgreicher RCE-Angriff kann zu einer vollständigen Kompromittierung des Systems führen und Unternehmen Datenverstößen, Ransomware-Angriffen, Betriebsausfällen, regulatorischen Risiken und langfristigen Reputationsschäden aussetzen. Diese Art von Schwachstelle bietet Angreifern einen direkten Weg zu hochwertigen Vermögenswerten.

WORKAROUND: Wenn Patches nicht sofort angewendet werden können, sollten Unternehmen den Zugriff auf den betroffenen Dienst einschränken, strenge Firewall-Regeln anwenden, anfällige Systeme nach Möglichkeit isolieren und das Netzwerkverhalten genau auf Anomalien überwachen.

DRINGLICHKEIT: Da es sich um eine kritische RCE-Sicherheitslücke handelt, ist eine schnelle Bereitstellung von Patches unerlässlich. RCE-Schwachstellen gehören zu den am häufigsten von Angreifern ausgenutzten Schwachstellen, und die potenziellen Auswirkungen – von der Übernahme des Systems bis hin zu weitreichenden lateralen Bewegungen – machen eine sofortige Abhilfe unerlässlich.

Microsoft Office Remote Code Execution Vulnerability CVE-2025-62557

„Wenn die Ausführung von Code von außen möglich wird, wird jedes nicht gepatchte System zu einer offenen Einladung für Angreifer.“

Diese Schwachstelle ermöglicht es einem Angreifer, durch Ausnutzung einer unsachgemäßen Validierung innerhalb einer zentralen Verarbeitungskomponente aus der Ferne beliebigen Code auf betroffenen Systemen auszuführen. Eine erfolgreiche Ausnutzung könnte dem Angreifer die vollständige Kontrolle über das System verschaffen und Datenmanipulationen, Dienstunterbrechungen oder eine weitere Kompromittierung verbundener Umgebungen ermöglichen.

CVSS-Score: 8,4

SCHWERWIEGENDHEIT: Kritisch

BEDROHUNG: Remote Code Execution (RCE)

EXPLOITS: Derzeit sind keine bestätigten öffentlichen Exploits, Zero-Day-Angriffe oder Proof-of-Concept-Codes verfügbar. Dennoch führen RCE-Schwachstellen mit hoher Kritikalität aufgrund ihrer potenziellen Auswirkungen häufig zu einer raschen Entwicklung von Exploits.

TECHNISCHE ZUSAMMENFASSUNG: CVE-2025-62557 wird durch eine unzureichende Eingabevalidierung verursacht, die bei der Verarbeitung von netzwerkbasierten Anfragen auftritt. Diese Schwachstelle ermöglicht es speziell gestalteten Eingaben, unbeabsichtigte Ausführungspfade auszulösen, was letztendlich die Remote-Ausführung von beliebigem Code mit den Berechtigungen des Zielservices ermöglicht. Bei Ausnutzung könnten Angreifer schädliche Software installieren, Systemkonfigurationen manipulieren, sensible Informationen stehlen oder wichtige Vorgänge unterbrechen.

AUSNUTZBARKEIT: Alle Systeme, auf denen anfällige Versionen der betroffenen Software ausgeführt werden, sind gefährdet. Angreifer würden dies in der Regel ausnutzen, indem sie böswillig gestaltete Anfragen an den exponierten Dienstendpunkt senden, wodurch die anfällige Komponente nicht autorisierten Code ausführt.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Ein erfolgreicher Angriff könnte zu einer vollständigen Kompromittierung des Systems führen. Unternehmen können mit Betriebsausfällen, Datenverlusten, finanziellen Schäden und langfristigen Reputationsschäden konfrontiert sein. Da RCE-Schwachstellen Angreifern direkte Kontrolle verschaffen, stellen sie eine erhebliche Bedrohung für die Geschäftskontinuität und die Sicherheitsintegrität dar.

WORKAROUND: Wenn das Patch nicht sofort angewendet werden kann, sollten Unternehmen den Netzwerkzugriff auf den betroffenen Dienst einschränken, zusätzliche Überwachung auf Anomalien aktivieren und strenge Firewall- oder Segmentierungskontrollen einsetzen, um die Gefährdung zu verringern.

DRINGLICHKEIT: Dieses Patch muss schnell eingesetzt werden, da kritische RCE-Schwachstellen oft zu Hauptzielen für die Entwicklung von Exploits werden. Das Risiko einer vollständigen Systemübernahme macht eine schnelle Schadensbegrenzung unerlässlich, um die Sicherheit aufrechtzuerhalten und eine potenzielle Sicherheitsverletzung zu verhindern.

Microsoft Office Remote Code Execution Vulnerability CVE-2025-62562

„Ein einziger übersehener Fehler kann Angreifern als Türöffner dienen, um die vollständige Kontrolle zu erlangen – dieser Patch verschließt diese Tür, bevor jemand durch sie hindurchgeht.“

Diese Schwachstelle ermöglicht es Angreifern, beliebigen Code auf betroffenen Systemen aus der Ferne auszuführen, wodurch sie die Möglichkeit erhalten, ohne Autorisierung bösartige Befehle auszuführen. Wenn sie ausgenutzt wird, gewährt sie dem Angreifer Berechtigungen, die Daten gefährden, den Betrieb stören oder seitliche Bewegungen im Netzwerk ermöglichen könnten.

CVSS-Score: 8,4

SCHWERWIEGENDHEIT: Kritisch

BEDROHUNG: Remote Code Execution (RCE)

EXPLOITS: Derzeit sind keine öffentlichen Exploit-Codes oder Zero-Day-Angriffe bekannt. Schwachstellen, die die Ausführung von Remote-Code ermöglichen, ziehen jedoch aufgrund ihrer hohen Auswirkungen und ihrer breiten Angriffsfläche oft schnell die Entwicklung von Exploits nach sich.

TECHNISCHE ZUSAMMENFASSUNG: CVE-2025-62562 resultiert aus einer unsachgemäßen Eingabeverarbeitung innerhalb einer Kernverarbeitungskomponente der betroffenen Software. Der Fehler ermöglicht es manipulierten Netzwerkeingaben, Sicherheitsprüfungen zu umgehen, was letztlich die Ausführung von beliebigem Code unter dem Sicherheitskontext der Anwendung ermöglicht. Wenn dieser Fehler ausgenutzt wird, könnte ein Angreifer Programme installieren, Daten ändern oder stehlen oder den normalen Systembetrieb stören.

AUSNUTZBARKEIT: Systeme, auf denen anfällige Versionen der betroffenen Software ausgeführt werden, sind gefährdet. Ein Angreifer würde diese Schwachstelle in der Regel ausnutzen, indem er speziell gestaltete Anfragen an den exponierten Dienst sendet und so den Codeausführungspfad auslöst.

AUSWIRKUNGEN AUF DAS GESCHÄFT: Diese Schwachstelle kann direkt zu einer vollständigen Kompromittierung des Systems führen. Unternehmen können mit Betriebsausfällen, Datendiebstahl, Ransomware-Vorfällen und Reputationsschäden konfrontiert werden. Selbst ein einziger erfolgreicher Angriff, der eine RCE-Schwachstelle ausnutzt, kann zu weitreichenden Risiken für das Unternehmen führen.

WORKAROUND: Wenn eine sofortige Patch-Installation nicht möglich ist, beschränken Sie den Zugriff auf den betroffenen Dienst, wenden Sie Filter auf Netzwerkebene an und überwachen Sie ungewöhnliche Verkehrsmuster, bis Updates bereitgestellt werden können.

DRINGLICHKEIT: Da es sich um eine kritische RCE-Sicherheitslücke mit hohem Schadenspotenzial handelt, ist eine schnelle Bereitstellung des Patches unerlässlich, um zu verhindern, dass Angreifer die vollständige Kontrolle über Systeme erlangen. RCE-Schwachstellen sind bevorzugte Ziele für Angreifer und werden oft schnell als Waffen eingesetzt.

Microsoft Windows LNK-Datei-UI-Fehldarstellung (CVE-2025-9491)

„Eine harmlos aussehende Windows-Verknüpfung kann gefährliche Befehle verbergen und ohne Vorwarnung Malware starten.“

Das Update von Microsoft behebt CVE-2025-9491, eine schwerwiegende Schwachstelle in der Darstellung von .LNK-Verknüpfungsdateizielen durch Windows. Durch das Einfügen von Leerzeichen in Befehle konnten Angreifer bösartige Argumente in den Eigenschaften der Datei verstecken, sodass die Verknüpfung sicher erschien. Die Schwachstelle hatte einen hohen CVSS-Score (7,0–7,8) und wurde aktiv in realen Angriffen ausgenutzt, darunter Kampagnen, bei denen PlugX-Malware eingesetzt wurde.

Der Patch zwingt Windows nun dazu, das vollständige, unverhüllte Ziel der Verknüpfung anzuzeigen, sodass Angreifer keine schädlichen Befehle mehr hinter irreführenden UI-Verhaltensweisen verstecken können.

Die Sicherheitsupdates vom Patch Tuesday im Dezember 2025

Nachfolgend finden Sie die vollständige Liste der behobenen Sicherheitslücken in den Updates vom Patch Tuesday im Dezember 2025.

Der Beitrag 2025-12 Patchday erschien zuerst auf Grams IT - Blog.

Quelle: datenschutz.hessen.de

Einleitung: Das Ende der Rechtsunsicherheit – Microsoft 365 in der Kommune

Microsoft 365 ist längst mehr als nur eine Bürosoftware; es ist das zentrale Nervensystem moderner digitaler Verwaltung. Dennoch hängt über seiner Nutzung in deutschen Kommunen weiterhin die Wolke der Rechtsunsicherheit. Die digitale Transformation im öffentlichen Sektor ist auf effiziente, vernetzte Lösungen angewiesen, doch die strikten Vorgaben der Datenschutz-Grundverordnung (DSGVO) und die komplexen Implikationen des Schrems II-Urteils bremsen den Fortschritt massiv aus. Insbesondere die Frage, wie ein US-amerikanischer Cloud-Anbieter datenschutzkonform als Auftragsverarbeiter (AV) fungieren kann, beschäftigt juristische Abteilungen und IT-Leiter gleichermaßen.

Mit der Veröffentlichung des wegweisenden Berichts des Hessischen Beauftragten für Datenschutz und Informationsfreiheit (HBDI) vom 15. November 2025 – einer Blaupause für die gesamte Öffentliche Verwaltung Cloud-Nutzung – ist nun endlich ein klarer Fahrplan vorgegeben. Dieser umfassende Leitfaden basiert auf der detaillierten Analyse des HBDI-Berichts und bietet Ihnen, den Verantwortlichen in Kommunen, die konkrete Schritt-für-Schritt-Anleitung, wie Sie Microsoft 365 rechtssicher einführen und betreiben können. Wir tauchen tief in die Materie ein, von den obligatorischen Technischen und Organisatorischen Maßnahmen (TOMs) über die Herausforderung der Telemetriedaten Microsoft bis hin zur korrekten Umsetzung der Standardvertragsklauseln M365. Nutzen Sie diese Expertise, um Ihre Verwaltung zukunftssicher und M365 datenschutzkonform zu gestalten.

1. Die Quintessenz des HBDI-Berichts (15.11.2025): Neue Mindestanforderungen

Der von vielen Stellen lange erwartete Bericht des HBDI schafft Klarheit und definiert Sieben Mindestanforderungen, ohne deren konsequente Umsetzung eine datenschutzkonforme Nutzung von Microsoft 365 in der Öffentlichen Verwaltung Cloud nicht mehr statthaft ist. Der Bericht erkennt den Mehrwert der Plattform an, stellt aber unmissverständlich fest: Der bloße Abschluss des Auftragsverarbeitungsvertrages (AVV) und der Standardvertragsklauseln (SCCs) reicht alleine nicht mehr aus. Die juristische Hürde des US Cloud Act muss durch verstärkte TOMs aufseiten der Kommune überwunden werden.

1.1 Das Drei-Säulen-Modell der Compliance

Der HBDI-Bericht baut seine Analyse auf drei fundamentalen Säulen auf, die in ihrer Gesamtheit die Risiken der Datenübermittlung in die USA minimieren sollen:

1. Rechtliche Fundierung (Säule I): Die korrekte Kaskadierung von AVV und den neuen SCCs als zwingende Basis, ergänzt durch spezifische vertragliche Zusätze zur Informationspflicht.
2. Technische Risiko-Minimierung (Säule II): Die Implementierung von Ende-zu-Ende-Verschlüsselung (E2EE) für bestimmte Datenkategorien und die vollständige Kontrolle über Telemetriedaten.
3. Organisatorische Verantwortung (Säule III): Die lückenlose Datenschutzfolgeabschätzung (DSFA) und die permanente Schulung der Mitarbeiter bezüglich sensibler Daten.

Der Bericht weist Kommunen die alleinige Verantwortung für die Einhaltung der DSGVO zu. Microsoft ist zwar Auftragsverarbeiter, doch die Entscheidung und die Haftung für die Angemessenheit der getroffenen Maßnahmen obliegt der verantwortlichen Stelle, sprich, der Kommune.

1.2 Die zentralen, juristischen HBDI-Forderungen

Die strengste Anforderung des HBDI zielt auf die Minimierung des Zugriffsrisikos durch US-Behörden (im Sinne von Schrems II) ab.

A. Nachweis der effektiven SCC-Zusatzmaßnahmen (Artikel 46 DSGVO)

Kommunen müssen nun aktiv nachweisen, dass die vertraglich vereinbarten Standardvertragsklauseln M365 durch zusätzliche, wirksame Maßnahmen ergänzt werden. Der HBDI fordert eine detaillierte Dokumentation, die über eine einfache Checkliste hinausgeht.

Verbindliche Elemente der Nachweisdokumentation:

• Risikoanalyse des Drittlandtransfers (TTA): Eine spezifische Analyse, welche Datenkategorien (z.B. Sozialdaten, Personaldaten) in welche M365-Dienste übertragen werden, und eine Bewertung des Zugriffsrisikos durch US-Behörden für jeden Dienst (Exchange Online, SharePoint Online, Teams).
• Definition der „Red-Line“-Daten: Eindeutige Festlegung, welche Daten (z.B. Kommunalwahlen, Bauakten) unter keinen Umständen unverschlüsselt in die Cloud gelangen dürfen. Für diese Daten gilt ein absolutes E2EE-Gebot.
• Vertragliche Zusicherung der Transparenz: Die Kommune muss von Microsoft vertraglich die Zusage einfordern, über jegliche Anfragen von US-Behörden unverzüglich und vollumfänglich informiert zu werden, selbst wenn dies – theoretisch – gegen US-Recht verstoßen könnte (sog. „Transparency-Klausel“).

B. Klarstellung zur Datenverantwortung

Der Bericht betont, dass die Kommune nicht nur für die Auftragsverarbeitung Microsoft 365 verantwortlich ist, sondern auch klar definieren muss, wann sie (hypothetisch) mit Microsoft als gemeinsam Verantwortlicher handelt. Dies betrifft insbesondere die Konfiguration der Dienste und die Nutzung von Features, die über die reine Verarbeitung von Weisungsdaten hinausgehen (z.B. Cortana-Funktionen, bestimmte AI-Assistenten). Der HBDI fordert, dass diese Grenzziehung in der DSFA detailliert und nachvollziehbar dargelegt wird.

2. Telemetrie und Diagnosedaten: Die Achillesferse entschärfen

Der HBDI-Bericht identifiziert die Erfassung und Übermittlung von Telemetriedaten Microsoft – also Daten über die Nutzung und den Zustand der Software – als den kritischsten und oft unterschätzten datenschutzrechtlichen Knackpunkt. Diese Daten sind essenziell für Microsoft zur Wartung und Verbesserung des Dienstes, können aber auch Rückschlüsse auf individuelle Nutzungsmuster, IP-Adressen, Gerätekennungen und unter Umständen sogar auf in den Dateinamen enthaltene personenbezogene Informationen zulassen.

2.1 HBDI-Diktat: Volle Kontrolle über Telemetriedaten

Der Bericht legt fest, dass Kommunen die Kontrolle über diese Daten vollständig übernehmen müssen. Es wird eine Zero-Trust-Policy für die automatische Übermittlung von Diagnosedaten gefordert, es sei denn, die Übermittlung ist technisch zwingend für die Funktion des Dienstes erforderlich und kann nicht vermieden werden.

Konkrete Konfigurationsvorgaben im Detail

Der HBDI unterscheidet zwischen drei Kategorien von Telemetriedaten und legt für jede klare Anforderungen fest:

Die Pflicht zur Netzwerkanalyse

Als neue, verschärfte TOM verlangt der HBDI von Kommunen, vor der Produktivsetzung eine detaillierte Netzwerkanalyse durchzuführen. Dabei muss protokolliert werden, welche Endpunkte (URLs, IP-Adressen) von den M365-Clients im „Required“-Modus kontaktiert werden und welche Datenpakete dabei gesendet werden.

• Ziel: Die Kommune muss sich vergewissern, dass Microsoft die vertraglichen Zusicherungen zur Telemetrie-Begrenzung auch technisch einhält.
• Ergebnis: Die Analyse muss Bestandteil der DSFA sein. Nur wenn die Datenübermittlung auf das absolute Minimum beschränkt ist, ist die Nutzung zulässig.

2.2 Microsoft Purview als Kontrollzentrum

Der HBDI-Bericht hebt die Notwendigkeit hervor, die bereitgestellten Tools zur Kontrolle der Datenflüsse konsequent zu nutzen. Microsoft Purview (ehemals Compliance Center) wird dabei zum zentralen Kontrollzentrum der Kommune.

Vier kritische Purview-Funktionen:

1. Audit-Logging: Aktivierung der erweiterten Überwachung (Advanced Auditing) und die mindestens 5-jährige Speicherung der Protokolle. Dies dient dem Nachweis im Falle einer Datenpanne und der Einhaltung der kommunalen Aufbewahrungspflichten.
2. eDiscovery: Die Fähigkeit, auf Basis des HBDI-Berichts schnell und präzise auf etwaige Anfragen von US-Behörden reagieren zu können (sog. „Red-Button-Fähigkeit“). Die Kommune muss nachweisen, dass sie innerhalb kürzester Zeit (z.B. 48 Stunden) alle betroffenen Daten identifizieren und den Zugriff sperren könnte.
3. Data Loss Prevention (DLP): Zwingende Implementierung von DLP-Regeln, die das unautorisierte Teilen und Speichern von Sozialdaten und Kommunalgeheimnissen in unverschlüsselten M365-Diensten (z.B. OneDrive-Ordner ohne E2EE) unterbinden.
4. Information Protection (Sensitivity Labels): Klassifizierung aller Daten mit Sensitivity Labels. Diese Labels (z.B. „VS-NUR FÜR DIENSTLICHEN GEBRAUCH“, „PERSONENBEZOGEN – KLARNAME“) müssen die technische E2EE-Verschlüsselung bei der Speicherung in der Cloud erzwingen. Dies ist die wichtigste TOM zur Überwindung der Schrems II Microsoft 365 Problematik.

3. Die rechtliche Gratwanderung: Auftragsverarbeitung und Schrems II

Die zweite juristische Säule der HBDI-Analyse dreht sich um die rechtskonforme Ausgestaltung des Verhältnisses zwischen der Kommune (Verantwortlicher) und Microsoft (Auftragsverarbeiter) unter Berücksichtigung der Drittlandtransfers gemäß Schrems II (EuGH C-311/18).

3.1 Das Dilemma der US-Cloud-Anbieter

Der HBDI-Bericht bekräftigt, dass die US-Gesetze, insbesondere der Cloud Act und die FISA 702, weiterhin ein fundamentales Problem darstellen, da sie US-Behörden unter bestimmten Umständen den Zugriff auf Daten ohne Kenntnis des europäischen Verantwortlichen ermöglichen. Die einfache Nutzung von Rechenzentren in der EU (z.B. Deutschland oder den Niederlanden) ist nicht ausreichend, da Microsoft als US-Unternehmen diesen Gesetzen unterliegt.

A. Die Rolle der Standardvertragsklauseln

Die Standardvertragsklauseln M365 (neue SCCs) dienen als Ersatz für ein Angemessenheitsniveau und sind die Grundlage für den Datentransfer. Der HBDI fordert, dass die Kommune nicht nur die SCCs unterzeichnet, sondern auch eine lückenlose Wirksamkeitsprüfung vornimmt.

Drei Punkte zur Wirksamkeitsprüfung (TTA – Transfer Impact Assessment):

1. Rechtsvergleich: Detaillierte Prüfung, ob das Schutzniveau der SCCs durch das Recht des Drittlandes (USA) untergraben wird. Der HBDI liefert hierfür eine Muster-Rechtsvergleichsanalyse, die die Kommune nur noch unterschreiben und in ihre DSFA integrieren muss.
2. Technische Maßnahmen als Ultima Ratio: Die technische E2EE-Verschlüsselung wird zur zwingenden Zusatzmaßnahme. Die Kommunen müssen festlegen, dass für alle Daten, deren Offenlegung bei einem Zugriff von US-Behörden einen „hohen oder sehr hohen Schaden“ für die Betroffenen (Bürger, Mitarbeiter) verursachen würde, eine E2EE implementiert sein muss.
3. Häufigkeit der Überprüfung: Die gesamte TTA und die damit verbundenen technischen TOMs müssen mindestens jährlich überprüft und vom Datenschutzbeauftragten (DSB) der Kommune freigezeichnet werden.

B. Klarstellung zur Datenresidenz und Pseudonymisierung

Der HBDI-Bericht stellt klar, dass Datenresidenz in der EU zwar erwünscht, aber kein Allheilmittel ist. Die datenschutzrechtliche Verantwortung bleibt beim Verantwortlichen.

• Geografische Einschränkung: Die Kommune muss die Speicherung der Kundendaten (Core Customer Data) vertraglich auf die EU begrenzen. Dies geschieht über die Konfigurationsoptionen im M365 Admin Center.
• Pseudonymisierung: Für alle nicht E2EE-geschützten Metadaten und Telemetriedaten, die zwangsläufig an Microsoft übermittelt werden, muss die Kommune die Pseudonymisierungsfunktionen der Clients nutzen, um eine direkte Identifizierbarkeit zu verhindern. Hierzu zählt die Nutzung von Nutzer-IDs anstelle von Klarnamen in den Logfiles.

3.2 Die perfekte Auftragsverarbeitung

Der Auftragsverarbeitungsvertrag zwischen Kommune und Microsoft muss die im HBDI-Bericht geforderten Spezifikationen enthalten, die über die Standardklauseln hinausgehen.

Mindestens drei zwingende, neue vertragliche Zusätze:

1. Reaktionskette im Notfall: Detaillierte Regelung, wie Microsoft die Kommune im Falle einer Datenzugriffsanfrage von US-Behörden unmittelbar informiert und welche rechtlichen Schritte Microsoft in Absprache mit der Kommune einleitet (z.B. Einspruch gegen die Herausgabepflicht).
2. Audit-Recht: Der Kommune muss explizit das Recht eingeräumt werden, eigene unabhängige Audits der technischen und organisatorischen Umgebung bei Microsoft durchzuführen (Audit-Recht). Dies dient der kontinuierlichen Überprüfung der vertraglichen Zusicherungen (Art. 28 Abs. 3 lit. h DSGVO).
3. Kündigungsrecht bei Rechtsänderung: Ein Sonderkündigungsrecht muss vereinbart werden, das die Kommune zur sofortigen Kündigung ermächtigt, falls sich die US-Gesetzeslage (z.B. Verschärfung des Cloud Act) so ändert, dass die Einhaltung der DSGVO-Grundsätze unmöglich wird.

4. Technische und Organisatorische Maßnahmen (TOMs) als Schlüssel zur Compliance

Der HBDI-Bericht widmet den Technischen und Organisatorischen Maßnahmen (TOMs) das größte Kapitel und macht deutlich, dass nur eine perfekt konfigurierte M365-Umgebung als M365 datenschutzkonform gelten kann. Die Kommunen müssen hierfür einen erheblichen Aufwand betreiben.

4.1 Die Pflicht zur Ende-zu-Ende-Verschlüsselung (E2EE)

Die E2EE ist das zentrale TOM zur Überwindung der Schrems II Microsoft 365 Problematik. Der HBDI-Bericht definiert klar, wann E2EE zwingend erforderlich ist:

• Kategorie A (Zwingendes E2EE):
  • Sozialdaten: Alle Daten aus Sozialämtern, Jugendämtern, etc.
  • Besondere Kategorien personenbezogener Daten (Art. 9 DSGVO): Gesundheitsdaten (Amtsarzt), politische Meinungen (Wahlämter), religiöse Zugehörigkeit.
  • Kommunal- und Staatsgeheimnisse: Hochsensible Akten (z.B. Vergabeunterlagen, innere Sicherheit der Kommune).

Umsetzung der E2EE-Anforderung

Kommunen müssen hierfür eine Kombination aus bordeigenen M365-Features und Drittanbieterlösungen nutzen:

• Double Key Encryption (DKE): Dies wird vom HBDI für die Kategorie A Daten empfohlen. DKE ermöglicht der Kommune, einen eigenen Schlüssel (Key 1) zu halten, während Microsoft nur den zweiten Schlüssel (Key 2) verwaltet. Nur die Kommune kann die Daten entschlüsseln, was einen Zugriff durch US-Behörden – selbst mit einer richterlichen Anordnung gegen Microsoft – technisch unmöglich macht. Die Nutzung von DKE erfordert eine spezifische Lizenzierung (z.B. E5 Compliance).
• Sensitivity Labels: Verwendung von Microsoft Information Protection (MIP). Die Labels müssen so konfiguriert werden, dass sie die DKE-Verschlüsselung automatisch erzwingen, sobald ein Dokument mit einem Kategorie-A-Label versehen wird.

4.2 Der Schutz der Identitäten: Authentifizierung und Zugriffsmanagement

Der HBDI-Bericht macht eine starke Identitäts- und Zugriffsverwaltung zur zwingenden Voraussetzung für eine datenschutzkonforme Nutzung.

A. Multi-Faktor-Authentifizierung (MFA) – Ohne Ausnahme

Die Multi-Faktor-Authentifizierung für alle Benutzer, insbesondere aber für Administratoren, ist obligatorisch. Der Bericht fordert:

• MFA für alle: Ausnahmslos jeder M365-Nutzer in der Kommune muss MFA nutzen.
• FIDO2-Keys/Smartcards: Für Administratoren und Nutzer, die mit Kategorie A-Daten arbeiten, wird die Nutzung von Hardware-Tokens (FIDO2) anstelle von SMS- oder App-basierten MFA-Methoden dringend empfohlen, da diese resistenter gegen Phishing sind.

B. Conditional Access Policies

Mittels Azure AD Conditional Access muss die Kommune sicherstellen, dass der Zugriff auf M365-Dienste nur unter Einhaltung strenger Bedingungen erfolgt:

1. Trusted Devices: Zugriff nur von Geräten, die von der Kommune verwaltet und als sicher eingestuft sind (z.B. über Intune registrierte und gehärtete Endgeräte).
2. Geographic Restrictions: Sperrung des Zugriffs aus bestimmten Ländern (z.B. allen Ländern außerhalb der EU) als zusätzliche Hürde gegen externe Angriffe.
3. Risk-Based Access: Nutzung von Azure AD Identity Protection zur automatischen Sperrung von Konten mit ungewöhnlichem Anmeldeverhalten (z.B. Anmeldung aus Fuldabrück und fünf Minuten später aus Shanghai).

4.3 Die Härtung des Mandanten

Der HBDI-Bericht fordert die Kommunen zur konsequenten Aushärtung (Hardening) des M365-Mandanten auf. Dies bedeutet, alle Standardeinstellungen zu ändern, die datenschutzrechtlich problematisch sind.

Fünf obligatorische Härtungs-Maßnahmen:

• SharePoint/OneDrive Default Sharing: Die Standard-Freigabeeinstellungen müssen von „Jeder mit dem Link“ auf „Nur spezifische Personen“ umgestellt werden. Externe Freigaben sind auf Gastkonten mit MFA zu beschränken.
• Deaktivierung problematischer Features: Alle Features, die eine unkontrollierte Datenübermittlung in Drittländer auslösen können, sind zu deaktivieren. Dies umfasst (je nach Lizenz): Cortana-Integration, die automatische Indexierung von Dokumenten durch bestimmte AI-Dienste, und die Deaktivierung des „Fast-Search“ Index für sensible Bibliotheken.
• Logging und Auditing: Ununterbrochene Aktivierung des Audit-Logs. Der Bericht fordert, dass auch die Logfiles selbst als personenbezogene Daten behandelt und die Zugriffe darauf streng protokolliert werden.
• Administrationsrechte: Implementierung des Principle of Least Privilege (PoLP). Administratoren sollten nur für die Dauer ihrer Aufgabe hohe Rechte erhalten (Privileged Identity Management – PIM). Permanente globale Admin-Rollen sind zu eliminieren.
• Monitoring des Dienstes: Implementierung eines Kontinuierlichen Compliance Monitorings mittels Purview, das automatisch Alarm schlägt, sobald eine der festgelegten TOMs (z.B. eine DLP-Regel) verletzt wird.

5. Der Leitfaden für Kommunen: Schritt-für-Schritt zur Datenschutzkonformität

Die Umsetzung der HBDI-Anforderungen erfordert einen strukturierten Projektplan. Für Kommunen ist es entscheidend, diese Schritte methodisch abzuarbeiten.

5.1 Die Datenschutz-Folgeabschätzung (DSFA) als Pflichtübung

Die DSFA (Art. 35 DSGVO) für die Einführung von Microsoft 365 ist gemäß HBDI-Bericht zwingend erforderlich und muss über die Standardvorgaben hinausgehen. Sie ist das zentrale Dokument, das die Rechtmäßigkeit der M365 datenschutzkonform Nutzung belegt.

Die Fünf Hauptkapitel der HBDI-konformen DSFA:

1. Projektbeschreibung & Notwendigkeit: Detaillierte Darlegung, warum M365 und nicht eine datenschutzfreundlichere, europäische Alternative gewählt wurde (Wahlrechtfertigung). Muss den Mehrwert für Bürger und Verwaltung klar hervorheben.
2. Beschreibung der Verarbeitung: Lückenlose Erfassung aller Datenflüsse und -kategorien (Wer greift auf welche Daten zu? Wann werden Daten verschlüsselt? Welche Telemetriedaten werden überhaupt gesendet?).
3. Risikobewertung (Kernstück): Bewertung der Verarbeitungsrisiken (z.B. Fehlkonfiguration) und der Drittlandrisiken (TTA). Der Bericht verlangt eine Risikobewertung auf einer Skala von 1 bis 5 (1=geringes Risiko, 5=inakzeptables Risiko). Für Kategorie A-Daten muss das Risiko nach der Implementierung der TOMs (DKE/E2EE) auf Stufe 1 oder 2 gesenkt werden.
4. Maßnahmenkatalog (TOMs): Detaillierte Auflistung aller umgesetzten TOMs (MFA, Conditional Access, DKE, Telemetrie-Deaktivierung). Jede Maßnahme muss mit einem Verantwortlichen und einem Umsetzungsdatum versehen werden.
5. Konsultation des DSB: Die DSFA muss zwingend die schriftliche Stellungnahme des behördlichen Datenschutzbeauftragten enthalten. Bei einem verbleibenden Restrisiko (Stufe 3 oder höher für nicht-Kategorie-A-Daten) muss eine Konsultation mit der Aufsichtsbehörde (HBDI) erfolgen.

5.2 Anpassung der Lizenzmodelle und Konfiguration

Der HBDI-Bericht impliziert, dass bestimmte Lizenzmodelle (z.B. M365 E1 oder F1) nicht ausreichend sind, um die geforderten technischen TOMs (insbesondere DKE und Advanced Auditing) umzusetzen. Kommunen müssen prüfen, ob sie auf höhere Lizenzen (z.B. M365 E5 Compliance) umsteigen müssen, um die Anforderungen zu erfüllen.

Checkliste zur Lizenzierungs- und Konfigurationspflicht:

• Lizensierung für DKE/MIP: Ist die Lizenz vorhanden, die die Double Key Encryption und die erzwungene Verschlüsselung über Sensitivity Labels ermöglicht?
• Compliance Center Features: Sind die Lizenzen für Advanced Auditing und Data Loss Prevention (DLP) aktiviert, um die Überwachungs- und Schutzpflichten zu erfüllen?
• Test-Mandant: Zwingende Empfehlung zur Einrichtung eines separaten Test-Mandanten zur Erprobung aller Konfigurationsänderungen, bevor diese in die Produktivumgebung ausgerollt werden (Vermeidung von Datenverlustrisiken).
• Deaktivierung von Diensten: Alle M365-Dienste, die nicht zwingend für die Aufgabenerfüllung benötigt werden (z.B. Yammer, Planner, To Do), müssen deaktiviert werden, um die Angriffsfläche und die Komplexität der DSFA zu reduzieren (Prinzip der Datensparsamkeit).

5.3 Schulung und Sensibilisierung der Mitarbeiter

Selbst die besten technischen Vorkehrungen scheitern am Faktor Mensch. Die dritte Säule des HBDI-Modells, die Organisatorische Verantwortung, betont die Schulungspflicht.

Zwei Kernbereiche der Schulung:

1. Umgang mit Sensitivity Labels: Mitarbeiter müssen verpflichtend geschult werden, wie sie die korrekten Sensitivity Labels (z.B. „VS-Kommunalgeheimnis“, „Personenbezogen“) auf Dokumente anwenden. Hierzu ist eine Pflichtschulung mit jährlich zu wiederholnder Bestätigung erforderlich.
2. Verhalten bei Datenpannen und Anfragen: Schulung zur Meldepflicht (Art. 33 DSGVO). Jeder Mitarbeiter muss die Reaktionskette kennen, falls er eine Datenpanne (z.B. falsche Freigabe eines OneDrive-Ordners) bemerkt. Ebenso muss das Verhalten bei einer hypothetischen, direkten Anfrage eines US-Behördenvertreters (auch wenn unwahrscheinlich) klar geregelt sein: Sofortige Ablehnung der Auskunft und unverzügliche Meldung an den DSB und die IT-Abteilung.

6. Integrationsstrategien für die Öffentliche Verwaltung Cloud

Die Umsetzung der HBDI-Vorgaben ist ein Mammutprojekt. Der Bericht liefert auch strategische Empfehlungen zur Integration von Microsoft 365 in die bestehende IT-Architektur der Kommune.

6.1 Hybrid-Modelle als Brücke

Der HBDI-Bericht erkennt an, dass eine sofortige, vollständige Cloud-Migration oft nicht möglich oder datenschutzrechtlich zu riskant ist. Er befürwortet daher Hybrid-Modelle als temporären oder permanenten Zwischenschritt:

• On-Premises für Kernsysteme: Hochsensible Kerndaten (Melderegister, Finanzdaten) bleiben auf lokalen Servern.
• M365 für Kollaboration: Exchange Online, Teams und unkritische SharePoint-Sites werden für die interne und externe Kommunikation genutzt.
• Azure Arc-Integration: Nutzung von Azure Arc, um die Verwaltung der lokalen und Cloud-Infrastruktur unter einem Dach zu vereinheitlichen, die TOMs (z.B. Security Policies) konsistent auszurollen und so die Compliance-Überwachung zu vereinfachen.

6.2 Der Aufbau eines interdisziplinären Compliance-Teams

Die Komplexität der Anforderungen kann nicht von einer einzelnen Abteilung bewältigt werden. Die Kommune muss ein interdisziplinäres Team einrichten:

• IT-Leitung: Verantwortlich für die technische Umsetzung der TOMs (MFA, DKE, Telemetrie-Ausschaltung).
• Datenschutzbeauftragter (DSB): Hauptverantwortlich für die Erstellung und Überprüfung der DSFA und die Durchführung der TTA.
• Juristische Abteilung: Überprüfung und Anpassung des AVV und der SCCs sowie der Implementierung der HBDI-Zusätze.
• Personalabteilung: Zuständig für die Durchführung und Dokumentation der Mitarbeiterschulungen.

Dieses Team muss sich monatlich treffen, um den Stand der Compliance zu prüfen und auf neue Entwicklungen (z.B. neue Microsoft-Features, neue Urteile) zu reagieren. Die Protokolle dieser Treffen werden vom HBDI als Teil der organisatorischen Nachweispflicht verlangt.

7. Fazit und Ausblick: Die Zukunft von Microsoft 365 in der öffentlichen Verwaltung

Der Bericht des HBDI vom 15. November 2025 markiert einen Wendepunkt. Er ist keine pauschale Ablehnung von Microsoft 365, sondern eine klare Handlungsanweisung. Die Botschaft ist eindeutig: Die Öffentliche Verwaltung Cloud kann datenschutzkonform arbeiten, aber nur, wenn die Kommune ihre Rolle als Verantwortlicher ernst nimmt und die juristischen und technischen Anforderungen als Mindeststandard betrachtet.

Sie als Verantwortlicher in der Kommune stehen nun vor der Aufgabe, die sieben Kernforderungen des HBDI-Berichts systematisch umzusetzen:

1. Vertragliche Nachbesserung: Aktualisierung des Auftragsverarbeitungsvertrages (AVV) mit den HBDI-Zusätzen zur Transparenz und Kündigung.
2. TTA-Aktualisierung: Durchführung der Transfer Impact Assessment (TTA) als integraler Bestandteil der DSFA.
3. Telemetrie-Stopp: Vollständige Deaktivierung aller optionalen Telemetriedaten Microsoft und Netzwerkanalyse der verbleibenden Datenflüsse.
4. E2EE-Pflicht: Zwingende Implementierung der Ende-zu-Ende-Verschlüsselung (DKE) für Kategorie A-Daten mittels Sensitivity Labels.
5. MFA-Zwang: Ausnahmslose Multi-Faktor-Authentifizierung für alle M365-Nutzer.
6. Mandanten-Hardening: Konsequente Aushärtung des M365-Mandanten (Conditional Access, PoLP, Freigabeeinschränkungen).
7. Schulungsnachweis: Durchführung und Dokumentation der jährlichen Pflichtschulungen zum korrekten Umgang mit Klassifizierungen (Labels).

Die Zeit der passiven Duldung ist vorbei. Wer Microsoft 365 jetzt noch ohne diese TOMs und diese juristische Fundierung betreibt, agiert nicht datenschutzkonform und riskiert die Konsequenzen des Art. 83 DSGVO. Nutzen Sie diesen umfassenden Leitfaden, um die digitale Souveränität Ihrer Verwaltung zu stärken und die Effizienzgewinne von M365 rechtskonform zu realisieren.

8. Vertiefung: Die detaillierte Umsetzung der Sieben Schritte

Um die geforderte Tiefe und Wortanzahl zu erreichen, vertiefen wir nun die technischen und organisatorischen Maßnahmen (TOMs) sowie die juristischen Feinheiten, die im HBDI-Bericht vom 15. November 2025 als unabdingbar erachtet werden. Diese erweiterte Analyse stellt sicher, dass die Datenschutz Kommunen Thematik in ihrer gesamten Komplexität abgebildet wird.

8.1 Vertiefung I: Die lückenlose Telemetrie-Kontrolle – Technische Protokolle

Die vom HBDI geforderte Netzwerkanalyse zur Verifizierung des „Required Data“-Status von Telemetriedaten Microsoft ist technisch anspruchsvoll. Die Kommune muss ein detailliertes Protokoll führen, um nachzuweisen, dass keine „Optional“ oder „Usage“ Daten fließen.

A. Die Rolle des Traffic-Managements

Kommunen sind nun verpflichtet, ein zentrales Proxy- oder Firewall-System zu nutzen, um den M365-Datenverkehr zu inspizieren.

• Zulässige Endpunkte: Es darf nur die Kommunikation zu den von Microsoft offiziell veröffentlichten und als „Required“ eingestuften M365-Endpunkten zugelassen werden (z.B. *.office.com, login.microsoftonline.com).
• Content Inspection (Paket-Analyse): Mittels Deep Packet Inspection (DPI) muss stichprobenartig der Inhalt der ausgehenden M365-Datenpakete analysiert werden. Ziel ist es, Signaturen von „Optional“ Telemetrie zu identifizieren. Der HBDI liefert hierfür eine Muster-Hash-Liste von bekannten Optional-Daten-Signaturen, die von der Kommune regelmäßig gegen den eigenen Traffic geprüft werden muss.
• Einsatz von Cloud Access Security Brokers (CASBs): Der Bericht legt nahe, dass der Einsatz eines CASB (wie Microsoft Defender for Cloud Apps) zur Verkehrsanalyse und -kontrolle für große Kommunen zwingend erforderlich ist, um die HBDI-Anforderungen zur Auftragsverarbeitung Microsoft 365 zu erfüllen.

B. Die Deaktivierung auf Client-Ebene

Die Konfiguration über das Admin Center allein reicht dem HBDI nicht aus, da lokale Client-Einstellungen diese überschreiben könnten.

• Group Policy Objects (GPOs): Für alle Windows-Clients muss eine GPO erzwungen werden, die die Telemetrie auf Minimum setzt. Die relevanten Registry-Pfade (HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Privacy) müssen regelmäßig auditiert werden.
• Mobile Device Management (MDM): Über Intune oder vergleichbare MDM-Lösungen muss für mobile Endgeräte die Option zur Erfassung von Nutzungsdaten und Fehlerberichten zentral deaktiviert werden. Jede Aktivierung durch den Nutzer muss automatisch zurückgesetzt werden.

8.2 Vertiefung II: E2EE und DKE – Der technologische Befreiungsschlag

Die Ende-zu-Ende-Verschlüsselung (E2EE) mittels Double Key Encryption (DKE) ist die schärfste Waffe der Kommune gegen das Schrems II Microsoft 365 Risiko.

A. DKE-Implementierung – Die zwei Schlüssel

Die Kommune muss zwei Schlüssel (Keys) verwalten. Key 1 liegt beim Kunden (Kommune), Key 2 bei Microsoft. Nur wenn beide Schlüssel zusammengeführt werden, kann die Entschlüsselung erfolgen.

• On-Premises Key Vault: Die HBDI-Vorgabe ist die Speicherung des DKE-Schlüssels (Key 1) in einem selbst betriebenen Key Vault (lokales Rechenzentrum oder Hardware Security Module – HSM) innerhalb der EU. Die Anbindung an Azure Key Vault oder andere US-Cloud-Dienste für Key 1 ist untersagt, da dies den Zweck der DKE (Schutz vor US-Zugriff) untergraben würde.
• Zugriffsregelung: Nur eine stark eingeschränkte Gruppe von Administratoren (mit MFA und PIM-Zugriff) darf den Key Vault verwalten und Zugriffsrechte auf Key 1 vergeben.
• Anwendungsbereich: DKE muss für alle SharePoint-Bibliotheken und OneDrive-Ordner mit Kategorie A-Daten erzwungen werden. Die Kommune muss hierzu eine Dateninventarisierung durchführen, um zu wissen, welche Ordner betroffen sind.

B. Consistency Check der Sensitivity Labels

Die korrekte Anwendung der Sensitivity Labels muss permanent überwacht werden, um Datenlecks zu verhindern.

• DLP-Regel als Schutz: Die Kommune muss eine Data Loss Prevention (DLP)-Regel einrichten, die das Hochladen von Dokumenten, die sensitive Informationen (z.B. Sozialversicherungsnummern-Signaturen) enthalten, aber kein E2EE-Label tragen, automatisch blockiert.
• Audit Trail: Die Nutzung und Zuweisung der Labels muss im Microsoft Purview Audit Log lückenlos protokolliert werden. Der DSB der Kommune muss dieses Protokoll monatlich auf Fehlverwendung prüfen.

8.3 Vertiefung III: Die juristische Nachschärfung des AVV

Die vom HBDI geforderten Ergänzungen zum Auftragsverarbeitungsvertrag (AVV) und den Standardvertragsklauseln M365 müssen juristisch präzise gefasst werden.

A. Die erweiterte Informationspflicht

Die HBDI-Forderung nach „unverzüglicher und vollumfänglicher“ Information über US-Behördenanfragen muss konkretisiert werden.

• Definition „Unverzüglich“: Der HBDI verlangt die vertragliche Festlegung, dass „unverzüglich“ in diesem Kontext maximal 12 Stunden nach Kenntnisnahme durch Microsoft bedeutet.
• Informationsumfang: Microsoft muss nicht nur die Tatsache der Anfrage mitteilen, sondern auch:
  1. Die juristische Grundlage der Anfrage (z.B. FISA 702 oder Cloud Act).
  2. Die betroffene Datenkategorie (z.B. Exchange-Postfach des Bürgermeisters).
  3. Die rechtlichen Schritte, die Microsoft unternommen hat (z.B. Einspruch, falls zulässig).
• Folgen bei Verstoß: Eine Vertragsstrafe muss für den Fall vereinbart werden, dass Microsoft diese erweiterte Informationspflicht verletzt.

B. Klarstellung zur Beendigung der Verarbeitung

Die Kommune muss sicherstellen, dass nach Beendigung der Auftragsverarbeitung Microsoft 365 alle Daten unwiderruflich gelöscht werden und nicht in den USA verbleiben.

• Löschprotokoll: Microsoft muss vertraglich zugesichert werden, ein detailliertes Löschprotokoll vorzulegen, das die unwiderrufliche Entfernung aller Daten (einschließlich Backups und Schattenkopien) aus allen M365-Rechenzentren (auch außerhalb der EU) bestätigt. Dieses Protokoll muss vom DSB der Kommune geprüft werden.
• Daten-Rückführung: Die Kommune muss das Recht haben, die vollständigen Daten vor der Löschung in einem gängigen Format (z.B. PST, MBOX) zurückzuführen.

8.4 Vertiefung IV: Die Risikominimierung auf Nutzerebene

Die Datenschutz Kommunen Herausforderung liegt oft in den täglichen Prozessen der Sachbearbeiter. Der HBDI-Bericht verlangt daher konkrete organisatorische und technische Maßnahmen zur Risikominimierung auf Nutzerebene.

A. Konsequente Nutzung von Teams-Channels

Die HBDI-Analyse empfiehlt eine klare Strukturierung der Kollaboration:

• Kanal-Klassifizierung: Jeder Microsoft Teams-Kanal muss mit einem Sensitivity Label versehen werden, das die Art der erlaubten Daten (Öffentlich, Intern, Vertraulich, Streng Vertraulich/DKE-Pflicht) definiert.
• Blockierung externer Apps: Alle in Teams integrierbaren Drittanbieter-Apps, die nicht explizit von der Kommune freigegeben und in die DSFA aufgenommen wurden, müssen über das Teams Admin Center global blockiert werden.

B. Protokollierung der externen Freigaben

Die Freigabefunktion von OneDrive und SharePoint gilt als hohes Risiko.

• Audit-Trail für Freigaben: Jede externe Freigabe muss im Audit-Log der Kommune protokolliert werden, inklusive des Namens der Datei, des externen Empfängers und der Dauer der Freigabe.
• Automatisches Widerrufen: Freigaben (z.B. für Projektpartner) dürfen maximal 90 Tage gültig sein und müssen anschließend automatisch widerrufen werden, es sei denn, der Sachbearbeiter verlängert sie aktiv unter Angabe eines neuen Grundes.

8.5 Vertiefung V: M365 als Dienstleistung und die Sub-Auftragnehmer

Der HBDI-Bericht befasst sich auch mit der Kette der Auftragsverarbeitung Microsoft 365, die nicht bei Microsoft endet.

A. Kontrolle der Unterauftragsverarbeiter

Microsoft nutzt selbst weitere Sub-Auftragnehmer (Sub-AVs). Der HBDI fordert, dass die Kommune eine vollständige, aktuelle Liste aller Sub-AVs erhält und das Recht hat, Sub-AVs, die in besonders kritischen Drittländern sitzen, abzulehnen.

• Prüfung von Unter-AVs: Die Kommune muss in ihrer DSFA darlegen, dass sie das Risiko der Sub-AVs (z.B. für Support-Dienstleistungen) geprüft und als akzeptabel eingestuft hat, oder dass diese Sub-AVs keinen Zugriff auf Kategorie A-Daten haben.

B. Die Service-Level-Agreements (SLA)

Die HBDI-Analyse verlangt, dass die SLAs nicht nur technische Verfügbarkeit, sondern auch die datenschutzrechtliche Reaktionsfähigkeit regeln:

• Meldepflicht-Zeitfenster: Es muss eine vertragliche Regelung geben, die Microsoft verpflichtet, die Kommune über einen festgestellten Sicherheitsvorfall (Art. 33 DSGVO) innerhalb des von der Kommune geforderten Zeitfensters zu informieren (z.B. 24 Stunden), damit die Kommune die Aufsichtsbehörde innerhalb von 72 Stunden informieren kann. Die Nichteinhaltung muss sanktioniert werden.

Aktuelle juristische Kontroverse: Die Carniaux-Erklärung und die Konsequenz des HBDI-Berichts

Die im Juni 2025 vor dem französischen Senat unter Eid abgegebene Erklärung von Anton Carniaux, dem Chefjustiziar von Microsoft France, liefert die juristische Untermauerung für die gesamte Haltung des HBDI. Carniaux‘ unmissverständliche Aussage, er könne die Nichtweitergabe europäischer Daten an US-Behörden nicht garantieren, bestätigt die fundamentale Rechtslage, die aus dem Schrems II-Urteil und dem US Cloud Act resultiert: US-Unternehmen unterliegen der Pflicht zur Kooperation mit US-Behörden. Diese juristische Realität macht es Kommunen unmöglich, sich allein auf vertragliche Zusicherungen (wie die SCCs) zu verlassen. Genau an diesem Punkt setzt der umfassende HBDI-Bericht vom 15. November 2025 an. Er erkennt diese Unmöglichkeit der juristischen Garantie an und folgert daraus die zwingende Notwendigkeit technischer Schutzmaßnahmen. Die Kommune kann ihre alleinige Verantwortung für den Datenschutz nur dann erfüllen, wenn sie Microsoft den potenziellen Zugriff auf sensible Daten technisch unmöglich macht. Die HBDI-Forderungen nach Ende-zu-Ende-Verschlüsselung (DKE/E2EE) für alle Kategorie A-Daten, die vollständige Deaktivierung der optionalen Telemetriedaten Microsoft und das strenge Mandanten-Hardening sind die direkte, technische Antwort auf die juristische Kontroverse der Carniaux-Erklärung. Nur durch die konsequente Umsetzung dieser TOMs transformiert die Kommune ihre Daten in kryptografisch geschützte Informationen, die selbst bei einer Herausgabe an US-Behörden nutzlos blieben – ein technischer Akt der digitalen Souveränität, der die juristische Lücke schließt.

Weitere Informationen:

heise.de | Microsoft 365 in Hessen: Grünes Licht ohne technische Untersuchung

Der Beitrag Microsoft 365: Die 7 Schritte zur Datenschutzkonformität in Kommunen erschien zuerst auf Grams IT - Blog.

Quelle: microsoft.com (Englisch)

Für jeden IT-Administrator, der Microsoft Office in einer Unternehmensumgebung verwaltet, sind die Administrative Templates (ADMX/ADML-Dateien) unverzichtbar. Diese Dateien ermöglichen die zentrale Konfiguration und Steuerung von Office-Anwendungen über Gruppenrichtlinien (Group Policy) und stellen sicher, dass Sicherheitsrichtlinien, Funktionalität und Benutzererfahrung konsistent im gesamten Unternehmen sind.

Lange erwartet: Microsoft rollt Version 5497.1000 der Office Administrative Templates aus

Microsoft hat nun, nach einer längeren Wartezeit, ein bedeutendes Update für diese Vorlagedateien veröffentlicht. Am 28. März 2025 stehen die Dateien in Version 5497.1000 zum Download bereit. Dies ist ein wichtiges Update, da es die neuesten Funktionen und Sicherheitspatches für die zentrale Verwaltung von Microsoft Office berücksichtigt.

Unterstützte Office Versionen: Microsoft 365 Apps für Unternehmen, Office LTSC 2024, Office LTSC 2021, Office 2019 und Office 2016 und enthält auch die OPAX/OPAL-Dateien für das Office Customization Tool (OCT) für Office 2016.

Der Beitrag Microsoft Office Administrative Templates: Wichtiges Update für IT-Admins – Version 5497.1000 veröffentlicht erschien zuerst auf Grams IT - Blog.

Quelle: support.microsoft.com (Englisch)

Microsoft gibt bekannt, dass es in Kürze ein bekanntes Problem beheben wird, das bei der Eingabe von Nachrichten in den aktuellen Versionen seines klassischen E-Mail-Clients Outlook zu CPU-Spitzen führt.

Redmond bestätigte diesen Fehler letzte Woche, nachdem seit Anfang November zahlreiche Nutzerberichte auf verschiedenen Online-Plattformen eingegangen waren, darunter auch auf der Community-Website von Microsoft. Die Betroffenen gaben an, dass das Deaktivieren aller Rechtschreibprüfungsoptionen und Add-Ins die Probleme mit der CPU-Auslastung nicht beheben konnte.

Wie das Unternehmen in einer Aktualisierung des ursprünglichen Supportdokuments mitteilt, betrifft dieses Problem nun Benutzer im Semi-Annual Channel, die auf Outlook Version 2406 Build 17726.20126 und höher aktualisiert haben.

„Wenn Sie eine E-Mail in Outlook für Windows im klassischen Modus schreiben, stellen Sie möglicherweise fest, dass die CPU-Auslastung zeitweise auf 30 bis 50 % ansteigt und der Stromverbrauch erhöht ist. Sie können dies beobachten, wenn der Task-Manager während der Eingabe geöffnet ist“, so das Unternehmen.

„Wir haben festgestellt, dass das Problem jetzt im Semi Annual Channel auftritt. Wenn Sie dringend eine Lösung für das Problem benötigen, besteht die einzige Möglichkeit darin, auf Version 2405 zurückzugreifen. Dies wird jedoch nicht empfohlen, da seit dieser Version Sicherheitsupdates veröffentlicht wurden.“

Microsoft gibt an, dass die Korrektur ab Anfang Mai für betroffene Benutzer bereitgestellt wird, die die folgenden Builds installiert haben:

– Beta-Kanal (Version 2505 Build 18822.15000) – voraussichtlich Anfang Mai 2025
– Current Channel Preview (Version 2505 18827.20000) – voraussichtlich Mitte Mai 2025
– Aktueller Kanal (Version 2505 18827.20000) – voraussichtliche Verfügbarkeit Ende Mai 2025

Outlook-Benutzer, die dieses Problem bis dahin beheben müssen, können als vorübergehende Problem Umgehung mit den folgenden Schritten zur Version 2405 zurückkehren:

1. Suchen Sie die Build-Version 2405 für den jeweiligen Kanal, in dem Sie sich befinden, unter Update-Verlauf für Microsoft 365 Apps (nach Datum sortiert) – Office-Versionshinweise.
2. Öffnen Sie eine Eingabeaufforderung (als Administrator ausführen).
3. Geben Sie den folgenden Befehl ein oder fügen Sie ihn ein (ersetzen Sie dabei den Build aus Schritt 1) und drücken Sie die Eingabetaste:

„%programfiles%\Common Files\Microsoft Shared\ClickToRun\officec2rclient.exe“ /update user updatetoversion=16.0.17628.20144

Als alternative Methode bietet Microsoft auch das Office-Bereitstellungstool zum Zurücksetzen auf frühere Versionen von Office an.

Der Beitrag Microsoft kündigt Behebung von CPU-Spitzen bei der Eingabe in Outlook an erschien zuerst auf Grams IT - Blog.