Multi-Faktor-Authentifizierung im Unternehmen: Verfahren, Phishing-Resistenz und Rollout

Multi-Faktor-Authentifizierung im Unternehmen ist eine der wirksamsten Einzelmaßnahmen gegen die Übernahme von Benutzerkonten, und dennoch wird sie in vielen Organisationen nur lückenhaft umgesetzt. Typisch ist ein Zustand, in dem die Cloud-Plattform für Büroanwendungen per App-Bestätigung geschützt ist, während der VPN-Zugang, die Administrationsoberfläche der Firewall oder das Konto des externen Dienstleisters weiterhin nur mit Benutzername und Passwort erreichbar sind. Angreifer suchen gezielt nach genau diesen Lücken. Hinzu kommt, dass nicht jedes MFA-Verfahren gleich stark ist: Einmalcodes per SMS oder einfache Push-Bestätigungen lassen sich mit Adversary-in-the-Middle-Phishing oder durch gezielte Ermüdung der Nutzer aushebeln. Dieser Beitrag ordnet die gängigen Faktorarten und Verfahren ein, vergleicht sie hinsichtlich Sicherheit und Betriebsaufwand und zeigt, wie sich phishing-resistente MFA mit Conditional Access, sauber definierten Ausnahmen und Notfallkonten verbinden lässt. Abschließend folgen ein Rollout-Schrittplan sowie die Bezüge zu ISO/IEC 27001, BSI IT-Grundschutz, DSGVO und NIS2, damit Geschäftsführung und Fachverantwortliche die Maßnahme nicht nur technisch, sondern auch im Hinblick auf Nachweis und Governance planen können.

Hinweis: Dieser Beitrag gibt ausschließlich die redaktionellen Ansichten der Redaktion von cyberschutzbetrieb.de wieder. Er stellt keine Rechtsberatung dar und ersetzt nicht die Beratung durch eine qualifizierte Rechtsanwältin oder einen qualifizierten Rechtsanwalt. Für rechtlich verbindliche Auskünfte zu Ihrem konkreten Fall wenden Sie sich bitte an einen zugelassenen Rechtsbeistand.

Titelbild: Foto von Onur Binay auf Unsplash.

Grundlagen: Was Multi-Faktor-Authentifizierung im Unternehmen leisten muss

Authentifizierung beantwortet die Frage, ob eine Person tatsächlich diejenige ist, für die sie sich ausgibt. Ein einzelnes Passwort ist dafür ein schwacher Nachweis, weil es kopiert, erraten, wiederverwendet oder abgefischt werden kann, ohne dass der Inhaber es bemerkt. Multi-Faktor-Authentifizierung kombiniert deshalb mindestens zwei voneinander unabhängige Faktoren aus unterschiedlichen Kategorien. Entscheidend ist die Unabhängigkeit: Zwei Passwörter hintereinander sind keine MFA, ebenso wenig ein Passwort und eine Sicherheitsfrage.

Die drei Faktorkategorien

• Wissen: Passwort, Passphrase oder PIN. Der Faktor ist beliebig kopierbar und damit anfällig für Phishing, Credential Stuffing und Keylogger.
• Besitz: Smartphone mit Authenticator-App, Hardware-Token, Smartcard oder Sicherheitsschlüssel. Der Angreifer muss das Gerät oder dessen geheimen Schlüssel kontrollieren.
• Inhärenz: biometrische Merkmale wie Fingerabdruck oder Gesichtserkennung. In der Unternehmenspraxis dient Biometrie meist dazu, einen lokal gespeicherten Schlüssel freizugeben, und wird nicht zentral übertragen.

Moderne Verfahren wie FIDO2 verschieben den Schwerpunkt: Der Besitzfaktor ist ein kryptografischer Schlüssel, der das Gerät nie verlässt, und die lokale Freigabe erfolgt per PIN oder Biometrie. Damit entsteht eine Zwei-Faktor-Kombination, bei der kein wiederverwendbares Geheimnis über das Netz übertragen wird. Genau dieses Merkmal ist die Grundlage für Phishing-Resistenz.

Kontextsignale sind kein Faktor

