Zwei-Faktor-Authentifizierung (2FA/MFA) richtig einführen

Ein gestohlenes Passwort genügt, um in E-Mail, Cloud-Speicher oder VPN eines Unternehmens einzudringen. Zwei-Faktor-Authentifizierung (2FA/MFA) verhindert den Großteil solcher Übernahmen, wenn sie richtig eingeführt wird. Diese Anleitung richtet sich an Administratoren und Entscheider im Mittelstand und zeigt anbieterunabhängig, welche Verfahren schützen, wie Sie MFA in Phasen ausrollen, wie ein Recovery-Konzept Aussperrungen verhindert und welche Pflichten NIS-2 vorgibt. Die Umsetzung in Microsoft 365 behandelt eine eigene, am Ende verlinkte Anleitung.

Voraussetzungen

• Eine Bestandsaufnahme aller Konten, Anwendungen und Zugänge (Cloud/SaaS, VPN, Mail, Finanzen, Admin-Konten, Service-Accounts, Externe).
• Identity-Provider oder Dienste, die MFA unterstützen (Microsoft 365/Entra ID, Google Workspace, Keycloak, VPN-Gateway usw.).
• FIDO2-Sicherheitsschlüssel für privilegierte Konten, je Person zwei Stück (einer als Reserve).
• Ein verschlüsselter Passwort-Manager für Notfall-Codes sowie ein Tresor.
• Rückendeckung der Geschäftsleitung. Bei NIS-2-Einrichtungen ist sie nach § 38 BSIG verpflichtet, die Maßnahmen umzusetzen und zu überwachen.

Schritt 1: Grundlagen klären: Was 2FA ausmacht

Authentifizierung stützt sich auf drei Faktor-Kategorien. 2FA kombiniert zwei verschiedene davon; zwei Passwörter sind keine 2FA.

• Wissen: Passwort, PIN.
• Besitz: Smartphone, Hardware-Token, Smartcard.
• Inhärenz: Fingerabdruck, Gesicht (Biometrie).

Für die Auswahl entscheidend ist die Phishing-Resistenz. Einmalcodes aus SMS, E-Mail oder TOTP-App lassen sich über eine Phishing-Proxy-Seite (etwa Evilginx) in Echtzeit weiterreichen: Der Nutzer gibt den Code auf der gefälschten Seite ein, der Angreifer nutzt ihn sofort beim echten Dienst. FIDO2 und Passkeys verhindern das: Der private Schlüssel verlässt das Gerät nicht, und die Anmeldung ist an die echte Domain gebunden.

Verifizieren: Alle Beteiligten im Projekt können die drei Kategorien benennen und erklären, warum ein TOTP-Code nicht phishing-resistent ist.

Schritt 2: Verfahren auswählen und vergleichen

Das BSI (Bewertung von 2FA-Verfahren) stellt fest, dass E-Mail-TAN, SMS-TAN und TOTP nicht vor Echtzeit-Phishing schützen, Passkeys dagegen gegen übliche Phishing-Angriffe resistent sind. NIST SP 800-63B-4 (2025) führt Einmalcodes über das Telefonnetz (SMS, Anruf) als restricted authenticator und lässt E-Mail als Out-of-Band-Verfahren nicht zu. Wählen Sie das Verfahren nach Schutzbedarf des Kontos.

Verfahren	Faktor-Typ	Phishing-resistent	Offline-fähig	Eignung
FIDO2-Sicherheitsschlüssel (gerätegebundener Passkey)	Besitz + PIN/Biometrie	Ja	Ja	Admins, Hochrisiko
Synchronisierter Passkey	Besitz + PIN/Biometrie	Ja	Ja	alle Nutzer
Hardware-OTP-Token	Besitz	Nein	Ja	Offline-Umgebungen
TOTP-App (Authenticator)	Besitz	Nein	Ja	Standard-Mitarbeiter
Push-Bestätigung	Besitz	Nein (Risiko MFA-Fatigue)	Nein	nur mit Number-Matching
SMS-/E-Mail-Code	Besitz	Nein (schwächste Option)	Nein	nur Fallback

