MFA in Microsoft 365: Warum "der Betriebsrat ist dagegen" kein Ende der Diskussion ist

Wer über MFA diskutiert, unterschätzt häufig, was an einem einzelnen Konto hängt. Ein kompromittiertes Microsoft-365-Konto ist kein Postfach. Es ist:

• Der gesamte Mailverlauf, inklusive aller jemals empfangenen Anhänge – oft über Jahre.

• Der Dateizugriff auf SharePoint und OneDrive, in vielen Umgebungen also auf die zentrale Dokumentenablage.

• Teams-Chats und Kanäle, in denen erfahrungsgemäß offener kommuniziert wird als per Mail.

• Eine vertrauenswürdige Absenderidentität für Angriffe auf Kollegen, Kunden und Lieferanten. Eine Rechnungsmanipulation aus einem echten internen Postfach heraus ist für den Empfänger praktisch nicht als Angriff erkennbar.

• Ein Sprungbrett in weitere Dienste, die per Single Sign-on an derselben Identität hängen.

Ohne zweiten Faktor genügt für all das ein Passwort. Und Passwörter sind nach einem Vorfall wie dem beschriebenen genau das, was man nicht mehr als geheim behandeln darf.

Warum "wir überwachen doch die Anmeldungen" nicht reicht

Ein häufiges Gegenargument lautet: Auffällige Anmeldungen fallen doch auf. Das stimmt und es ist trotzdem kein Ersatz.

Erkennung setzt voraus, dass sich jemand auffällig verhält. Ein Angreifer, der ein gültiges Passwort besitzt, sich zu normalen Arbeitszeiten anmeldet und zunächst nur liest, verhält sich per Definition unauffällig. Erkennung schlägt an, wenn etwas passiert. MFA verhindert, dass es überhaupt so weit kommt.

Anders gesagt: Erkennung ist Schadensbegrenzung, MFA ist Schadensverhinderung. Wer nur eines von beidem hat, sollte wissen, welches der beiden den Vorfall verhindert.

1. Der Aufwand explodiert

Ohne zweiten Faktor gilt nach einem Vorfall dieser Größenordnung jedes betroffene Passwort als kompromittiert. Das bedeutet nicht "ein paar Kennwörter zurücksetzen", sondern:

• Zurücksetzen sämtlicher betroffener Konten in kurzer Zeit

• Invalidierung bestehender Sitzungen und Aktualisierungstoken, denn sonst arbeitet ein Angreifer mit einer laufenden Sitzung einfach weiter

• Neuverteilung der Zugangsdaten an die Belegschaft, organisatorisch sauber und nachweisbar

• Prüfung, welche Konten zwischenzeitlich Postfachregeln, Weiterleitungen oder App-Berechtigungen erhalten haben

• Betreuung von hunderten Mitarbeitenden, die alle gleichzeitig nicht arbeiten können

In der beschriebenen Umgebung sollte all das ein einzelner interner Administrator leisten. Das ist kein Nachmittag, das ist ein Projekt unter Zeitdruck, parallel zum laufenden Incident.

Hier liegt das Argument, das in Budgetgesprächen am besten funktioniert: Ein einziger Vorfall ohne MFA erzeugt mehr Arbeit als die vollständige Einführung von MFA. Der Unterschied ist, dass die Einführung planbar ist und der Vorfall nicht.

2. Die Cyberversicherung

Der Kunde verwies auf seine Cyberversicherung. Auf den Hinweis, dass diese ohne MFA möglicherweise nicht leisten werde, kam die naheliegende Antwort: "MFA steht nicht in unserer Police."

Das ist häufig sogar zutreffend und trotzdem kein Schutz. Denn Cyberpolicen arbeiten mit Obliegenheiten, also vertraglichen Pflichten des Versicherungsnehmers. Eine in der einen oder anderen Formulierung fast überall anzutreffende Klausel lautet sinngemäß:

> "Der Versicherungsnehmer hat angemessene technische und organisatorische Maßnahmen nach dem aktuellen Stand der Technik zu treffen."