Standort, IP-Adresse, Gerätestatus oder Uhrzeit sind wertvolle Signale für eine Risikobewertung, ersetzen aber keinen Authentifizierungsfaktor. Sie gehören in die Zugriffsrichtlinie (Conditional Access) und entscheiden darüber, ob und wie stark authentifiziert werden muss. Diese Trennung ist wichtig für die Dokumentation, weil Prüfer regelmäßig fragen, welche Faktoren tatsächlich eingesetzt werden und welche Bedingungen lediglich zusätzlich greifen.

MFA-Verfahren im Vergleich

Die Wahl des Verfahrens bestimmt, gegen welche Angriffe die MFA tatsächlich schützt. Die folgende Übersicht bewertet die in Unternehmen verbreiteten Methoden nach Sicherheitsniveau, Phishing-Resistenz und Betriebsaufwand. Die Einstufungen sind qualitativ und dienen als Orientierung für die Auswahl, nicht als abschließende Risikoanalyse.

Verfahren	Funktionsprinzip	Phishing-Resistenz	Typische Schwächen	Einsatzempfehlung
SMS- oder Sprachcode	Einmalcode über das Mobilfunknetz	Nein	SIM-Swapping, Umleitung, Abgreifen per Phishing-Seite, Abhängigkeit vom Netz	Nur als Übergangslösung oder letzte Rückfalloption
TOTP (Authenticator-App oder Token)	Zeitbasierter Einmalcode aus gemeinsamem Geheimnis	Nein	Code kann in Echtzeit auf gefälschter Seite abgegriffen werden, Geheimnis bei Export oder Backup kopierbar	Solide Basis für Standardkonten und Systeme ohne FIDO2-Unterstützung
Push-Benachrichtigung	Bestätigung der Anmeldung in einer App	Nein (einfache Variante)	MFA-Fatigue, versehentliche Bestätigung, fehlender Kontext	Nur mit Number Matching und Standort- sowie Anwendungsanzeige
FIDO2-Sicherheitsschlüssel	Asymmetrische Kryptografie, an Domain gebunden, Hardware-Schlüssel	Ja	Beschaffung, Verlustprozess, Ersatzschlüssel nötig	Erste Wahl für Administratoren und besonders exponierte Rollen
Passkeys (gerätegebunden oder synchronisiert)	FIDO2-Anmeldedaten auf Endgerät oder in Plattform-Schlüsselbund	Ja	Bei synchronisierten Passkeys hängt die Sicherheit vom Cloud-Konto des Schlüsselbunds ab	Breiter Rollout für Mitarbeitende, gerätegebunden für sensible Rollen
Smartcard oder zertifikatsbasierte Anmeldung	Privater Schlüssel auf Chip, PKI-gestützt	Ja	Aufwendige PKI, Kartenleser, Zertifikatslebenszyklus	Umgebungen mit bestehender PKI, hohe Schutzbedarfe, regulierte Bereiche

Die Tabelle macht deutlich, dass die Frage nicht lautet, ob MFA eingesetzt wird, sondern welche. Ein Unternehmen, das flächendeckend SMS-Codes nutzt, hat gegenüber reinen Passwörtern zwar einen Fortschritt erzielt, bleibt aber gegenüber professionell durchgeführten Phishing-Kampagnen verwundbar. Sinnvoll ist ein gestuftes Modell: phishing-resistente Verfahren für privilegierte und exponierte Konten, starke App-basierte Verfahren als Standard und schwache Verfahren nur dort, wo es technisch keine Alternative gibt.

Phishing-resistente MFA: Warum der Ursprung entscheidet

Klassische Einmalcodes haben eine grundlegende Schwäche: Sie sind nicht an die Website gebunden, auf der sie eingegeben werden. Bei einem Adversary-in-the-Middle-Angriff leitet ein Reverse-Proxy die Anmeldung transparent an den echten Dienst weiter. Der Nutzer gibt Passwort und Code ein, der Proxy reicht beides durch und übernimmt anschließend das Sitzungscookie. Die MFA wurde formal erfüllt, der Angreifer ist dennoch angemeldet.

