MFA ist keine Empfehlung mehr, sondern gesetzliche Pflicht
In den Diskussionen um NIS2 geht ein Detail unter, das für den IT-Betrieb sehr konkret ist: Multi-Faktor-Authentifizierung und gesicherte Kommunikation sind einer der zehn Maßnahmenbereiche nach § 30 BSIG. Damit ist MFA keine Frage der Sicherheitskultur mehr, sondern eine Anforderung, deren Umsetzung Sie belegen müssen.
Die Frage lautet nicht mehr „Brauchen wir MFA?“, sondern „Für welche Zugänge, mit welchem Faktor, und wie weisen wir das nach?“
Was der Gesetzestext verlangt – und was nicht
Das Gesetz nennt Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung als Maßnahme, ohne eine konkrete Technologie vorzuschreiben. Diese Offenheit ist keine Einladung zur Minimallösung: Maßgeblich ist der Stand der Technik und die Angemessenheit gegenüber dem Risiko. Ein Verfahren, das nachweislich umgehbar ist, erfüllt diesen Maßstab nur schwer.
| Verfahren | Phishing-resistent | Praxisbewertung |
|---|---|---|
| SMS-Code (TAN) | NEIN | Anfällig für SIM-Swapping und Echtzeit-Phishing. Besser als nichts, aber als alleiniger zweiter Faktor für privilegierte Zugänge nicht mehr angemessen. |
| TOTP-App (6-stelliger Code) | NEIN | Anfällig für Adversary-in-the-Middle-Angriffe. Für Standardbenutzer akzeptabel, für Administratoren nicht. |
| Push-Benachrichtigung mit Nummernabgleich | TEILWEISE | Deutlich besser als reine Push-Bestätigung, aber weiterhin kein kryptografischer Bezug zur Zieldomäne. |
| Windows Hello for Business | JA | Gerätegebunden, kryptografisch an den Dienst gebunden. Sehr gute Standardlösung für verwaltete Geräte. |
| FIDO2-Sicherheitsschlüssel / Passkey | JA | Der Referenzstandard. Funktioniert auch bei Schichtbetrieb und geteilten Arbeitsplätzen, wo Hello unpraktisch ist. |
| Smartcard mit AD CS | JA | Bewährt für die interne Windows-Anmeldung, aber mit eigenem PKI-Aufwand. |
Die Lücke, die fast alle haben
In den meisten Umgebungen ist MFA für Microsoft 365 aktiviert – und damit endet es. Die Anmeldung am Windows-Client, der RDP-Zugang zum Terminalserver und die VPN-Einwahl laufen weiterhin mit Benutzername und Passwort. Aus Sicht eines Angreifers ist das die interessante Seite, denn dort liegen die Daten und dort beginnt die seitliche Bewegung.
Wo Sie realistisch anfangen
- Alle privilegierten Konten auf phishing-resistente Verfahren umstellen. Das sind wenige Konten mit maximaler Wirkung – der schnellste Fortschritt im ganzen Projekt.
- Jeden Zugang von außen absichern: VPN, RDP-Gateway, Webmail, Fernwartungszugänge, Portale von Dienstleistern.
- Windows-Anmeldung für alle Arbeitsplätze über Windows Hello for Business, ergänzt um FIDO2-Schlüssel für gemeinsam genutzte Arbeitsplätze und Produktionsumgebungen.
- Dienst- und Notfallkonten gesondert regeln: Ausnahmen sind zulässig, müssen aber begründet, dokumentiert und kompensiert sein.
- Wirksamkeit messen: Anteil der Konten mit starkem Faktor, monatlich, als Kennzahl für die Geschäftsleitung.
Für Schritt 5 brauchen Sie keine zusätzliche Software – die Auswertung liefert Microsoft Graph. Das folgende Skript listet alle aktiven Konten ohne starke Authentifizierungsmethode auf. Genau diese Liste ist Ihr Projektfortschritt und gleichzeitig Ihr Nachweis:
# Microsoft Graph: Wer hat noch KEINE starke Authentifizierung?
# Voraussetzung: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","User.Read.All","Directory.Read.All"
$stark = @('#microsoft.graph.fido2AuthenticationMethod',
'#microsoft.graph.passwordlessMicrosoftAuthenticatorAuthenticationMethod',
'#microsoft.graph.windowsHelloForBusinessAuthenticationMethod',
'#microsoft.graph.microsoftAuthenticatorAuthenticationMethod',
'#microsoft.graph.softwareOathAuthenticationMethod')
Get-MgUser -All -Property Id,UserPrincipalName,DisplayName,AccountEnabled |
Where-Object AccountEnabled |
ForEach-Object {
$m = Get-MgUserAuthenticationMethod -UserId $_.Id
$typen = $m | ForEach-Object { $_.AdditionalProperties['@odata.type'] }
[pscustomobject]@{
Benutzer = $_.UserPrincipalName
Name = $_.DisplayName
Methoden = ($typen -replace '#microsoft.graph.','' -join ', ')
MFA_stark = [bool]($typen | Where-Object { $stark -contains $_ })
}
} | Where-Object { -not $_.MFA_stark } | Sort-Object BenutzerDer Widerstand kommt nicht aus der Technik
Technisch ist ein FIDO2-Rollout überschaubar. Der Widerstand kommt aus dem Betrieb: Was passiert, wenn jemand seinen Schlüssel vergisst? Wie melden sich Beschäftigte an einem gemeinsam genutzten Arbeitsplatz an? Wie läuft die Erstregistrierung für Personen ohne Diensthandy? Genau diese Fragen entscheiden über Erfolg oder Abbruch – deshalb gehören sie vor den Rollout, nicht danach.
- Zweiter Faktor als Rückfallebene pro Person – ein Ersatzschlüssel im Tresor ist billiger als jeder Notfallprozess.
- Definierter Prozess für Verlust, inklusive gesicherter Identitätsprüfung am Servicedesk.
- Umgang mit gemeinsam genutzten Arbeitsplätzen und Schichtbetrieb.
- Registrierungsprozess für neue Beschäftigte, verzahnt mit dem On-Boarding.
- Ausnahmenliste mit Begründung, Kompensation und Ablaufdatum.
- Kommunikation an die Belegschaft vor der Umstellung – MFA scheitert selten an der Technik und oft an der Überraschung.