Der entscheidende Begriff ist "Stand der Technik". Er ist bewusst dynamisch formuliert und verweist auf das, was zum Schadenzeitpunkt üblich und verfügbar ist und nicht auf das, was bei Vertragsabschluss galt. Auch Versicherer stellen zunehmend Anforderungen an das Sicherheitsniveau eines Unternehmens. Welche konkreten Obliegenheiten gelten und welche Auswirkungen fehlende Sicherheitsmaßnahmen im Schadenfall haben können, hängt von der jeweiligen Police und den gemachten Risikoangaben ab.

Unternehmen sollten deshalb nicht erst nach einem Vorfall prüfen, welche technischen und organisatorischen Anforderungen ihr Versicherungsvertrag tatsächlich vorsieht.

> ACHTUNG: Auch die Angaben im Antragsformular gehören zu dieser Prüfung. Die Bewertung des konkreten Vertrags ist eine Frage für Ihren Makler oder Versicherer, nicht für die IT allein.

3. Der Datenschutz und warum sensible Daten alles verschärfen

Nach Art. 32 DSGVO müssen Verantwortliche technische und organisatorische Maßnahmen treffen, die ein dem Risiko angemessenes Schutzniveau gewährleisten. Auch hier ist der Maßstab der Stand der Technik. Für Zugänge zu einer Cloud-Umgebung, die von überall auf der Welt erreichbar ist, gilt reine Passwort-Authentifizierung fachlich schon länger nicht mehr als angemessen.

Werden – wie in diesem Fall – besonders schützenswerte personenbezogene Daten verarbeitet, können die Auswirkungen eines kompromittierten Benutzerkontos besonders gravierend sein. Neben der technischen Aufarbeitung muss deshalb auch geprüft werden, welche datenschutzrechtlichen Melde- und Informationspflichten sich aus dem konkreten Vorfall ergeben. Die Fristen dafür sind kurz.

Die konkrete rechtliche Bewertung sollte durch den Datenschutzbeauftragten beziehungsweise eine entsprechende rechtliche Beratung erfolgen. Für die IT bleibt die praktische Konsequenz: Je sensibler die verarbeiteten Daten, desto weniger vertretbar ist ein Zugang, der nur durch ein Passwort geschützt ist.

Und damit sind wir bei dem Punkt, der sich nicht versichern lässt.

4. Der Vertrauensverlust

Ein Produktionsausfall ist ärgerlich und wird vergessen. Betroffene darüber informieren zu müssen, dass ihre sensiblen persönlichen Daten möglicherweise in fremde Hände geraten sind, ist etwas anderes.

Dieser Brief lässt sich nicht zurücknehmen. Er wird weitergereicht, er landet in der Lokalpresse, er wird zitiert. Betroffene fragen anschließend nicht nach Ihrer Architektur, sondern danach, ob Sie das Nötige getan haben. Wenn die Antwort lautet, dass eine seit Jahren als Standard geltende Schutzmaßnahme aus internen Gründen nicht eingeführt wurde, ist diese Diskussion verloren, bevor sie beginnt.

Der Schaden aus einem Vorfall ist bezifferbar und weitgehend versicherbar. Der Vertrauensverlust ist beides nicht.

In dem geschilderten Fall lautete die Begründung gegen MFA: Der Betriebsrat hatte dagegen gestimmt. Die Argumente waren die üblichen: Mitarbeitende wollen keine Firmen-App auf dem privaten Telefon und eine SMS an die private Nummer möchte auch niemand.

Diese Frage wird in Kundengesprächen regelmäßig als Endpunkt behandelt. Das ist sie nicht.

> Hinweis: Was folgt, ist eine Einordnung aus der Projektpraxis und ausdrücklich keine Rechtsberatung. Die arbeitsrechtliche Bewertung im Einzelfall gehört zu den entsprechenden Fachleuten.

In Unternehmen mit Betriebsrat sollte die konkrete Ausgestaltung eines MFA-Rollouts frühzeitig abgestimmt werden. Dabei geht es häufig weniger um MFA an sich als um die Frage, welche Authentifizierungsmethoden eingesetzt werden, welche Daten dabei entstehen und ob Beschäftigte private Geräte verwenden sollen.