FIDO2 und zertifikatsbasierte Verfahren verhindern dieses Muster, weil die kryptografische Signatur an den Ursprung (die Domain) gebunden ist. Der Authenticator signiert nur für die registrierte Domain; eine gefälschte Seite erhält entweder keine oder eine für den echten Dienst wertlose Antwort. Deshalb sprechen Fachleute von phishing-resistenter MFA. Sie ist kein Allheilmittel, denn Sitzungstoken können nach erfolgreicher Anmeldung weiterhin auf kompromittierten Endgeräten gestohlen werden. Ergänzend sind daher kurze Sitzungslaufzeiten, Token-Bindung an Geräte, soweit von der Plattform unterstützt, und ein verwalteter Gerätezustand sinnvoll.

„MFA ist nicht gleich MFA. Entscheidend ist, ob das Verfahren einem Angreifer, der die Anmeldung in Echtzeit mitliest, noch einen verwertbaren Nachweis liefert.“

MFA-Fatigue und Push-Bombing

Push-Verfahren sind komfortabel und deshalb weit verbreitet. Genau dieser Komfort wird ausgenutzt: Ein Angreifer, der das Passwort bereits kennt, löst wiederholt Anmeldeversuche aus, bis die betroffene Person aus Versehen, Ungeduld oder Verunsicherung auf „Genehmigen“ tippt. Häufig wird der Druck durch einen Anruf verstärkt, in dem sich der Angreifer als interner IT-Support ausgibt.

Gegenmaßnahmen

• Number Matching: Die Anmeldeseite zeigt eine Zahl, die in der App eingegeben werden muss. Blindes Bestätigen wird damit unmöglich.
• Zusatzkontext: Anzeige von Anwendung, ungefährem Standort und Gerät in der Push-Nachricht.
• Ratenbegrenzung: Sperre oder Verzögerung nach mehreren abgelehnten oder unbeantworteten Anfragen.
• Meldefunktion: Eine Option „Das war ich nicht“, die automatisch einen Sicherheitsvorfall auslöst und das Konto sperren oder das Passwort zurücksetzen kann.
• Klarer Kommunikationsgrundsatz: Die interne IT fordert niemals telefonisch zur Bestätigung einer Anmeldung auf. Dieser Satz gehört in jede Schulung und jedes Onboarding.

Langfristig ist der Umstieg auf phishing-resistente Verfahren die nachhaltigere Lösung, weil ein FIDO2-Schlüssel ohne physische Interaktion des Nutzers am eigenen Gerät keine Anmeldung freigibt.

Conditional Access: Risikobasierte Steuerung statt Pauschalregel

Conditional Access bezeichnet Richtlinien, die abhängig von Nutzer, Anwendung, Gerät, Standort und Risiko entscheiden, ob ein Zugriff erlaubt, blockiert oder an zusätzliche Bedingungen geknüpft wird. Die großen Identitätsplattformen bieten entsprechende Funktionen, die Begriffe unterscheiden sich je nach Hersteller. Richtig konfiguriert, erhöht Conditional Access die Sicherheit und senkt zugleich die Reibung für Nutzer, weil in vertrauenswürdigen Situationen weniger häufig nachgefragt wird.

Bewährte Richtlinienbausteine

1. MFA für alle Benutzer und alle Cloud-Anwendungen als Grundregel, ohne generelle Ausnahme für das Firmennetz.
2. Phishing-resistente Authentifizierungsstärke für alle administrativen Rollen verpflichtend.
3. Blockieren von Legacy-Protokollen, die keine moderne Authentifizierung unterstützen (etwa Basic Authentication bei älteren Mail-Protokollen).
4. Zugriff auf sensible Anwendungen nur von verwalteten und konformen Geräten.
5. Erneute Authentifizierung bei erhöhtem Anmelde- oder Benutzerrisiko sowie beim Registrieren neuer Sicherheitsinformationen.
6. Geografische Einschränkungen nur ergänzend, da sie sich per VPN oder Proxy umgehen lassen.

Eine typische Stolperfalle ist die Ausnahme für „vertrauenswürdige“ Standorte. Wird das Firmennetz pauschal von der MFA befreit, genügt einem Angreifer ein kompromittiertes Endgerät im internen Netz, um sich ohne zweiten Faktor anzumelden. Ebenso kritisch ist der Prozess zur Registrierung neuer Faktoren: Wer mit Passwort allein einen neuen Authenticator hinzufügen kann, hat die MFA faktisch ausgehebelt.