Als resistent gegen alle betrachteten Angriffsszenarien bewertet das BSI nur die Online-Ausweisfunktion des Personalausweises; sie steht für den Login in Unternehmensanwendungen aber meist nicht zur Verfügung. Realistische phishing-resistente Wahl sind daher FIDO2-Sicherheitsschlüssel und Passkeys. TOTP (RFC 6238, meist 6-stelliger Code, 30-Sekunden-Fenster, gemeinsames Geheimnis) funktioniert offline, ist aber nicht phishing-resistent.

Faustregel zur Zuordnung

• Hochrisiko (Admins, privilegierte Konten): FIDO2-Sicherheitsschlüssel oder Passkey, nie nur TOTP.
• Standard-Mitarbeiter: TOTP-App als Minimum, Passkey wo möglich.
• Push: nur mit Number-Matching und Kontextanzeige (Standort, App).
• SMS/E-Mail: nur als letzter Fallback.

Verifizieren: Für jede Schutzklasse ist ein zulässiges Verfahren festgelegt, und alle Kernsysteme unterstützen es.

Schritt 3: Roll-out risikobasiert in Phasen planen

Eine sofortige Pflicht für alle ohne Pilot führt zu Support-Flut und Login-Ausfällen. Rollen Sie MFA nach Schutzbedarf aus, nicht nach Hierarchie. Die Selbst-Registrierung (Enrollment) kommt immer vor der Pflicht (Enforcement).

Phase	Zielgruppe / Inhalt
Phase 0: Vorbereitung	Bestandsaufnahme aller Konten und Anwendungen, Policy schreiben, Support- und Recovery-Prozess definieren.
Phase 1: Pilot (1 bis 2 Wochen)	IT/Security plus freiwillige Power-User mit verschiedenen Geräten; Probleme sammeln.
Phase 2: privilegierte Konten	Alle Admin-Konten verpflichtend, phishing-resistent (FIDO2).
Phase 3: Remote-Zugang und Kernsysteme	VPN, Mail, Cloud/SaaS, Finanzbuchhaltung.
Phase 4: alle Mitarbeiter	Restliche Belegschaft, Standardverfahren TOTP oder Passkey.
Phase 5: Externe	Zugänge von Partnern und Lieferanten.

Verifizieren: Für jede Phase stehen Zielgruppe, Termin für die Registrierung und Termin für die Pflicht fest.

Schritt 4: Pilot durchführen und messen

Der Pilot deckt Probleme auf, bevor sie die ganze Belegschaft treffen. Haken Sie vor dem breiten Roll-out diese Punkte ab:

• mindestens zwei Verfahren angeboten (z. B. FIDO2 und TOTP)
• verschiedene Gerätetypen getestet (iOS, Android, Desktop)
• Anmeldung und Recovery getestet
• Support-Team geschult
• Kurzanleitung für Endnutzer fertig
• Kennzahlen erfasst: Registrierungsquote, Support-Tickets, Fehlerquote bei der Anmeldung

Verifizieren: Erst wenn die Kennzahlen stimmen und der Support die Anfragen bewältigt, starten Sie die nächste Phase. Planen Sie für die erste Registrierungswelle zusätzliche Kapazität im Help-Desk ein.

Schritt 5: Recovery- und Notfall-Konzept aufsetzen

Ist nur ein Faktor registriert und geht das Gerät verloren, sperrt sich der Nutzer aus. Das ist die häufigste MFA-Panne. So beugen Sie vor:

1. Bei jeder Registrierung die vom Dienst angebotenen Einmal-Wiederherstellungscodes erzeugen.
2. Die Codes verschlüsselt im Passwort-Manager und ausgedruckt im Tresor hinterlegen.
3. Mindestens zwei verschiedene Zweitfaktoren je Nutzer registrieren (z. B. Sicherheitsschlüssel und TOTP).
4. Einen Reset-Prozess im Help-Desk mit Identitätsprüfung festlegen, kein Reset allein per E-Mail oder Anruf.
5. Ein Notfall-Admin-Konto (Break-Glass) mit FIDO2 und getrennt verwahrtem Notfall-Code einrichten und regelmäßig testen.

Notfall-Codes sicher lagern (Rule of Three)

Notfall-Codes im Klartext in einer E-Mail, als Screenshot oder in einer Notiz-App machen den zweiten Faktor wertlos. Verteilen Sie die Codes auf drei voneinander unabhängige Orte:

1) Verschlüsselt digital    -> Passwort-Manager (ein Eintrag je Konto)
2) Physisch im Büro         -> Tresor oder abschließbarer Schrank
3) Physisch am zweiten Ort  -> getrennt verwahrter Ausdruck

NIEMALS: Klartext-E-Mail, Screenshot, Desktop-Datei, Notiz-App

Ohne Sicherung der TOTP-Geheimnisse müssen Nutzer sich nach jedem Smartphone-Wechsel neu registrieren. Legen Sie dafür einen Migrationsprozess fest.

Verifizieren: Ein Testnutzer meldet sich ohne sein Hauptgerät erfolgreich mit dem zweiten Faktor bzw. einem Notfall-Code an, und das Notfall-Admin-Konto funktioniert.

Schritt 6: Schulung und Change-Management

Ohne Kommunikation sinkt die Akzeptanz. Setzen Sie diese Bausteine ein:

• Vorab-Ankündigung mit Begründung und Termin: warum, ab wann, für wen.
• Kurzanleitung (eine Seite mit Screenshots) je Verfahren.
• Aufklärung über MFA-Fatigue (Push-Bombing): Angreifer lösen wiederholt Push-Anfragen aus, bis jemand genervt bestätigt. Regel: nie eine unaufgeforderte Anfrage bestätigen.
• Ein klar benannter Ansprechpartner für Support.
• Erinnerung an die sichere Aufbewahrung der Notfall-Codes.

Verifizieren: Ankündigung ist verschickt, Kurzanleitungen liegen im Intranet, und die Zahl der Support-Tickets je Phase wird erfasst.

Schritt 7: MFA-Policy als internen Standard schreiben

Halten Sie die Regeln verbindlich und prüfbar fest. Bewährte Gliederung:

1. Geltungsbereich und betroffene Systeme.
2. Pflichtverfahren je Schutzklasse: Hochrisiko phishing-resistent (FIDO2/Passkey), Standard mindestens TOTP, SMS nur als Fallback.
3. Registrierungsprozess.
4. Recovery- und Lockout-Prozess.
5. Verbotene Praktiken: SMS als primärer Faktor, geteilte Konten, Codes im Klartext.
6. Verantwortlichkeiten und Überprüfungszyklus.

Die technische Umsetzung, etwa Conditional Access oder Authentication Strengths in Entra ID, dokumentieren Sie getrennt.

Verifizieren: Die Geschäftsleitung hat die Policy freigegeben, und sie ist mit Versionsstand veröffentlicht.

Schritt 8: Compliance: NIS-2 und DSGVO einordnen

Das NIS-2-Umsetzungsgesetz (NIS2UmsuCG) ist seit dem 06.12.2025 in Kraft. Für besonders wichtige und wichtige Einrichtungen nennt § 30 Abs. 2 Satz 2 Nr. 10 BSIG ausdrücklich die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“. Das BSI schätzt die Zahl der betroffenen Einrichtungen auf rund 29.500. Ob Ihr Unternehmen dazugehört, klären Sie mit der Betroffenheitsprüfung des BSI.

• Geschäftsleitung: Sie muss die Maßnahmen nach § 30 umsetzen und überwachen und haftet der Einrichtung bei schuldhafter Pflichtverletzung für den Schaden (§ 38 BSIG).
• Bußgelder: Wer Maßnahmen nach § 30 Abs. 1 nicht ergreift, riskiert bei besonders wichtigen Einrichtungen bis 10 Mio. Euro, bei wichtigen Einrichtungen bis 7 Mio. Euro. Bei mehr als 500 Mio. Euro Gesamtumsatz gelten bis 2 % bzw. 1,4 % des Gesamtumsatzes (§ 65 BSIG).
• DSGVO: Art. 32 verlangt technische und organisatorische Maßnahmen nach dem Stand der Technik und dem Risiko. Für Konten mit Zugriff auf personenbezogene Daten ist MFA eine naheliegende Maßnahme; eine ausdrückliche MFA-Pflicht nennt die DSGVO nicht.

MFA ist eine von zehn Maßnahmengruppen in § 30 Abs. 2 BSIG und erfüllt NIS-2 allein nicht. Diese Einordnung ersetzt keine Rechtsberatung.

Verifizieren: Betroffenheit ist geklärt und dokumentiert; die MFA-Umsetzung ist Teil der Dokumentation nach § 30 Abs. 1 BSIG.