Genau darin liegt auch der praktische Ausweg. Wer die Diskussion als "MFA ja oder nein" führt, verhandelt meist über den falschen Gegenstand. Die tragfähigere Frage lautet: Welches Verfahren führen wir für welche Benutzergruppe unter welchen Bedingungen ein? MFA-Projekte können organisatorische und mitbestimmungsrechtliche Fragen auslösen. Das ist ein guter Grund, sie sauber zu planen und die Mitarbeitervertretung früh einzubinden, aber kein Grund, das Thema Sicherheit auf unbestimmte Zeit liegen zu lassen.

Und die Einwände sind teilweise berechtigt

Ein Punkt, den IT-Abteilungen ungern hören: Beim privaten Telefon ist der Einwand berechtigt.

Ein MFA-Konzept sollte nicht darauf beruhen, dass Beschäftigte zwingend ihr privates Smartphone oder ihre private Mobilfunknummer zur Verfügung stellen. Das ist ein legitimer Diskussionspunkt, und er lässt sich nicht wegdiskutieren.

Wer die MFA-Einführung auf "alle installieren den Authenticator auf ihrem Handy" aufbaut, baut sie damit auf einer Annahme auf, die in der Praxis nicht trägt.

Die gute Nachricht: Dieses Problem ist rein technisch lösbar.

Der Konflikt "MFA gegen Betriebsrat" ist in den allermeisten Fällen gar kein Konflikt über MFA. Er ist ein Konflikt über ein bestimmtes Verfahren. Wechselt man das Verfahren, verschwindet der Einwand.

Microsoft Entra ID unterstützt mehrere Methoden, die ohne privates Gerät auskommen:

FIDO2-Sicherheitsschlüssel: Ein Hardware-Token per USB oder NFC, das der Arbeitgeber stellt. Phishing-resistent, kein Gerät des Mitarbeiters, keine Berührung mit dem Privatleben. Aus Sicherheitssicht die derzeit stärkste breit einsetzbare Option und der Einwand "nicht auf mein Handy" läuft vollständig ins Leere.

Passkeys: Technisch die Weiterentwicklung desselben Prinzips, ebenfalls auf Sicherheitsschlüsseln oder verwalteten Geräten speicherbar. Microsoft macht Passkeys ab dem 1. September 2026 zur bevorzugten Methode und fordert betroffene Nutzer aktiv zur Registrierung auf.

Windows Hello for Business: Der zweite Faktor steckt im Arbeitsgerät selbst, kryptografisch abgesichert über das TPM des Rechners. Nutzbar über eine PIN oder optional über biometrische Merkmale. Windows Hello ist ausdrücklich kein rein biometrisches Verfahren, die PIN ist ein vollwertiger Bestandteil. Biometrische Referenzdaten verbleiben lokal und verschlüsselt auf dem jeweiligen Endgerät und werden nicht an zentrale Server übertragen. Dennoch sollte der Einsatz biometrischer Verfahren im Beschäftigtenumfeld datenschutzrechtlich und mit der Mitarbeitervertretung abgestimmt werden. Für Beschäftigte mit festem Arbeitsplatzrechner ist das im Alltag die reibungsärmste Variante, weil kein zusätzlicher Handgriff anfällt.

Zertifikatsbasierte Authentifizierung: Sinnvoll dort, wo bereits eine PKI und Smartcards existieren, etwa in Umgebungen mit Ausweiskarten für Zutritt oder Druckerfreigabe.

OATH-Hardware-Token: Kleine Displaygeräte, die alle 30 Sekunden einen Code erzeugen. Technisch das schwächste der genannten Verfahren, aber die pragmatische Lösung für Arbeitsplätze ohne eigenen Rechner, in der Produktion oder dort, wo Mobiltelefone ohnehin nicht erlaubt sind.

Diensthandy mit Microsoft Authenticator: Vollkommen unproblematisch, wenn das Gerät gestellt wird. Der Einwand richtet sich nie gegen die App, sondern gegen das Privatgerät.

