Die Maßnahme, die Sie längst umgesetzt haben
Die meisten Luxemburger Unternehmen einer gewissen Größe haben dieses Projekt vor Jahren abgeschlossen. Die Multi-Faktor-Authentifizierung wurde für Microsoft 365 aktiviert, der Versicherer fragte danach und war zufrieden, der Prüfer setzte sein Häkchen, und das Thema Identität verschwand still aus dem Risikoregister. Eine Zeit lang war das eine vertretbare Entscheidung.
Dann erhielt jemand in der Buchhaltung eine Nachricht zu einer Compliance-Prüfung, meldete sich über eine Seite an, die exakt wie das Firmenportal aussah, bestätigte die Anfrage auf dem Handy, weil er sich ja selbst anmeldete — und nichts schien schiefzugehen. Zwei Wochen später ging eine Lieferantenzahlung auf ein falsches Konto, oder ein Postfach begann internes Spear-Phishing zu versenden, und die Untersuchung ergab, dass auf das Konto seit jenem Nachmittag durchgehend zugegriffen worden war, ohne eine einzige weitere Authentifizierungsaufforderung.
Die MFA hat genau so funktioniert, wie sie sollte. Das ist der Punkt, den es zu verstehen gilt.
Angreifer raten nicht mehr, sie leiten weiter
Die Technik heißt Adversary-in-the-Middle-Phishing, und sie ist eher banal als exotisch. Das Opfer landet auf einer Seite unter der Kontrolle des Angreifers, doch statt das Passwort in eine Datenbank zu schreiben, arbeitet diese Seite als transparenter Proxy zum echten Microsoft-Anmeldedienst. Jeder Tastenanschlag wird an den echten Dienst weitergereicht, jede Antwort zurück. Der Nutzer sieht den authentischen Anmeldebildschirm, weil es der authentische Anmeldebildschirm ist. Er tippt sein Passwort, das weitergeleitet wird. Er erhält eine MFA-Aufforderung, die eine echte Aufforderung ist. Er bestätigt sie auf dem Handy oder gibt die sechs Ziffern ein, und Microsoft stellt — völlig zu Recht, nachdem alles Geprüfte geprüft wurde — ein Sitzungstoken aus.
Dieses Token nimmt der Angreifer mit. Von da an ist der zweite Faktor bedeutungslos, denn das Token belegt, dass die Authentifizierung bereits stattgefunden hat. E-Mail, Dateien, Teams und jede Anwendung hinter derselben Anmeldung stehen ohne weitere Aufforderung offen, oft solange das Token gültig bleibt, und deutlich länger, wenn der Angreifer währenddessen eine eigene Authentifizierungsmethode registriert.
Microsofts Threat-Intelligence-Team hat im Mai eine ausführliche Analyse einer solchen Kampagne veröffentlicht. Zwischen dem 14. und 16. April 2026 erreichte sie über 35.000 Nutzer in mehr als 13.000 Organisationen in 26 Ländern, mit einer vorgetäuschten internen „Verhaltenskodex-Prüfung" als Köder. Die Kette führte über einen PDF-Anhang, eine vom Angreifer kontrollierte Domain, ein als Sitzungsprüfung ausgegebenes Cloudflare-CAPTCHA, eine zweite Bildauswahl-Verifizierung und schließlich eine Schaltfläche „Mit Microsoft anmelden", die die Authentifizierungssitzung weiterleitete und die Token abgriff. Professionelle Dienstleistungen machten elf Prozent der Ziele aus, neben Gesundheitswesen, Finanzdienstleistungen und Technologie.
Lesen Sie diese Kette noch einmal und achten Sie darauf, was fehlt. Keine Schadsoftware, kein Exploit, keine Schwachstelle in der Umgebung des Kunden. Die beiden CAPTCHAs dienen dazu, automatisierte Analyse auszusieben und nebenbei den Menschen zu beruhigen. Es handelt sich um eine gut gebaute Webanwendung und einen plausiblen Vorwand, und es gibt einen funktionierenden Markt, der diese Fähigkeit an Leute vermietet, die sie selbst nicht entwickeln könnten.
Warum die Bestätigung auf Ihrem Handy nicht hilft
Push-Bestätigungen und Einmalcodes teilen eine Konstruktionsannahme: dass die Person, die bestätigen soll, weiß, für welche Website sie bestätigt. Diese Information wird nicht mitgeliefert. Ein sechsstelliger Code ist für den echten Dienst genauso gültig wie für einen davorgeschalteten Proxy, und eine Push-Meldung fragt „Melden Sie sich gerade an?" — worauf die ehrliche Antwort in diesem Szenario Ja lautet.
Der Zahlenabgleich schützt vor einem anderen Angriff: jenem, bei dem ein Angreifer mit gestohlenem Passwort um drei Uhr nachts Aufforderungen sendet, bis jemand auf Bestätigen tippt. Hier hilft er nicht, denn der Nutzer meldet sich aktiv an und liest die Zahl bereitwillig von der Seite des Angreifers ab.
Das ist kein Argument, die MFA abzuschalten
Die Größenordnungen sollten stimmen, denn die Sicherheitsbranche neigt dazu, eine Maßnahme für tot zu erklären, sobald jemand einen Weg daran vorbei findet. Microsofts Digital Defense Report 2025 ordnet siebenundneunzig Prozent der Identitätsangriffe dem Password Spraying zu — massenhaftem, primitivem Durchprobieren gegen offengelegte Benutzernamen — auf Basis von rund 38 Millionen Identitätsrisiko-Erkennungen, die an einem durchschnittlichen Tag ausgewertet werden. Gewöhnliche MFA stoppt praktisch dieses gesamte Volumen, und eine Organisation ohne sie hat kein ausgefeiltes Adversary-in-the-Middle-Problem. Sie hat ein weit einfacheres und weit wahrscheinlicheres.
Verändert hat sich das obere Ende. KI hat den Vorwand billig und die Formulierung tadellos gemacht: Microsoft berichtet von KI-gestützten Phishing-Kampagnen mit Klickraten von bis zu vierundfünfzig Prozent gegenüber rund zwölf Prozent bei herkömmlichen Kampagnen. Grammatik und Layout sind nicht länger das verräterische Zeichen — was bedeutet, dass der Rat, den wir Anwendern seit einem Jahrzehnt geben, nämlich auf Fehler zu achten, still und leise aufgehört hat zu funktionieren. Wie sich das regional äußert, haben wir in den Angriffsmustern beschrieben, die wir in der Großregion beobachten, und wir haben untersucht, was die Datenlage zu Awareness-Schulungen sagt. Kurz gefasst: Schulung hebt das Grundniveau und wird Sie hier nicht retten. Dieses Problem muss in der Authentifizierungsschicht gelöst werden.
Der entscheidende Unterschied: Ein phishbarer Faktor belegt, dass jemand eine Aufforderung erfüllt hat. Ein phishing-resistenter Faktor belegt, dass er sie auf der echten Domain erfüllt hat. Alles Weitere ist Detail.
Microsoft hat die Frist für Sie gesetzt
Wenn Sie Microsoft 365 einsetzen, ist Ihnen diese Entscheidung weitgehend abgenommen worden — nach einem veröffentlichten Zeitplan. Im Juli hat Microsoft bestätigt, dass Passkeys zur Standard-Authentifizierungsmethode in Entra ID werden, mit diesen Terminen:
- 1. September 2026 — automatische Aktivierung von Passkeys und Registrierungsaufforderungen für Nutzer, die derzeit SMS oder Sprachanruf verwenden.
- 18. September 2026 — Veröffentlichung von Preisen, Vertragsbedingungen und Listen unterstützter Telekommunikationsanbieter für Organisationen, die SMS beibehalten müssen.
- 30. Oktober 2026 — Administratoren können einen Drittanbieter für Telekommunikation auswählen und konfigurieren.
- 1. Februar 2027 — Microsoft stellt die eigene Zustellung von SMS- und Sprach-Authentifizierung ein, und die Aufforderung zur Passkey-Registrierung wird verpflichtend. Microsofts Formulierung ist eindeutig: „There will be no opt-out option."
Zwei Klarstellungen, weil beide häufig missverstanden werden. Erstens geht es um das Ende der von Microsoft bereitgestellten SMS- und Sprachzustellung, nicht um ein Verbot von SMS: Organisationen, die es wirklich brauchen, können über den Microsoft Security Store einen Telekommunikationspartner beauftragen und diesen direkt bezahlen. Zweitens gelten diese Termine nur für Entra ID in der Public Cloud; andere Cloud-Umgebungen folgen einem eigenen Zeitplan.
Praktisch heißt das: Nichts zu tun ist jetzt eine Entscheidung mit Datum. Ihre Nutzer werden in wenigen Tagen aufgefordert, einen Passkey zu registrieren — unabhängig davon, ob Sie Ihre Passkey-Strategie festgelegt, Ihren Service Desk gebrieft oder geklärt haben, was mit dem Schichtleiter im Lager geschieht, der kein Diensthandy besitzt.
Eine Migration, die nicht in Woche zwei zusammenbricht
Passkeys und FIDO2-Sicherheitsschlüssel funktionieren, weil der Berechtigungsnachweis kryptografisch an die ausstellende Domain gebunden ist. Vor einer nachgebauten Seite warnt der Authentifikator den Nutzer nicht — er verweigert schlicht, weil die Domain nicht übereinstimmt. Es bleibt keine Entscheidung, die ein Mensch falsch treffen könnte, und genau darum geht es.
In einer Organisation mit fünfzig bis fünfhundert Beschäftigten ist das technisch nicht schwierig. Es scheitert an dem, was niemand eingeplant hat.
1. Finden Sie heraus, was Ihre Nutzer heute tatsächlich verwenden
Ziehen Sie die registrierten Authentifizierungsmethoden pro Nutzer, bevor Sie irgendetwas ändern. In den meisten Tenants ist das Ergebnis unbequem: ein langer Rattenschwanz an SMS, eine Handvoll Konten ganz ohne zweiten Faktor aufgrund einer historischen Ausnahme, und Dienstkonten, für die niemand einen Verantwortlichen benennen kann. Diese Inventur ist der Migrationsplan; alles Weitere folgt daraus.
2. Entscheiden Sie gerätegebunden oder synchronisiert, bevor Sie jemanden registrieren
Synchronisierte Passkeys liegen in einem Anmeldedaten-Manager und folgen dem Nutzer über seine Geräte hinweg, was Einführung und Wiederherstellung deutlich erleichtert. Gerätegebundene Passkeys — ein Hardware-Sicherheitsschlüssel oder Windows Hello for Business auf einer bestimmten Maschine — geben Ihnen eine stärkere Zusicherung darüber, wo sich der Nachweis physisch befindet. Die meisten Organisationen sollten beides nutzen: Hardware-Schlüssel für Administratoren und alle, die Geld bewegen können, synchronisierte Passkeys für den Rest. Klären Sie das zuerst, denn eine Umkehr bedeutet, alle erneut zu registrieren.
3. Beginnen Sie mit den Konten, die ein Angreifer wirklich will
Globale Administratoren, Finanzen und Zahlungsverkehr, Assistenzkräfte mit delegiertem Postfachzugriff, Personalwesen und alle, die Bankverbindungen in einem Lieferantenstammsatz ändern können. Diese Liste ist kurz genug, um sie in zwei Wochen abzuarbeiten, und deckt die meisten realistischen Schadensszenarien ab.
4. Lösen Sie die unbequemen fünfzehn Prozent zuerst, nicht zuletzt
Gemeinsam genutzte Arbeitsplätze in der Fertigung. Beschäftigte ohne Firmenhandy und mit nachvollziehbaren Einwänden gegen die Nutzung des privaten. Externe Dienstleister. Außendiensttechniker auf Leihgeräten. Jede Migration bleibt hier stecken, und zwar im ungünstigsten Moment: nachdem die Richtlinie erzwungen wurde und die Ausnahmen zu dringenden Tickets werden. Kalkulieren Sie Hardware-Schlüssel für diese Gruppe von Anfang an ein; sie kosten wenig gegenüber einer Woche Dauerfeuer im Service Desk.
5. Reparieren Sie den Service Desk, bevor Sie die Anmeldung reparieren
Wenn die Vordertür nicht mehr aufzubekommen ist, verlagert sich der Angriff auf die Person, die sie zurücksetzen kann. Ein Anruf eines plausibel klingenden Kollegen, der „sein Handy auf dem Weg zum Kunden verloren" hat, ist inzwischen der kürzeste Weg in Ihren Tenant, und er wird genutzt. Halten Sie schriftlich fest, welcher Identitätsnachweis für ein Zurücksetzen verlangt wird, wählen Sie etwas, das ein Außenstehender nicht beschaffen kann — ein Rückruf auf die in der Personalakte hinterlegte Nummer oder eine Bestätigung durch die Führungskraft des Anfragenden — und machen Sie es unverhandelbar, ganz gleich wie ranghoch oder wie gestresst der Anrufer klingt. Ein Service Desk, der das einmal geprobt hat, verhält sich völlig anders als einer, der nur eine Richtlinie gelesen hat; genau dafür gibt es unsere Sicherheitsschulungen.
6. Erzwingen Sie es über Conditional Access, nicht über gutes Zureden
Registrierungskampagnen bringen Ihnen Verbreitung. Sie bringen Ihnen keine Zusicherung, denn ein Nutzer mit Passkey und SMS-Rückfallebene wird das Bequemere verwenden — und wer ihn phisht, ebenfalls. Setzen Sie eine Conditional-Access-Richtlinie ein, die eine phishing-resistente Authentifizierungsstärke verlangt, zunächst auf Ihre Prioritätsgruppe angewandt und mit wachsender Abdeckung ausgeweitet. Solange eine Gruppe nicht vollständig registriert ist, verkürzen Sie für sie die Anmeldehäufigkeit, damit ein gestohlenes Token eine kürzere nutzbare Lebensdauer hat.
7. Schließen Sie die Hintertüren
Veraltete Authentifizierungsprotokolle, App-Kennwörter, nicht verwaltete Dienstprinzipale und die Notfallkonten, die Sie 2019 angelegt und seither nicht angesehen haben. Ein Angreifer findet den einen phishbaren Authentifizierungspfad, den Sie stehen gelassen haben, und es ist meist der, der älter ist als die heutige IT-Mannschaft. Notfallkonten müssen weiterhin existieren — geben Sie ihnen Hardware-Schlüssel, verwahren Sie diese ordentlich und alarmieren Sie bei jeder Nutzung.
Worauf Sie achten sollten, während Sie mittendrin sind
Das Migrationsfenster ist der riskante Teil, denn Sie haben eine gemischte Nutzerschaft und viele legitime Authentifizierungsänderungen, die Rauschen erzeugen. Ein paar Alarme sollten stehen, bevor Sie beginnen: die Registrierung einer neuen Authentifizierungsmethode auf einem Konto, das bereits eine hatte; eine Anmeldung von einem ungewohnten Ort kurz nach erfolgreicher MFA; neue Weiterleitungs- oder Ausblendregeln im Postfach; und OAuth-Zustimmungen für Anwendungen, die niemand freigegeben hat. Diese vier decken das übliche Vorgehen nach einem Token-Diebstahl ab und entscheiden darüber, ob Sie es in einer Stunde bemerken oder erst, wenn die Rechnung ausbleibt. Wenn außerhalb der Bürozeiten niemand auf diese Telemetrie schaut, ist das eine Lücke, die für sich genommen zu schließen ist — sie ist der Kern unserer Arbeit im Security-Betrieb.
Der Compliance-Aspekt, kurz
Für Einrichtungen im Anwendungsbereich des Luxemburger NIS2-Gesetzes nennen die Risikomanagementmaßnahmen in Artikel 21 die Multi-Faktor-Authentifizierung ausdrücklich. Der Text unterscheidet derzeit nicht zwischen phishbaren und phishing-resistenten Verfahren — doch die Erwartungen der Aufsicht folgen der Bedrohungslage, und eine Organisation, die phishing-resistente Authentifizierung für ihre privilegierten Konten nachweisen kann, steht deutlich besser da als eine, die erklären muss, weshalb ein Session-Token-Diebstahl als angemessene Sicherheit gelten sollte. Wenn Sie Ihre Position noch bestimmen, beginnt unsere NIS2-Compliance-Unterstützung mit genau dieser Anwendungsbereichsfrage.
Womit Sie anfangen
Wenn Sie aus diesem Artikel eine einzige Maßnahme mitnehmen: Erstellen Sie die Liste derjenigen in Ihrer Organisation, die noch auf SMS oder eine Push-Bestätigung angewiesen sind, und sehen Sie nach, wie viele dieser Konten eine Zahlung freigeben oder ein Passwort zurücksetzen können. Diese Zahl ist Ihre tatsächliche Exponierung, und sie ist an einem Nachmittag zu ermitteln.
Ist die Liste länger als erwartet, oder sind es genau die unbequemen Fälle, die Sie immer wieder verschieben, gehen wir sie gerne mit Ihnen durch — Inventur, eine realistische Reihenfolge und die zwei bis drei Conditional-Access-Richtlinien, die den Großteil der Arbeit leisten. Sprechen Sie uns an, und wir sagen Ihnen offen, wie groß die Aufgabe ist, bevor Sie sich darauf festlegen.