Priorisierung: Wo MFA zuerst greifen muss

Nicht jedes Unternehmen kann alle Konten und Systeme gleichzeitig umstellen. Eine risikoorientierte Reihenfolge stellt sicher, dass die Konten mit dem größten Schadenspotenzial zuerst geschützt sind. Bewährt hat sich folgende Priorisierung:

1. Administrative Konten: Domänen- und Cloud-Administratoren, Konten mit Zugriff auf Backup, Virtualisierung, Firewall und Identitätsverwaltung. Hier gilt ausschließlich phishing-resistente MFA, idealerweise mit getrennten Admin-Konten.
2. Remote-Zugänge: VPN, Remote-Desktop-Gateways, Fernwartungszugänge externer Dienstleister und Zugänge zu Jump-Hosts. Diese Systeme sind aus dem Internet erreichbar und ein häufiger Einstiegspunkt.
3. E-Mail und Kollaboration: Ein übernommenes Postfach ermöglicht Rechnungsbetrug, interne Phishing-Wellen und das Zurücksetzen weiterer Passwörter.
4. Cloud-Dienste und SaaS: ERP, CRM, Buchhaltung, Dateiablagen. Wo möglich, über Single Sign-on an den zentralen Identitätsanbieter anbinden, damit die MFA-Richtlinie einheitlich greift.
5. Interne Anwendungen und Endgeräteanmeldung: Schrittweise, abhängig von technischer Unterstützung und Schutzbedarf.

Besondere Aufmerksamkeit verdienen Konten, die keinem Menschen eindeutig zugeordnet sind: Funktionspostfächer, gemeinsam genutzte Konten und Konten von Dienstleistern. Gemeinsam genutzte Anmeldungen sollten, wo immer möglich, durch personalisierte Konten mit Delegation ersetzt werden, weil sich MFA an einem geteilten Smartphone kaum sauber betreiben lässt.

Ausnahmen, Dienstkonten und Notfallkonten (Break-Glass)

Ausnahmen kontrolliert zulassen

In jeder Umgebung gibt es Systeme, die MFA technisch nicht unterstützen, etwa ältere Maschinensteuerungen, Druckerdienste oder Schnittstellen zwischen Anwendungen. Solche Ausnahmen sind zulässig, wenn sie dokumentiert, begründet, zeitlich befristet und durch kompensierende Maßnahmen abgesichert sind. Dazu zählen Netzwerkbeschränkungen auf bestimmte Quelladressen, lange zufällige Passwörter aus einem Passwort-Tresor, eingeschränkte Berechtigungen und eine gezielte Protokollauswertung. Ein Ausnahmeregister mit Verantwortlichem, Ablaufdatum und Überprüfungstermin gehört zum Mindeststandard.

Dienstkonten (Service Accounts) sollten keine interaktive Anmeldung erlauben und, soweit die Plattform es unterstützt, durch verwaltete Identitäten oder zertifikatsbasierte Anmeldungen ersetzt werden. Ein Dienstkonto mit statischem Passwort und globalen Administratorrechten ist ein bevorzugtes Ziel.

Notfallkonten richtig einrichten

Break-Glass-Konten sichern den Zugriff, wenn der reguläre Anmeldeweg ausfällt, etwa bei einer Störung des MFA-Dienstes, einer Fehlkonfiguration der Zugriffsrichtlinien oder dem Verlust aller Admin-Token. Folgende Grundsätze haben sich bewährt:

• Mindestens zwei Notfallkonten, ausschließlich cloud-basiert und nicht mit dem lokalen Verzeichnis synchronisiert.
• Absicherung mit FIDO2-Schlüsseln, die getrennt voneinander physisch verwahrt werden (etwa Tresor mit Vier-Augen-Prinzip).
• Gezielte Ausnahme nur aus den Richtlinien, die einen Lockout verursachen könnten, nicht aus allen Richtlinien.
• Alarmierung bei jeder Anmeldung eines Notfallkontos an das Sicherheitsteam.
• Regelmäßiger Test der Funktionsfähigkeit, dokumentiert im Notfallhandbuch.

Ein häufiger Fehler besteht darin, das Notfallkonto mit einem Passwort ohne jede Überwachung zu betreiben. Damit entsteht genau der unkontrollierte Hintereingang, den MFA verhindern soll.