Freiwillig das Privatgerät: Möglich und für einen erheblichen Teil der Belegschaft die bequemste Variante, aber als echtes Wahlangebot, nicht als Vorgabe. Eine Betriebsvereinbarung kann diese Freiwilligkeit ausdrücklich festhalten, was erfahrungsgemäß viel Widerstand auflöst.

> ACHTUNG: Bauen Sie eine neue MFA-Strategie nicht primär auf SMS auf. Microsoft stellt zum 1. Februar 2027 die eigene Bereitstellung von SMS- und Sprachanrufen für die Entra-Authentifizierung ein und treibt den Wechsel zu moderneren, phishing-resistenten Authentifizierungsverfahren weiter voran. Unabhängig vom konkreten Datum würden wir heute kein MFA-Projekt mehr auf SMS ausrichten – schon deshalb, weil SMS-Codes die schwächste der verfügbaren Methoden sind.

In der Praxis bewährt sich selten eine einzige Methode, sondern eine Zuordnung nach Arbeitsplatztyp:

| Gruppe | Empfohlenes Verfahren |

|---|---|

| Büroarbeitsplatz mit festem Rechner | Windows Hello for Business, Sicherheitsschlüssel als Rückfallebene |

| Außendienst, Führungskräfte, mobile Nutzer | Diensthandy mit Authenticator oder Sicherheitsschlüssel (NFC) |

| Produktion, Lager, Schichtbetrieb ohne festen Rechner | FIDO2-Schlüssel oder OATH-Token am Schlüsselbund |

| Administrative Konten | Ausschließlich phishing-resistente Verfahren, keine Ausnahmen |

| Dienst- und Notfallkonten | Sicherheitsschlüssel oder Zertifikat, dokumentiert und sicher verwahrt |

Die folgende Reihenfolge hat sich bewährt, weil sie den Rollout jederzeit anhaltbar und für den Betriebsrat nachvollziehbar hält.

Schritt 1 – Bestandsaufnahme: Ermitteln Sie zunächst, wer heute bereits MFA nutzt und über welche Methode. Im Entra Admin Center liefert der Bericht unter *Schutz → Authentifizierungsmethoden → Registrierung von Authentifizierungsmethoden* den Ausgangsstand. Diese Zahl ist zugleich der beste Einstieg ins Betriebsratsgespräch, weil sie zeigt, wie viele Menschen tatsächlich betroffen sind.

Schritt 2 – Methoden freischalten, bevor Sie etwas erzwingen. Unter *Schutz → Authentifizierungsmethoden → Richtlinien* aktivieren Sie genau die Verfahren, auf die Sie sich mit dem Betriebsrat verständigt haben und deaktivieren die, die Sie nicht wollen. Wer SMS gar nicht erst anbietet, muss später nicht darüber streiten.

Schritt 3 – Registrierung ermöglichen, ohne auszusperren. Über eine Registrierungskampagne und über den *Temporary Access Pass* lassen sich Beschäftigte zur Einrichtung bewegen beziehungsweise bei der Ersteinrichtung unterstützen, ohne dass bereits jemand ausgesperrt wird. Der Temporary Access Pass ist ein zeitlich begrenzter Einmalcode, den der Helpdesk ausstellt – das Werkzeug, mit dem ein Rollout ohne Aussperr-Chaos gelingt.

Schritt 4 – Bedingten Zugriff im Nur-Bericht-Modus. Legen Sie die Richtlinie an, die MFA erfordert, und setzen Sie sie zunächst auf *Nur Bericht*. Sie sehen dann in den Anmeldeprotokollen, welche Anmeldungen die Richtlinie blockiert hätte, ohne dass tatsächlich jemand blockiert wird. Lassen Sie das mindestens zwei Wochen laufen und werten Sie die Treffer aus. Dieselbe Logik wie bei jeder anderen Härtungsmaßnahme: erst messen, dann erzwingen.