Typische Fehler

• SMS/E-Mail als primärer zweiter Faktor: anfällig für SIM-Swapping, Angriffe auf das Mobilfunknetz und Echtzeit-Phishing. Nur als letzter Fallback.
• TOTP für phishing-resistent halten: Der Code lässt sich über eine Proxy-Seite weiterreichen. Admins brauchen FIDO2 oder Passkey.
• Kein Recovery-Konzept: Ein einziger Faktor plus Geräteverlust ergibt Aussperrung. Immer zwei Faktoren und Notfall-Codes.
• Pflicht ohne Pilot: führt zu Support-Flut. Phasenweise vorgehen, Registrierung vor Pflicht.
• Vergessene Sonderfälle: Service-Accounts, geteilte Postfächer und Legacy-Authentifizierung (IMAP, POP, SMTP mit Basic Auth) umgehen MFA. Blockieren Sie Legacy-Authentifizierung, sonst läuft MFA ins Leere.
• Notfall-Codes unsicher gelagert: Klartext-Mail, Screenshot oder Notiz-App machen den zweiten Faktor wertlos.

Häufige Fragen

Reicht eine TOTP-App nicht für alle aus?

Für Standard-Mitarbeiter ist sie ein gutes Minimum. Für privilegierte Konten reicht sie nicht, weil sie nicht phishing-resistent ist. Admins brauchen FIDO2 oder Passkey.

Warum ist SMS als zweiter Faktor so schlecht?

SMS-Codes sind anfällig für SIM-Swapping, Angriffe auf das Mobilfunknetz und Echtzeit-Phishing. NIST führt sie als restricted authenticator. Nutzen Sie SMS nur als Fallback und bieten Sie immer einen stärkeren Faktor an.

Was ist der Unterschied zwischen 2FA und MFA?

2FA bedeutet genau zwei Faktoren aus zwei Kategorien, MFA zwei oder mehr. In der Praxis werden die Begriffe synonym verwendet; entscheidend ist, dass die Faktoren aus unterschiedlichen Kategorien stammen.

Wie verhindern Sie, dass sich Mitarbeiter aussperren?

Mit mindestens zwei registrierten Zweitfaktoren je Nutzer, sicher verwahrten Notfall-Codes und einem Reset-Prozess mit Identitätsprüfung (siehe Schritt 5).

Was ist MFA-Fatigue und wie schützen Sie Ihr Team?

Angreifer lösen wiederholt Push-Anfragen aus, bis jemand bestätigt. Schutz bieten Number-Matching, Kontextanzeige, Schulung und am wirksamsten phishing-resistente Verfahren ohne einfachen Bestätigungs-Push.

Sind Passkeys sicher genug für Unternehmen?

Ja. Das BSI bewertet beide Passkey-Varianten als resistent gegen übliche Phishing-Angriffe. Grundlage ist FIDO2 (WebAuthn des W3C plus CTAP2). Bei synchronisierten Passkeys hängt die Sicherheit zusätzlich vom Konto ab, über das synchronisiert wird; für Admins sind gerätegebundene Sicherheitsschlüssel die strengere Wahl.

Fazit

Die Einführung von 2FA/MFA ist vor allem ein Prozessthema. Wählen Sie die Verfahren nach Schutzbedarf, rollen Sie in Phasen aus, bieten Sie die Registrierung vor der Pflicht an und testen Sie den Recovery-Weg so gründlich wie die Anmeldung. Blockieren Sie Legacy-Authentifizierung, damit MFA nicht umgangen wird.

Weiterführende Anleitungen und Quellen

• Konkrete Umsetzung in Microsoft 365: Microsoft 365 MFA mit Conditional Access in Entra ID einrichten
• Passwörter ablösen und Passkeys ausrollen: Sichere Passwörter und Passkeys im Unternehmen
• Mitarbeitende für Angriffe sensibilisieren: Phishing erkennen und melden – Leitfaden fürs Team
• Weitere Anleitungen rund um IT-Sicherheit: Kategorie Sicherheit

Quellen: BSI: Bewertung von 2FA-Verfahren | NIST SP 800-63B-4 | § 30 BSIG | § 38 BSIG | § 65 BSIG. Stand 09/2026.