Rollout-Schrittplan für Multi-Faktor-Authentifizierung im Unternehmen

Ein strukturierter Rollout reduziert Supportaufwand und Widerstände. Der folgende Ablauf lässt sich an die Größe der Organisation anpassen.

1. Bestandsaufnahme: Alle Anmeldewege erfassen (Cloud, VPN, Remote Desktop, Fernwartung, SaaS, Admin-Oberflächen), dazu Identitätsquellen, Legacy-Protokolle und Konten ohne eindeutige Zuordnung.
2. Zielbild und Richtlinie: Zulässige Verfahren je Schutzbedarf festlegen, Ausnahmeprozess definieren, Verantwortlichkeiten klären und die Richtlinie durch die Geschäftsführung freigeben lassen.
3. Technische Vorbereitung: Single Sign-on für relevante Anwendungen, Conditional-Access-Richtlinien zunächst im Berichtsmodus, Notfallkonten einrichten, Hardware-Schlüssel beschaffen.
4. Pilot: Start mit IT-Team und Administratoren, anschließend eine repräsentative Nutzergruppe aus mehreren Abteilungen. Supportfälle auswerten und Anleitungen anpassen.
5. Registrierungskampagne: Mitarbeitende registrieren ihre Faktoren in einem definierten Zeitfenster, idealerweise mit Unterstützung vor Ort. Registrierung neuer Faktoren nur nach starker Authentifizierung oder mit befristetem Zugangscode (Temporary Access Pass).
6. Durchsetzung in Wellen: Richtlinien schrittweise vom Berichts- in den Erzwingungsmodus überführen, Legacy-Protokolle abschalten.
7. Prozesse für Verlust und Wechsel: Verfahren für verlorene Geräte, Gerätewechsel, Neueintritte und Austritte festlegen und mit dem Service Desk üben. Die Identitätsprüfung am Telefon ist ein kritischer Punkt, weil Angreifer gezielt den Helpdesk anrufen.
8. Überwachung und Weiterentwicklung: Kennzahlen wie Abdeckungsgrad, Anteil phishing-resistenter Verfahren und Zahl offener Ausnahmen regelmäßig berichten; schwache Verfahren planmäßig ablösen.

Checkliste für die Abnahme

• Alle administrativen Konten nutzen ausschließlich phishing-resistente Verfahren.
• Alle aus dem Internet erreichbaren Zugänge verlangen MFA.
• Legacy-Authentifizierung ist blockiert oder dokumentiert ausgenommen.
• Push-Verfahren sind mit Number Matching konfiguriert.
• Notfallkonten sind eingerichtet, verwahrt, überwacht und getestet.
• Das Ausnahmeregister ist vollständig und hat Ablaufdaten.
• Der Helpdesk-Prozess zur Identitätsprüfung ist dokumentiert und geschult.

Normbezüge: ISO 27001, BSI IT-Grundschutz, DSGVO und NIS2

ISO/IEC 27001 Anhang A

In ISO/IEC 27001 sind im Anhang A vor allem zwei Maßnahmen einschlägig. Maßnahme 5.17 (Authentifizierungsinformationen) regelt Zuteilung, Verwaltung und Umgang mit Authentifizierungsinformationen, also etwa den Prozess zur Ausgabe und Registrierung von Token oder den Umgang mit Initialpasswörtern. Maßnahme 8.5 (Sichere Authentifizierung) fordert sichere Authentifizierungstechnologien und Verfahren entsprechend den Zugangsbeschränkungen und der Richtlinie zur Zugangssteuerung. Im Rahmen eines ISMS sollten die Auswahl der MFA-Verfahren und deren Zuordnung zu Schutzbedarfen in der Erklärung zur Anwendbarkeit nachvollziehbar begründet sein.

BSI IT-Grundschutz

Im IT-Grundschutz-Kompendium des BSI behandelt der Baustein ORP.4 (Identitäts- und Berechtigungsmanagement) Anforderungen an Kennungen, Authentisierung und die Verwaltung von Berechtigungen. Für Unternehmen, die sich am Grundschutz orientieren, empfiehlt es sich, die MFA-Richtlinie direkt auf die Anforderungen dieses Bausteins abzubilden. Weitere Hinweise zur Zwei-Faktor-Authentisierung veröffentlicht das Bundesamt für Sicherheit in der Informationstechnik.