> ACHTUNG: Bedingter Zugriff setzt eine Lizenz Entra ID P1 voraus, die unter anderem in Microsoft 365 Business Premium und E3 enthalten ist. Ohne P1 bleiben die Sicherheitsstandards ("Security Defaults") als Alternative – die funktionieren, sind aber nicht granular steuerbar und lassen sich nicht schrittweise ausrollen.

Schritt 5 – Wellenweise erzwingen: Beginnen Sie mit den administrativen Konten, dann eine Pilotgruppe, dann Abteilung für Abteilung. Für administrative Zugänge ist das ohnehin keine Wahl mehr: Microsoft erzwingt MFA für die Anmeldung an den Administrationsportalen bereits verbindlich.

Schritt 6 – Altlasten schließen: Ein MFA-Rollout ist wirkungslos, solange Anmeldungen über Verfahren möglich sind, die MFA nicht unterstützen. Prüfen und blockieren Sie die Legacy-Authentifizierung. Achten Sie außerdem darauf, dass nach einer Kompromittierung bestehende Sitzungen und Aktualisierungstoken invalidiert werden. Ein zurückgesetztes Passwort allein wirft einen Angreifer nicht zwangsläufig hinaus.

Schritt 7 – Betriebsvereinbarung: Halten Sie fest, welche Verfahren angeboten werden, dass die Nutzung privater Geräte freiwillig ist, welche Daten bei der Anmeldung anfallen, wie lange diese aufbewahrt werden, wer sie zu welchem Zweck einsehen darf und dass keine Leistungs- oder Verhaltenskontrolle stattfindet. Genau diese Zusagen ermöglichen dem Betriebsrat die Zustimmung und sie kosten Sie in der Sache nichts, weil Sie die Daten ohnehin nicht zur Verhaltenskontrolle verwenden wollen.

| Rahmenwerk | Bezug |

|---|---|

| DSGVO | Art. 32 (Sicherheit der Verarbeitung), Art. 9 (besondere Kategorien personenbezogener Daten), Art. 33/34 (Meldung und Benachrichtigung) |

| ISO/IEC 27001:2022 | Anhang A, 5.15 Zugangssteuerung, 5.17 Authentifizierungsinformationen, 8.5 Sichere Authentifizierung |

| BSI IT-Grundschutz | ORP.4 Identitäts- und Berechtigungsmanagement |

| NIS2 | Maßnahmen nach Art. 21, ausdrücklich einschließlich Multi-Faktor-Authentifizierung |

| Mitbestimmung | Ausgestaltung des Rollouts – Bewertung im Einzelfall durch arbeitsrechtliche Beratung |

| Cyberversicherung | Obliegenheiten und Auflagen der jeweiligen Police, insbesondere "Stand der Technik" |

Der geschilderte Fall ging glimpflich aus. Das war Glück, nicht Architektur.

Was bleibt, ist eine Rechnung, die sich jedes Unternehmen selbst aufmachen kann. Auf der einen Seite ein planbares Projekt: Methodenauswahl, Betriebsvereinbarung, Beschaffung von Hardware-Token, wellenweiser Rollout. Auf der anderen Seite ein ungeplanter Vorfall, bei dem in wenigen Tagen hunderte Zugangsdaten zurückgesetzt, Meldefristen eingehalten, Betroffene benachrichtigt und Fragen der Versicherung beantwortet werden müssen.

Und die Betriebsratsfrage? Sie ist ein guter Grund, einen MFA-Rollout sauber zu planen und die Mitarbeitervertretung früh einzubinden, aber kein Grund, das Thema liegen zu lassen. In der Praxis lösen sich die meisten dieser Konflikte ohnehin auf, sobald man aufhört, über das private Telefon zu reden, und anfängt, über Sicherheitsschlüssel zu reden.

Wenn Sie wissen möchten, welche Verfahren in Ihrer Umgebung realistisch umsetzbar sind, welche Vorarbeit ein Rollout braucht und wie eine tragfähige Betriebsvereinbarung dazu aussieht: Sprechen Sie uns an. Der erste Schritt ist eine Bestandsaufnahme, und die tut niemandem weh.