Rollendrift und Sicherheitslücken sind zwei Seiten desselben Problems. Wenn die Lizenzierung nicht mehr widerspiegelt, wie Menschen arbeiten oder welchen Bedrohungen sie ausgesetzt sind, ist die Durchsetzungsebene Ihres Betriebsmodells bereits veraltet.
In den ersten beiden Beiträgen dieser Serie (blog 1: Identity Entropy und blog 2: Governance Debt Hiding in Plain Sight), ging es um Identity Entropy und verwaiste Accounts. Beide Probleme entstehen aus derselben Realität: Microsoft 365 verändert sich langsamer als die Unternehmen, die darauf arbeiten.
Es gibt jedoch ein drittes Muster. Weniger sichtbar. Oft gefährlicher.
Viele Unternehmen arbeiten heute mit Lizenz- und Sicherheitsmodellen, die nicht mehr der Realität entsprechen. Rollen haben sich verändert. Verantwortlichkeiten haben sich verschoben. Sicherheitsrisiken ebenfalls.
Die Lizenzierung hingegen basiert oft noch auf Annahmen aus vor zwei oder drei Jahren. Das Resultat:
Die technische Kontrollschicht passt nicht mehr zur Organisation.
Und genau dort entsteht das eigentliche Risiko.
Microsoft-365-Lizenzen werden meist einmal sauber vergeben:
Danach wird nur noch punktuell angepasst. Das Problem: Rollen bleiben nicht statisch. Mit der Zeit:
Die Lizenz bleibt trotzdem oft dieselbe. Das nennt man Role Drift. Die Lizenz bildet nicht mehr die aktuelle Funktion ab, sondern die Vergangenheit.
Viele Unternehmen betrachten Lizenzabweichungen primär als Optimierungsthema:
Das greift zu kurz. In Microsoft 365 steuern Lizenzmodelle direkt, welche Sicherheitsmechanismen überhaupt technisch verfügbar sind:
Wenn Rollen wachsen, die Lizenzierung jedoch stehen bleibt, entstehen Sicherheitslücken nicht durch Fehlverhalten, sondern durch organisatorische Drift.
Ein Mitarbeiter mit erweiterten Compliance-Aufgaben hat möglicherweise nicht die notwendigen DLP-Funktionen.
Ein anderer besitzt weiterhin Enterprise-Rechte, obwohl die Rolle längst vereinfacht wurde.
Die Sicherheitsarchitektur wird inkonsistent. Und Inkonsistenz ist auditrelevant. Auch ohne Sicherheitsvorfall.
Noch problematischer ist eine zweite Form der Fehlanpassung. Viele KMU haben Sicherheitsfunktionen lizenziert, aber nie vollständig umgesetzt.
Das passiert ständig:
Die Funktion existiert im Tenant, aber nicht im Betrieb. Typische Beispiele:
Die Rechnung suggeriert Sicherheit. Die Realität oft nicht. Eine Lizenz ist keine Schutzmassnahme. Erst Konfiguration und Durchsetzung machen daraus Kontrolle.
Viele CIOs interpretieren eine stabile Microsoft-365-Rechnung als Zeichen von Kontrolle. Keine Überraschungen. Keine Eskalation. Alles ruhig.
Aber stabile Kosten bedeuten nicht, dass die Sicherheitsarchitektur noch zur Organisation passt. Im Gegenteil: Genau dort verstecken sich oft:
In anderen Bereichen würden solche Inkonsistenzen sofort auffallen. Wenn Produktionssysteme an jedem Standort unterschiedlich konfiguriert wären, wäre das Problem sichtbar. Bei Identitäten, Lizenzen und Zugriffsmodellen bleibt die Fehlanpassung oft jahrelang unsichtbar.
Bis ein Audit kommt, oder ein Incident.
Die Ursachen sind selten technisch. Sie sind organisatorisch.
Gerade in KMU ist das nachvollziehbar. Der Fokus liegt auf Betrieb, Verfügbarkeit und Delivery. Aber Microsoft-365-Lizenzierung ist heute kein administratives Nebenthema mehr. Sie definiert direkt:
Nicht permanente Reorganisation, sondern regelmässige Re-Baselining-Prozesse. Konkret bedeutet das:
Das ist keine „Lizenzoptimierung“ - Das ist operative Governance.
Die meisten Unternehmen brauchen keinen externen Benchmark, um ihre Situation einzuschätzen.
Drei Fragen reichen:
Wenn diese Prozesse nicht klar definiert sind, bestehen die Lücken mit hoher Wahrscheinlichkeit bereits. Nicht wegen fehlender Kompetenz, sondern weil Organisationen sich schneller verändern als ihre Kontrollmechanismen.
Role Drift und Security Capability Gaps erzeugen selten sofort sichtbare Probleme.
Keine Alerts.
Keine roten Warnlampen.
Keine auffälligen Rechnungen.
Aber kleine Fehlanpassungen summieren sich über Jahre:
Die entscheidende Frage lautet deshalb nicht, ob diese Lücken existieren. Sondern ob das Unternehmen definiert hat, wann und wie sie systematisch korrigiert werden. Bevor ein Audit, ein Security Incident oder die nächste Microsoft-Preisrunde daraus ein dringendes Problem macht