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 lit. j verlangt Maßnahmen zur Sicherheit der Authentifizierung als Teil des Identitäts- und Zugriffsmanagements, sofern die Einrichtung in den nationalen Anwendungsbereich fällt.
• DSGVO Art. 32 Abs. 1 verlangt geeignete technisch-organisatorische Maßnahmen zur Sicherstellung von Vertraulichkeit und Integrität. Die Aufsichtsbehörden orientieren sich bei der Auslegung regelmäßig an BSI-Standards.

Detail

• BSI IT-Grundschutz Baustein ORP.4 (Identitäts- und Berechtigungsmanagement) ist die anerkannte Referenz für die Auslegung im deutschen Raum.
• 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 (BAIT, VAIT, KAIT, B3S Krankenhaus, KRITIS-Verordnung, TKG) sehen regelmäßig erweiterte Vorgaben zur Authentifizierungs-Stärke vor.
• Vertragliche Anforderungen aus Cyber-Versicherungen schreiben MFA für Admin-Accounts regelmäßig als Deckungsvoraussetzung vor.

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.

Detail

• Sehr hoher Schutzbedarf (Domain-Admin, Cloud-Tenant-Admin, KRITIS-relevante Zugänge): Hardware-Token mit Attestierung und mehrstufige Genehmigungsprozesse (Privileged Access Management) sind regelmäßig erforderlich.

Die Schutzbedarfsanalyse ist nach BSI IT-Grundschutz Baustein ISMS.1 Bestandteil eines tragfähigen Sicherheitsmanagements.

Welcher Aufbau-Rahmen ist verbreitet?

Ein gestaffelter MFA-Rollout, wie er für KMU-Profile diskutiert wird, umfasst typischerweise vier Bestandteile. Die Initialisierung kann bei vorhandenem Microsoft-365- oder Google-Workspace-Tenant in einem begrenzten Zeitfenster (regelmäßig 30-90 Minuten reine Klick-Zeit für die Aktivierung) erfolgen; 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.

Detail

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. Eine Direkt-Exposition administrativer Protokolle ins offene Internet ohne MFA ist nach BSI-Empfehlung nicht mehr zeitgemäß.

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.

Detail

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?

Ein 30-90-Minuten-Initialaufwand für die Aktivierung in einem zentralen Tenant ist nicht repräsentativ für alle Unternehmensprofile. In den folgenden Konstellationen sind erweiterte Konzepte und längere Realisierungszeiträume erforderlich:

Detail

• 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 wesentliche und wichtige Einrichtungen: Erforderlich ist ein dokumentiertes Identity- und Access-Management-Programm einschließlich Rollendefinition, Lifecycle-Prozessen und regelmäßigen Berechtigungs-Reviews, die reine MFA-Aktivierung ist hierfür nicht ausreichend.
• Finanzsektor (BAIT, VAIT, KAIT, MaRisk): Detaillierte Vorgaben zu Authentifizierungs-Stärke, Privileged-Access-Management und Logging.
• 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 mit erweiterten Anforderungen: Versicherungsbedingungen schreiben regelmäßig phishing-resistente MFA für administrative Konten als Deckungsvoraussetzung vor.

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

Nächster Schritt

Eine erste Strukturierung der NIS2-Pflichtenlage einschließlich Authentifizierungs-Anforderungen lässt sich über den NIS2-Check anlegen. 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 2026-05-16. Sie ersetzt keine Einzelfallprüfung durch eine qualifizierte Beratung.