Artikel
MFA richtig priorisieren: Diese Konten sollten zuerst geschützt werden
Welche Konten brauchen MFA zuerst? So priorisieren Sie Admin-, E-Mail-, Cloud-, VPN- und besonders kritische Zugänge sinnvoll.
In diesem Artikel
Multi-Faktor-Authentifizierung (MFA) erschwert die Übernahme eines Kontos deutlich, weil ein gestohlenes Passwort allein nicht mehr ausreicht. Trotzdem bleiben in vielen Umgebungen Lücken: Ein Teil der Benutzer ist geschützt, während Administrator-, Recovery- oder externe Cloud-Konten weiterhin nur mit einem Passwort erreichbar sind. Wenn nicht alle Zugänge gleichzeitig umgestellt werden können, sollten deshalb zuerst die Konten abgesichert werden, deren Kompromittierung weitere Systeme, Daten oder Identitäten gefährden würde.
Nicht der Dienstname entscheidet, sondern der mögliche Schaden
Ein Mitarbeiterkonto für einen einzelnen SaaS-Dienst ist anders zu bewerten als ein Zugang, mit dem neue Benutzer angelegt, Kennwörter zurückgesetzt oder Sicherheitsregeln verändert werden können. Für die Reihenfolge bei der MFA-Einführung ist deshalb eine einfache Frage hilfreicher als eine lange Produktliste: Was kann jemand mit diesem Konto tun, wenn es übernommen wird?
Besonders kritisch sind Konten, die weitere Zugänge kontrollieren oder Wiederherstellungswege beeinflussen. Ein kompromittiertes E-Mail-Konto kann zum Beispiel Passwort-Reset-Nachrichten empfangen. Ein Administratorkonto kann neue Benutzer anlegen oder Berechtigungen verändern. Ein Zugang zum Domainregistrar kann DNS-Einträge ändern und damit Auswirkungen auf Website, E-Mail und andere Dienste haben.
MFA sollte langfristig überall dort zum Standard werden, wo ein Dienst sie sinnvoll unterstützt. Wenn die Einführung schrittweise erfolgen muss, lohnt es sich aber, diese Abhängigkeiten zuerst sichtbar zu machen.
Diese Konten sollten zuerst abgesichert werden
| Kontotyp | Warum er besonders kritisch ist |
|---|---|
| Identitäts- und Administratorkonten | Sie können Benutzer, Rollen, Richtlinien oder Sicherheitseinstellungen verändern. Ein einzelnes kompromittiertes Konto kann dadurch viele weitere Konten oder Systeme betreffen. |
| Geschäftliche E-Mail und zentrale Kollaboration | E-Mail ist häufig Teil von Passwort-Resets und interner Kommunikation. Wer ein Postfach kontrolliert, kann sich außerdem glaubwürdig als Mitarbeiter ausgeben. |
| Passwortmanager, Recovery-Konten und zentrale Wiederherstellungswege | Diese Zugänge schützen oder entsperren andere Konten. Werden sie übernommen, verliert ein zusätzliches Passwort an anderer Stelle schnell seinen Wert. |
| Domainregistrar, DNS, Hosting und Cloud-Administration | Änderungen an Domains, DNS, Servern oder Cloud-Ressourcen können mehrere Dienste gleichzeitig beeinflussen und im schlimmsten Fall den Zugriff auf weitere Systeme ermöglichen. |
| VPN, Fernzugriff und Remote-Support | Diese Konten schaffen einen direkten Weg in interne Systeme oder auf verwaltete Geräte. Deshalb sollten sie nicht nur mit einem Passwort erreichbar sein. |
| Finanz-, Lohn- und besonders sensible Fachanwendungen | Hier können Zahlungsprozesse, personenbezogene Daten oder geschäftskritische Informationen betroffen sein. |
| Normale Benutzerkonten | Sie sollten nach den besonders kritischen Zugängen nicht außen vor bleiben. Ein kompromittiertes Standardkonto kann als Ausgangspunkt für Phishing, Datenzugriff oder weitere Angriffe dienen. |
Diese Reihenfolge ist keine starre Produktliste. In einem Betrieb kann ein Branchenportal wichtiger sein als ein Cloud-Speicher, in einem anderen ist eine bestimmte Fachanwendung der zentrale Zugang zu Kundendaten. Entscheidend ist die Wirkung eines kompromittierten Kontos.
Administratorkonten brauchen eine stärkere Absicherung
Bei privilegierten Konten reicht es nicht, MFA nur irgendwie einzuschalten. Wo die Plattform es unterstützt, sollten für Administratoren möglichst phishing-resistente Verfahren eingesetzt werden. Microsoft empfiehlt für privilegierte Entra-Rollen ausdrücklich phishing-resistente MFA und nennt dafür unter anderem entsprechende Authentifizierungsstärken. Microsoft beschreibt die empfohlenen Schutzmaßnahmen für Administratorrollen hier.
Der Unterschied ist wichtig: Ein Einmalcode aus einer App ist besser als ein reines Passwort, kann aber weiterhin auf einer gefälschten Anmeldeseite eingegeben und weitergereicht werden. Der aktuelle NIST-Standard SP 800-63B beschreibt manuell eingegebene OTP-Verfahren deshalb nicht als phishing-resistent und nennt WebAuthn beziehungsweise FIDO2 als Beispiel für einen phishing-resistenten Ansatz. Die technischen Anforderungen sind im NIST SP 800-63B dokumentiert.
Für besonders privilegierte Konten kommen damit je nach Plattform beispielsweise Passkeys, FIDO2-Sicherheitsschlüssel oder Windows Hello for Business infrage. Welche Methode tatsächlich passt, hängt von den verwendeten Geräten, Diensten und Wiederherstellungswegen ab.
E-Mail und Identität gehören zusammen gedacht
Bei Cloud-Umgebungen ist der Benutzerzugang häufig gleichzeitig Identität für E-Mail, Dateien, Teams, Anwendungen und weitere Dienste. Wird nur eine einzelne Anwendung betrachtet, bleibt leicht die eigentliche Abhängigkeit unsichtbar.
Bei Microsoft 365 betrifft MFA deshalb nicht nur Outlook. Der Entra-Benutzer kann je nach Lizenzierung und Konfiguration Zugriff auf Exchange Online, Teams, SharePoint, OneDrive und weitere Anwendungen erhalten. Für Administratoren kommen zusätzlich Tenant-weite Rechte hinzu.
Wichtig ist außerdem der Wiederherstellungsweg. Wenn ein geschütztes Konto über eine ungeschützte externe E-Mail-Adresse oder ein schwach abgesichertes Zweitkonto zurückgesetzt werden kann, verlagert sich das Risiko lediglich auf diesen Zugang.
Die typischen MFA-Lücken liegen oft außerhalb des Hauptsystems
Viele Teams aktivieren MFA zuerst in Microsoft 365 oder Google Workspace und betrachten das Thema danach als erledigt. Kritische Zugänge liegen aber häufig daneben: beim Domainregistrar, im Passwortmanager, bei der Backup-Konsole, im Webhosting, im Remote-Support oder in einzelnen Fachanwendungen.
Gerade diese Konten werden leicht übersehen, weil sie nur von wenigen Personen genutzt werden. Das macht sie nicht weniger wichtig. Im Gegenteil: Ein selten genutzter Zugang mit weitreichenden Rechten kann lange unverändert bestehen und fällt im normalen Benutzer-Onboarding kaum auf.
Technische Dienstkonten sind dabei ein Sonderfall. Ein nicht interaktiv genutztes Konto sollte nicht einfach wie ein normaler Mitarbeiterzugang behandelt werden. Wo möglich, sind dafür verwaltete Identitäten, Zertifikate oder andere nicht interaktive Verfahren mit minimalen Rechten sinnvoller als ein gemeinsam verwendetes Benutzerkonto mit Passwort.
MFA einführen, ohne sich selbst auszusperren
MFA sollte nicht spontan auf einem einzelnen Administrator aktiviert werden, ohne Registrierung und Recovery mitzudenken. Vor der Durchsetzung muss geklärt sein, welche Faktoren die betroffenen Personen verwenden, wie ein verlorenes Gerät ersetzt wird und wer im Notfall Zugriff wiederherstellen darf.
Für kritische Konten sind mindestens diese Punkte sinnvoll:
- geeignete MFA-Methode festlegen und registrieren
- zweiten beziehungsweise alternativen Wiederherstellungsweg dokumentieren
- persönliche Admin-Zugänge statt gemeinsam genutzter Konten verwenden
- Ausnahmen und noch nicht geschützte Konten ausdrücklich erfassen
- nach der Aktivierung testen, ob Anmeldung und Wiederherstellung wie vorgesehen funktionieren
Bei zentralen Identitätsplattformen sollte eine Richtlinie zunächst kontrolliert eingeführt werden. Microsoft warnt bei phishing-resistenter MFA für Administratoren ausdrücklich davor, die Richtlinie zu aktivieren, bevor die passenden Methoden registriert wurden, weil sonst ein Tenant-Lockout drohen kann.
Eine kleine Kontenliste reicht für den Start
Für eine erste Bestandsaufnahme braucht es kein komplexes IAM-Projekt. Eine einfache Tabelle macht bereits sichtbar, wo die größten Lücken liegen:
| Konto oder System | Verantwortlich | Adminrechte | MFA aktiv | Methode | Recovery geprüft |
|---|---|---|---|---|---|
| Microsoft-365-Administratorkonto (Beispiel) | IT | Ja | Ja | Passkey / FIDO2 | Ja |
| Domainregistrar (Beispiel) | IT / Geschäftsführung | Ja | Nein | Nicht festgelegt | Offen |
| Lohnabrechnung (Beispiel) | Buchhaltung | Nein | Ja | Authenticator-App | Ja |
Die Beispielwerte sind bewusst fiktiv. Für die eigene Umgebung reicht es zunächst, die wichtigsten Systeme einzutragen und Konten ohne MFA oder mit ungeklärter Wiederherstellung sichtbar zu markieren. Danach lässt sich die Reihenfolge sachlich statt nach Bauchgefühl festlegen.
MFA zuerst dort einsetzen, wo ein Konto viele Türen öffnet
Die wichtigste Frage lautet nicht, ob jedes Tool sofort dieselbe MFA-Methode verwendet. Zuerst müssen die Zugänge abgesichert werden, über die sich weitere Konten, Daten oder Systeme kontrollieren lassen. Danach sollte MFA schrittweise zum Standard für alle unterstützten Benutzerkonten werden.
Besondere Aufmerksamkeit verdienen Administratoren, E-Mail und zentrale Identitäten, Recovery-Wege, Fernzugänge sowie Infrastruktur- und Finanzkonten. Für privilegierte Zugänge sind phishing-resistente Verfahren die bessere Zielrichtung als einfache Bestätigungscodes.
Wenn unklar ist, welche Konten und Zugänge zuerst geprüft werden sollten, kann eine strukturierte Bestandsaufnahme im Rahmen der IT-Sicherheit für KMU helfen, die wichtigsten Lücken zu priorisieren.