DSGVO Art. 32

Art. 32 der Datenschutz-Grundverordnung verpflichtet Verantwortliche und Auftragsverarbeiter, unter Berücksichtigung des Stands der Technik, der Implementierungskosten und des Risikos geeignete technische und organisatorische Maßnahmen zu treffen. MFA wird für Zugänge zu personenbezogenen Daten mit erhöhtem Schutzbedarf regelmäßig als Stand der Technik betrachtet. Fehlt sie bei einem aus dem Internet erreichbaren Zugang, lässt sich im Fall einer Datenschutzverletzung schwer begründen, dass angemessene Maßnahmen getroffen wurden.

NIS2

Die Richtlinie (EU) 2022/2555 (NIS2) nennt in Art. 21 Abs. 2 Buchstabe j ausdrücklich die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung sowie gesicherte Kommunikationssysteme, wo angemessen. Für Einrichtungen im Anwendungsbereich der nationalen Umsetzung ist MFA damit Teil der verpflichtenden Risikomanagementmaßnahmen. Die Geschäftsleitung trägt nach der Richtlinie Verantwortung für Billigung und Überwachung dieser Maßnahmen, was eine regelmäßige Berichterstattung zum Umsetzungsstand nahelegt.

Typische Stolperfallen aus der Praxis

• Lücken bei Altprotokollen: MFA ist aktiv, aber ältere Mailprotokolle erlauben weiterhin reine Passwortanmeldungen.
• Unsichere Wiederherstellung: Der Reset des zweiten Faktors erfolgt per E-Mail oder Anruf ohne belastbare Identitätsprüfung.
• Dienstleisterzugänge vergessen: Fernwartungskonten externer Partner sind von der Richtlinie ausgenommen oder laufen über eigene, ungeschützte Portale.
• Private Geräte als einziger Faktor: Mitarbeitende ohne Dienst-Smartphone fallen auf SMS zurück. Hardware-Schlüssel sind hier oft die sauberere und datenschutzfreundlichere Lösung.
• Fehlende Mitbestimmung: Die Nutzung privater Geräte oder biometrischer Verfahren kann Beteiligungsrechte des Betriebsrats berühren. Eine frühzeitige Abstimmung vermeidet Verzögerungen.

FAQ

Ist eine Authenticator-App mit Einmalcode ausreichend?
Für Standardkonten ist ein zeitbasierter Einmalcode ein deutlicher Fortschritt gegenüber Passwörtern. Gegen Echtzeit-Phishing schützt er jedoch nicht. Für Administratoren und exponierte Rollen sollten phishing-resistente Verfahren wie FIDO2-Schlüssel, Passkeys oder Smartcards eingesetzt werden.

Was unterscheidet Passkeys von klassischen FIDO2-Sicherheitsschlüsseln?
Beide beruhen auf demselben Standard. Ein Sicherheitsschlüssel ist ein separates Hardware-Gerät, während Passkeys auf Smartphone oder Rechner gespeichert und teils über Plattform-Schlüsselbunde synchronisiert werden. Für sensible Rollen sind gerätegebundene Varianten vorzuziehen.

Wie viele Notfallkonten sind sinnvoll?
Üblich sind mindestens zwei, damit bei Verlust oder Defekt eines Faktors ein zweiter Zugang verbleibt. Beide sollten mit getrennt verwahrten Hardware-Schlüsseln geschützt und bei jeder Nutzung alarmiert werden.

Muss MFA auch im internen Netz gelten?
Ja, zumindest für privilegierte Zugriffe und sensible Anwendungen. Eine pauschale Ausnahme für das Firmennetz erleichtert Angreifern, die bereits ein internes Endgerät kontrollieren, die seitliche Ausbreitung.

Welche Rolle spielt der Service Desk?
Eine zentrale. Wenn der Reset eines zweiten Faktors telefonisch ohne sichere Identitätsprüfung möglich ist, umgehen Angreifer die MFA über Social Engineering. Verbindliche Prüfverfahren und dokumentierte Freigaben sind deshalb Teil jedes MFA-Konzepts.