Ein MFA-Rollout scheitert selten an der Technik. Er scheitert daran, dass am Stichtag Menschen ohne Diensthandy vor einem Anmeldefenster sitzen, dass niemand weiß, wie ein verlorener Faktor zurückgesetzt wird, und dass die Ausnahmeliste nach drei Monaten länger ist als die Nutzerliste. Diese Seite beschreibt den Ablauf, der das verhindert: Verfahren nach Nutzergruppe auswählen, in vier Wellen ausrollen, den Wiederherstellungsweg vorher festlegen – und Ausnahmen befristen statt begründen.
Das Wichtigste in Kürze
- Die Reihenfolge lautet: Wiederherstellungsweg klären, Pilot, administrative Konten, Belegschaft, Ausnahmen abbauen. Rund acht Wochen für 200 bis 500 Konten.
- Administrative Konten zuerst. Sie sind die Konten, deren Übernahme den Schaden ausmacht, und ihre Zahl ist klein genug, um Fehler im Verfahren früh zu bemerken.
- Nur FIDO2-Sicherheitsschlüssel und Passkeys sind phishing-resistent. Push-Bestätigung und Einmalcodes schützen gegen gestohlene Kennwörter, aber nicht gegen eine Anmeldeseite, die die Eingabe in Echtzeit weiterreicht.
- Für jede Person braucht es zwei registrierte Faktoren. Mit nur einem ist jeder Geräteverlust ein Helpdesk-Fall mit Identitätsprüfung.
- Der Wiederherstellungsweg ist der eigentliche Schwachpunkt: Wer sich am Telefon als vergesslich ausgeben kann, umgeht die gesamte Maßnahme. Rückstellung nur mit belegter Identität.
- Mindestens zwei Notfallkonten ohne MFA, mit langem Kennwort, dokumentiert hinterlegt und mit Alarm bei Anmeldung. Sonst sperrt eine fehlerhafte Richtlinie die eigene Organisation aus.
- Rechtlich: § 30 Abs. 2 Nr. 10 BSIG nennt Multi-Faktor-Authentifizierung ausdrücklich als Risikomanagementmaßnahme. In der ISO/IEC 27001:2022 liegt der Bezug in den Maßnahmen 5.17 und 8.5.
- SMS-Codes bleiben ein Rückfallweg, kein Zielzustand. Wer sie einsetzt, sollte den Grund und das Ablaufdatum notieren.
Verfahren und was sie leisten
Die Auswahl fällt leichter, wenn man sie an einer Frage aufhängt: Schützt das Verfahren auch dann, wenn jemand auf einer täuschend echten Anmeldeseite landet? Danach zerfällt die Liste in zwei Gruppen.
| Verfahren | Phishing-resistent | Passend für | Einschränkung |
|---|---|---|---|
| FIDO2-Sicherheitsschlüssel | Ja | Administrative Konten, Zugriff auf besonders schützenswerte Daten, Personen ohne Diensthandy | Beschaffung und Ersatz kosten Geld; zwei Schlüssel je Person einplanen |
| Passkey auf dem Gerät | Ja | Die Belegschaft, wenn verwaltete Geräte vorhanden sind | An Gerät oder Konto des Herstellers gebunden; Wiederherstellung vorher klären |
| Push-Bestätigung mit Zahlenabgleich | Nein | Breite Einführung mit geringem Aufwand | Ohne Zahlenabgleich anfällig für Bestätigungsmüdigkeit |
| Einmalcode aus einer App (TOTP) | Nein | Systeme ohne moderne Anbindung, externe Dienstleister | Code lässt sich in Echtzeit weiterleiten |
| Code per SMS oder Anruf | Nein | Rückfallweg, Personen ohne Smartphone | Rufnummernübernahme und Weiterleitung möglich; befristet einsetzen |
Für die meisten Organisationen ist die tragfähige Kombination: Passkey oder Push für alle, FIDO2-Schlüssel für administrative Konten, ein Einmalcode-Verfahren als zweiter registrierter Faktor. Wer Personen ohne Smartphone beschäftigt – Produktion, Lager, Empfang –, plant Sicherheitsschlüssel für diese Gruppe von Anfang an ein. Die Alternative, ihnen ein Diensthandy zu geben, ist teurer und wird trotzdem regelmäßig zuerst vorgeschlagen.
Der Rollout in vier Wellen
| Welle | Umfang | Zeitraum | Was hier geprüft wird |
|---|---|---|---|
| 0 – Vorbereitung | Notfallkonten anlegen, Wiederherstellungsweg festlegen, Selbstregistrierung öffnen | Woche 1–2 | Ob eine Rückstellung ohne Helpdesk möglich ist |
| 1 – Pilot | 10 bis 20 Personen, gemischt: IT, eine Fachabteilung, eine Person ohne Diensthandy, eine im Außendienst | Woche 3 | Welche Anwendungen die Anmeldung nicht sauber weiterreichen |
| 2 – Administrative Konten | Alle Konten mit erhöhten Rechten, Dienstkonten gesondert betrachten | Woche 4–5 | Ob Automatisierungen an der Anmeldung hängen bleiben |
| 3 – Belegschaft | Nach Abteilungen, 2 bis 3 Gruppen pro Woche, Registrierung eine Woche vor Pflichttermin | Woche 6–8 | Wie viele Anfragen je 100 Personen entstehen |
| 4 – Ausnahmen | Verbliebene Konten einzeln durchgehen, jede Ausnahme befristen | ab Woche 9 | Ob die Liste kürzer wird oder wächst |
Zwischen Registrierung und Pflichttermin sollte etwa eine Woche liegen. Wer beides auf denselben Tag legt, erzeugt die Anfragewelle, die den Ruf des Projekts bestimmt: Alle registrieren gleichzeitig, und jeder Fehler landet innerhalb einer Stunde beim Support. Mit einer Woche Vorlauf registrieren sich erfahrungsgemäß die meisten Personen von selbst, und übrig bleiben die Fälle, die tatsächlich Hilfe brauchen.
Wiederherstellung und Notfallzugang
Zwei Wege müssen vor der ersten Welle stehen, weil beide unter Zeitdruck sonst improvisiert werden – und Improvisation heißt hier: jemand bekommt Zugang, ohne dass seine Identität geprüft wurde.
- Verlorener Faktor. Erste Wahl ist die Selbsthilfe über den zweiten registrierten Faktor – deshalb zwei je Person. Ist auch der weg, folgt die Rückstellung durch den Helpdesk, aber nur nach Identitätsprüfung: persönlich, per Videoanruf mit Ausweis oder durch Bestätigung der Führungskraft über einen zweiten Kanal. Ein Anruf mit Namen und Geburtsdatum genügt nicht.
- Notfallkonten. Mindestens zwei Konten, die von der MFA-Pflicht ausgenommen sind, mit einem sehr langen zufälligen Kennwort, getrennt hinterlegt und nicht an eine Person gebunden. Jede Anmeldung erzeugt eine Meldung. Sie existieren für den Fall, dass die Richtlinie selbst oder der Anbieter des zweiten Faktors ausfällt – ein Szenario, das häufiger eintritt als der Angriff, gegen den die Richtlinie schützt.
Der Umgang mit diesen Konten gehört in dasselbe Dokument wie die übrigen privilegierten Zugänge, also ins Berechtigungskonzept. Ihr Einsatz ist ein meldepflichtiges Ereignis – der Ablauf dafür steht im Meldeprozess für Sicherheitsvorfälle.
Ausnahmen befristen
Ausnahmen entstehen in jedem Rollout, und sie sind meistens berechtigt: eine Maschinensteuerung ohne moderne Anmeldung, ein Fachverfahren, das seit 2014 unverändert läuft, ein externer Dienstleister mit eigenem Verzeichnis. Das Problem ist nicht die Ausnahme, sondern ihre Dauer.
Deshalb bekommt jede Ausnahme vier Angaben: das betroffene System, den technischen Grund, die ersatzweise Maßnahme – Netztrennung, IP-Beschränkung, kürzere Sitzungsdauer – und ein Ablaufdatum. Ohne Ablaufdatum entsteht ein Dauerzustand, den beim nächsten Audit niemand mehr erklären kann. Mit Ablaufdatum entsteht eine Wiedervorlage, die entweder verlängert oder geschlossen wird; beides ist eine Entscheidung und damit belegbar.
Mustertext für die Richtlinie
Dieser Abschnitt lässt sich in eine bestehende IT-Richtlinie oder in die Passwortrichtlinie übernehmen. Platzhalter ersetzen, Nichtzutreffendes streichen.
Mehrfaktor-Authentisierung bei der [Organisation]
1. Geltung
Der Zugriff auf Systeme der [Organisation] erfolgt mit mindestens zwei Faktoren aus verschiedenen Kategorien. Das gilt für alle Konten von Beschäftigten, für administrative Konten und für Zugänge externer Dienstleister. Ausgenommen sind ausschließlich die in Abschnitt 5 geregelten Fälle.
2. Zugelassene Verfahren
Zugelassen sind Sicherheitsschlüssel nach FIDO2, Passkeys auf verwalteten Geräten, Push-Bestätigung mit Zahlenabgleich und Einmalcodes aus einer Authentisierungs-App. Für Konten mit erhöhten Rechten ist ein phishing-resistentes Verfahren zu verwenden. Codes per SMS oder Sprachanruf sind nur als befristeter Rückfallweg nach Abschnitt 5 zulässig.
3. Registrierung
Jede Person registriert zwei Faktoren. Die Registrierung erfolgt eigenständig innerhalb von [7] Tagen nach Aufforderung. Die Faktoren werden nicht an andere Personen weitergegeben; Sicherheitsschlüssel werden wie ein Ausweis behandelt.
4. Verlust und Rückstellung
Der Verlust eines Faktors wird unverzüglich an [Kontakt] gemeldet. Die Rückstellung erfolgt nach Prüfung der Identität durch [Verfahren: persönlich, Videoanruf mit Lichtbildausweis oder Bestätigung der Führungskraft über einen zweiten Kanal]. Eine Rückstellung ohne Identitätsprüfung ist unzulässig. Jede Rückstellung wird protokolliert.
5. Ausnahmen
Ausnahmen werden von [Rolle] genehmigt und enthalten System, Begründung, ersatzweise Maßnahme und ein Ablaufdatum von höchstens [12] Monaten. Sie werden in [Ablage] geführt und mindestens halbjährlich überprüft.
6. Notfallzugänge
Es bestehen [2] Notfallkonten ohne zweiten Faktor mit einem Kennwort von mindestens [30] Zeichen. Die Zugangsdaten werden geteilt und getrennt hinterlegt. Jede Anmeldung löst eine Meldung an [Rolle] aus und wird als Ereignis nach dem Meldeprozess behandelt. Die Funktionsfähigkeit wird [halbjährlich] geprüft.
Freigegeben durch: [Name, Funktion] · Gültig ab: [Datum] · Nächste Überprüfung: [Datum]
Aus der Praxis: die Ausnahmeliste als Frühwarnung
Die Zahl, die am meisten über einen MFA-Rollout aussagt, ist nicht die Abdeckungsquote. Sie ist die Entwicklung der Ausnahmeliste über die Zeit. Eine Quote von 96 Prozent klingt gut und verdeckt, dass die restlichen 4 Prozent genau die Systeme sind, über die ein Angriff laufen würde – alte Fachverfahren, Fernzugänge, Dienstleisterkonten.
Meine Einschätzung: Der verbreitete Rat, MFA zuerst für alle „normalen“ Nutzer auszurollen und die Sonderfälle später zu behandeln, dreht die Prioritäten um. Die Belegschaftskonten sind der einfache Teil und liefern die Zahl für die Berichterstattung; der Nutzen entsteht bei den administrativen Zugängen und den Fernzugriffen. Wer dort anfängt, hat nach zwei Wochen den größeren Teil des Risikos erledigt und trifft die schwierigen Fälle zu einem Zeitpunkt, an dem noch Projektzeit übrig ist. Umgekehrt landen sie in Woche neun auf einer Liste, für die sich dann niemand mehr zuständig fühlt.
Häufige Fragen
Können wir Beschäftigte verpflichten, ihr privates Handy zu nutzen?
Ohne Vereinbarung nicht. Die Nutzung eines Privatgeräts für dienstliche Zwecke ist freiwillig, und eine Anweisung dazu ist arbeitsrechtlich angreifbar. Der praktikable Weg ist ein Wahlrecht: wer sein eigenes Gerät nutzen möchte, kann das; wer nicht, bekommt einen Sicherheitsschlüssel. Die Schlüssel kosten weniger als die Diskussion.
Reicht MFA, um die Anforderung aus NIS2 zu erfüllen?
Für den Punkt in § 30 Abs. 2 Nr. 10 BSIG ja, für die Zugriffskontrolle insgesamt nein. Die Vorschrift nennt Multi-Faktor-Authentifizierung neben gesicherter Kommunikation als eine von zehn Maßnahmengruppen. Ob die eigene Organisation überhaupt darunterfällt, klärt der Betroffenheits-Check nach § 28 BSIG.
Was ist mit Dienstkonten und Automatisierungen?
Für Konten ohne Person hinter der Anmeldung ist MFA das falsche Werkzeug. Sie brauchen stattdessen verwaltete Identitäten, hinterlegte Zertifikate oder regelmäßig gewechselte Geheimnisse, dazu eine Einschränkung auf Quell-Adressen. Wichtig ist, sie beim Rollout gesondert zu erfassen – sonst laufen sie in eine Richtlinie, die für sie nicht gedacht war, und ein Nachtjob bricht ab.
Wie lange soll eine Sitzung ohne erneute Bestätigung gelten?
Auf verwalteten Geräten sind mehrere Tage vertretbar, auf nicht verwalteten Geräten und bei administrativen Zugängen deutlich weniger – üblich sind wenige Stunden. Die Bestätigung sollte zusätzlich erzwungen werden, wenn sich Standort, Gerät oder Netz ändern. Zu kurze Intervalle für alle erzeugen Bestätigungsmüdigkeit, und die ist selbst ein Angriffsweg.
Was passiert mit Personen, die den zweiten Faktor nicht bedienen können?
Es gibt für fast jede Einschränkung ein passendes Verfahren – ein Sicherheitsschlüssel mit Taste kommt ohne Bildschirm und ohne Code aus. Wo die Auswahl an einer Barriere scheitert, ist das ein Gestaltungsfehler der Anmeldung; das Erfolgskriterium 3.3.8 Zugängliche Authentifizierung beschreibt, worauf dabei zu achten ist.
Weiterführende Seiten
- Passwortrichtlinie – der erste Faktor, mit Länge statt Wechselintervall
- Berechtigungskonzept – wer welche Rechte bekommt und wer sie wieder verliert
- IT-Richtlinie – der Rahmen, in den der Mustertext oben passt
- IT-Notfallplan – was gilt, wenn die Anmeldung selbst ausfällt
- ISMS einführen – wo die Maßnahme im Gesamtaufbau steht
Stand: August 2026. Rechtsgrundlage ist § 30 BSIG in der seit dem 6. Dezember 2025 geltenden Fassung; Normbezug sind die Maßnahmen 5.17 und 8.5 im Anhang A der ISO/IEC 27001:2022. Der Mustertext ersetzt keine Rechtsberatung; die Einführung berührt bei bestehendem Betriebsrat die Mitbestimmung.