MFA-Rollout im KMU: Welcher Initialaufwand ist realistisch?

Welche regulatorischen Grundlagen sind einschlägig?

Die Anforderungen an die Authentifizierungs-Stärke ergeben sich aus mehreren parallelen Rechts- und Standard-Quellen:

• NIS2-Richtlinie (EU) 2022/2555 Art. 21 Abs. 2 Buchst. j nennt die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung sowie gesicherte Sprach-, Video- und Textkommunikation und gegebenenfalls gesicherte Notfallkommunikation; Zugriffskontrolle steht gesondert in Buchst. i. In Deutschland gilt seit 06.12.2025 § 30 Abs. 2 Nr. 10 BSIG („Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme") für besonders wichtige und wichtige Einrichtungen.
• DSGVO Art. 32 Abs. 1 verlangt geeignete technische und organisatorische Maßnahmen, die unter anderem die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme auf Dauer sicherstellen. Ein bestimmtes Authentifizierungsverfahren schreibt die DSGVO nicht vor; maßgeblich ist das Risiko der Verarbeitung.

• BSI IT-Grundschutz Baustein ORP.4 (Identitäts- und Berechtigungsmanagement) beschreibt Anforderungen an Identitäts- und Berechtigungsmanagement und kann als fachliche Orientierung dienen; rechtlich bindend ist er nur, wo ein Regelwerk oder Vertrag darauf verweist.
• NIST SP 800-63B definiert international die Authenticator-Klassifizierung (AAL1-AAL3) und gibt Hinweise zu Verfahren, die für höhere Vertrauensstufen geeignet sind.
• Sektorspezifische Anforderungen können hinzukommen, etwa im Finanzsektor DORA (VO (EU) 2022/2554), deren Art. 9 Abs. 4 Buchst. d Leitlinien und Protokolle für starke Authentifizierungsmechanismen verlangt; VAIT, KAIT und ZAIT hat die BaFin zum 16.01.2025 aufgehoben, die BAIT entfallen mit Ablauf des 31.12.2026 vollständig. Die BSI-KritisV selbst legt nur Sektoren und Schwellenwerte fest, keine Authentifizierungsvorgaben.
• Vertragliche Anforderungen aus Cyber-Versicherungen können MFA für Admin-Accounts voraussetzen; maßgeblich sind die jeweiligen Versicherungsbedingungen.

Welche dieser Quellen mit welcher Bindungswirkung greift, ist im Einzelfall zu prüfen.

Welche Schutzbedarfs-Stufe passt typisch zu KMU?

Die Wahl der MFA-Verfahren richtet sich nach der Kritikalität der jeweiligen Konten und der verarbeiteten Daten. Eine typische KMU-Einstufung kann sein:

• Normaler Schutzbedarf (Standard-Mitarbeitenden-Accounts in Microsoft 365 oder Google Workspace, Standard-SaaS-Zugriffe): App-basierte TOTP-Verfahren oder Push-basierte MFA über Authenticator-Apps sind ein verbreiteter Bezugspunkt.
• Hoher Schutzbedarf (Administrative Rollen, Buchhaltungs- und Finanz-Zugriffe, ERP-Admin): Hier sind phishing-resistente Verfahren (FIDO2-Hardware-Token, Plattform-Passkeys) gegenüber rein OTP-basierten Verfahren in Erwägung zu ziehen.

• Sehr hoher Schutzbedarf (Domain-Admin, Cloud-Tenant-Admin, KRITIS-relevante Zugänge): Hardware-Token mit Attestierung und mehrstufige Genehmigungsprozesse (Privileged Access Management) kommen in Betracht.

Die Methodik der Schutzbedarfsfeststellung beschreibt der BSI-Standard 200-2 (Kapitel 8.2).

Welcher Aufbau-Rahmen ist verbreitet?

Ein gestaffelter MFA-Rollout, wie er für KMU-Profile diskutiert wird, umfasst typischerweise vier Bestandteile. Die technische Aktivierung beschränkt sich bei vorhandenem Microsoft-365- oder Google-Workspace-Tenant auf wenige zentrale Einstellungen; die Vollausrollung mit Recovery, Help-Desk-Prozess, Schulung und Dokumentation umfasst zusätzliche Aufwände, die je nach Organisationsgröße und Anzahl angebundener Systeme erheblich variieren.

1. Konfiguration der zentralen Identitätsplattform. In Microsoft Entra ID kann eine MFA-Pflicht über Security Defaults oder eine Conditional-Access-Policy aktiviert werden. In Google Workspace erfolgt die Aktivierung über die 2-Step-Verification-Enforcement-Einstellung. Welcher Konfigurationspfad geeignet ist, hängt von der vorhandenen Lizenzierung (Microsoft 365 Business Premium, Microsoft 365 E5, Google Workspace Business Standard/Plus) und den weiteren Conditional-Access-Anforderungen ab.

2. Anbindung externer SaaS-Anwendungen. Pro Anwendung ist die MFA-Konfiguration einzeln zu aktivieren, sofern keine durchgängige SSO-Föderation mit MFA-Erzwingung auf der Identity-Provider-Seite vorhanden ist. Marktbekannte Anwendungen (CRM, Buchhaltungs-Suiten, Code-Hosting-Plattformen, Cloud-Provider) bieten regelmäßig native MFA-Optionen.

3. Absicherung von Fernzugängen. VPN-Gateways, Remote-Desktop-Gateways, SSH-Zugänge und administrative Web-Konsolen sollten mit einem zweiten Faktor abgesichert sein. Welches Verfahren tragfähig ist, hängt vom Geräteprofil und der Bedrohungslage ab. Administrative Protokolle sollten nicht ohne zweiten Faktor direkt aus dem Internet erreichbar sein.

4. Recovery-Strategie, Help-Desk-Prozess und Schulung. Recovery-Codes, Backup-Authenticator, ein dokumentierter Reset-Prozess bei Geräte-Verlust und eine kurze Mitarbeitenden-Einweisung sind Bestandteile eines tragfähigen Rollouts. Ohne diesen organisatorischen Rahmen erzeugt eine reine Technik-Aktivierung erfahrungsgemäß Help-Desk-Eskalationen.

Welche Anforderungen an phishing-resistente Verfahren sind verbreitet?

Die FIDO Alliance, das NIST und das BSI weisen darauf hin, dass klassische zweite Faktoren (SMS, OTP) gegen moderne Phishing-Kits (Adversary-in-the-Middle, Reverse-Proxy-Phishing) nur begrenzten Schutz bieten. Phishing-resistente Verfahren (FIDO2/WebAuthn, Plattform-Passkeys) binden die Authentifizierung kryptographisch an die Origin-URL und sind gegen diese Angriffsklasse strukturell robuster.

Verbreitete Einsatzszenarien im KMU-Bereich:

• Domain-Admins, Cloud-Tenant-Admins, Backup-Admins, Hardware-Token oder Plattform-Passkeys mit registriertem Geräte-Pool.
• Mitarbeitende mit Zugriff auf besondere Datenkategorien, Plattform-Passkeys (Apple, Microsoft, Google) als verbreitete Umsetzung.
• Allgemeine Mitarbeitenden-Accounts, App-basierte TOTP oder Push-basierte Authentifizierung mit Number-Matching, ggf. mit perspektivischem Übergang zu Passkeys.

Die konkrete Verfahrens-Auswahl hängt von Lizenzierung, Geräte-Verfügbarkeit (eigene oder private Endgeräte für die Authenticator-App), regulatorischen Vorgaben und Schulungs-Aufwand ab.

Welche Konstellationen erfordern abweichendes Vorgehen?

Eine schnelle Aktivierung in einem zentralen Tenant ist nicht für alle Unternehmensprofile möglich. In den folgenden Konstellationen sind erweiterte Konzepte und längere Realisierungszeiträume erforderlich:

• Komplexe Identitätslandschaften mit mehreren parallelen Identity Providern, Legacy-Anwendungen ohne MFA-Unterstützung, Eigenentwicklungen mit hartkodierten Service-Accounts: Hier ist regelmäßig eine vorgelagerte Identity-Konsolidierung erforderlich, bevor MFA durchgängig erzwungen werden kann.
• NIS2-pflichtige besonders wichtige und wichtige Einrichtungen: Neben MFA nach § 30 Abs. 2 Nr. 10 BSIG verlangt § 30 Abs. 2 Nr. 9 BSIG Konzepte und Prozesse für die Sicherheit des Personals, die Zugriffskontrolle und die Verwaltung von IKT-Systemen, -Produkten und -Prozessen. Die reine MFA-Aktivierung deckt diese Pflicht nicht ab.
• Finanzsektor: Seit 17.01.2025 gilt DORA (VO (EU) 2022/2554); Art. 9 Abs. 4 Buchst. d verlangt Leitlinien und Protokolle für starke Authentifizierungsmechanismen auf Grundlage einschlägiger Standards. VAIT, KAIT und ZAIT hat die BaFin aufgehoben; die BAIT gelten nur noch für Institute außerhalb von DORA und entfallen mit Ablauf des 31.12.2026 vollständig.
• Gesundheitssektor und Verarbeitung besonderer Datenkategorien nach Art. 9 DSGVO: Erweiterte Anforderungen an Verfahrenswahl und Dokumentation.
• Industrielle Steuerungssysteme (OT/SCADA): Klassische MFA-Verfahren sind in vielen OT-Umgebungen nicht ohne Weiteres umsetzbar; alternative Konzepte (Jump-Hosts mit MFA, dedizierte Wartungszugänge mit Out-of-Band-Authentifizierung) sind in Erwägung zu ziehen.
• Cyber-Policen: Ob MFA oder phishing-resistente Verfahren für administrative Konten Deckungsvoraussetzung sind, regeln die jeweiligen Versicherungsbedingungen; sie sollten vor Vertragsschluss und bei jeder Verlängerung geprüft werden.

Bei Unsicherheit über die einschlägige Verfahrens-Tiefe ist eine fachliche Beratung dem Verzicht auf Erweiterungen vorzuziehen.

Nächster Schritt

Ob das Unternehmen überhaupt in den NIS2-Anwendungsbereich fällt, lässt sich mit dem NIS2-Check vorläufig einordnen; er liefert ein Scope-Signal und priorisierte Maßnahmen, aber keine Authentifizierungsvorgaben. Welche Verfahren für das eigene Schutzbedarfsprofil tragfähig sind, ist im Anschluss durch eine Schutzbedarfsanalyse zu bestimmen.

Eine vertiefte Einordnung der NIS2-MFA-Anforderungen findet sich in NIS2-MFA-Pflicht: Praxis für KMU.

Diese Einordnung beruht auf den oben genannten Quellen mit Stand: 18.09.2026. Sie ersetzt keine Einzelfallprüfung durch eine qualifizierte Beratung.