CONSULTING BRIEFING

16.06.2026 · boddenberg.de · Security & Compliance

Entra Passkey Registration Campaign

Executive Summary

Microsoft tritt bei der phishing-resistenten Anmeldung aufs Gaspedal, und das Werkzeug dafür heißt Registration Campaign. Vergiss den netten Newsletter, den ohnehin niemand liest: Die Kampagne ist ein Interrupt mitten im Login. Der Nutzer meldet sich an, macht brav seine MFA – und bekommt direkt danach einen Anstupser: „Richte jetzt einen Passkey ein." Neu ist, dass Passkeys (FIDO2) überhaupt ein Ziel dieser Kampagne sein können und nicht mehr nur die Authenticator-App.

Die Pointe der Geschichte: Microsoft hat den vollautomatischen Umschalt-Plan im Zustand „Enabled" am 15. April 2026 kurz vor Toresschluss zurückgezogen – zu viel Reibung in den Randfällen. Produktiv kommt der Passkey-Push deshalb zunächst nur über den Zustand „Microsoft managed", gestaffelt ab Mai 2026. Wer Zero Trust ernst meint, sollte das Fenster nutzen – aber mit Plan. Sonst tauschst du eine Phishing-Lücke gegen eine Lawine aus Helpdesk-Tickets.

Abbildung 1: Vom Plan zur Vollbremsung – der Passkey-Push kommt zeitversetzt und vorerst nur „managed".

Worum geht es im Detail?

Eine Registration Campaign ist ein tenant-weiter Mechanismus in Entra ID, der Nutzer während der Anmeldung zu einer stärkeren Authentifizierungsmethode schubst. Der Ablauf ist bewusst aufdringlich: reguläre Anmeldung, MFA wie gewohnt, und genau dann – solange der Nutzer ohnehin am Login klebt – erscheint der Hinweis, die Zielmethode einzurichten. Wichtig: Conditional-Access-Richtlinien für die Registrierung von Sicherheitsinfos greifen zuerst. Wer per CA nur im internen Netz Sicherheitsinfos ändern darf, sieht den Anstupser auch nur dort.

Abbildung 2: Der Nudge sitzt direkt hinter der MFA – maximale Aufmerksamkeit, minimaler Aufwand.

Die Kampagne kennt zwei Zielmethoden: Microsoft Authenticator (Push) oder Passkey (FIDO2), wobei Passkey sowohl synchronisierte als auch gerätegebundene Schlüssel umfasst. Du kannst pro Tenant aber immer nur eine Methode gleichzeitig bewerben – Authenticator und Passkey parallel laufen lassen geht nicht. Drei Zustände stehen zur Wahl: „Disabled" (Ruhe), „Enabled" (du konfigurierst Zielmethode, Snooze-Dauer, Snooze-Limit und Zielgruppen selbst) und „Microsoft managed" (Microsoft setzt die Defaults, du darfst nur noch Include/Exclude anfassen).

Genau hier liegt der Knackpunkt. Der plötzliche Auto-Wechsel auf Passkey im Zustand „Enabled" wurde gestoppt, weil die Eignungslogik in den Randfällen zickte – vor allem bei Tenants mit AAGUID-Beschränkungen und gemischten Passkey-Profilen. Microsoft verfeinert die Logik weiter und schaltet den Passkey-Push zunächst nur über „Microsoft managed" frei, und das auch nur für Tenants, die saubere Voraussetzungen erfüllen. Übersetzt: Wenn du den Passkey-Anstupser im Zustand „Enabled" willst, musst du ihn selbst konfigurieren – der Automat nimmt dir die Arbeit dort vorerst nicht ab.

Abbildung 3: Zwei Zustände, zwei Philosophien – Kontrolle gegen Bequemlichkeit.

Technisch läuft alles über die Authentication-Methods-Policy. Im Entra Admin Center findest du das unter Authentifizierungsmethoden, Registrierungskampagne. Wer es per Skript mag, patcht die Policy über Microsoft Graph: ein PATCH auf /policies/authenticationmethodspolicy mit dem Abschnitt registrationEnforcement. Die relevanten Stellschrauben heißen snoozeDurationInDays (0 bis 14), enforceRegistrationAfterAllowedSnoozes (true erzwingt die Einrichtung nach drei Snoozes) und je Zielgruppe targetedAuthenticationMethod mit dem Wert microsoftAuthenticator oder fido2. Dafür brauchst du die Berechtigung Policy.ReadWrite.AuthenticationMethod und mindestens die Rolle Authentication Policy Administrator.

Kurzer Hintergrund, weil ihn erfahrungsgemäß die Hälfte der Runde im Meeting nicht parat hat: Ein Passkey ist im Kern ein FIDO2-/WebAuthn-Schlüsselpaar. Der private Schlüssel verlässt nie das Gerät oder den Authenticator, der öffentliche liegt bei Entra ID. Bei der Anmeldung schickt der Dienst eine kryptografische Challenge, die das Gerät signiert – und zwar fest gebunden an die echte Domäne. Genau deshalb läuft Phishing ins Leere: Eine nachgebaute Login-Seite bekommt schlicht keine gültige Signatur, weil die Domäne nicht passt. „Synced" bedeutet, der Schlüssel wandert verschlüsselt über einen Anbieter wie Google Password Manager oder iCloud-Schlüsselbund mit; „device-bound" heißt, er bleibt auf genau diesem Gerät oder Sicherheitsschlüssel. Beides ist phishing-resistent, aber für Compliance und Wiederherstellung ein himmelweiter Unterschied.

Eine Eigenheit, die im Betrieb gern für Verwirrung sorgt: Der Passkey-Nudge wird pro Gerät-Browser-Kombination bewertet, nicht pro Nutzerkonto. Hat jemand auf Windows mit Chrome bereits einen lokalen Passkey – etwa über Windows Hello for Business – bekommt er dort keinen Anstupser. Setzt sich derselbe Mensch an einen Mac mit Chrome, sieht er den Nudge trotzdem, weil das Credential dort nicht greift. Auf Mobilgeräten läuft die Kampagne gar nicht, und Linux-Nutzer werden ebenfalls nicht angestupst, weil dort schlicht keine FIDO2-Passkeys verfügbar sind.

Was sind Chancen? Was sind Risiken?

Die Chancen liegen auf der Hand und sind ungewöhnlich greifbar. Passkeys sind echt phishing-resistent: kein abtippbarer Code, kein Push, den ein müdes Hirn um 17 Uhr reflexhaft bestätigt, nichts, was sich über eine gefälschte Login-Seite abgreifen lässt. Die Kampagne trifft den Nutzer im richtigen Moment – er will sich ja gerade anmelden – und die Erfolgsquote ist dramatisch höher als bei jeder E-Mail-Bitte. Lizenzkosten? Keine. Der Mechanismus braucht nur aktivierte Entra MFA, kein Premium-Paket. Für eine ernstgemeinte Zero-Trust-Strategie ist das eine der günstigsten Maßnahmen mit großem Hebel.

Ein Beispiel aus der Praxis, das jeder kennt, der schon mal eine MFA-Umstellung begleitet hat: Bei einem Mittelständler mit rund 600 Konten lief jahrelang SMS-MFA, „weil es ja funktioniert". Dann kam der klassische Help-Desk-Anruf – ein Mitarbeiter hatte brav seinen Bestätigungscode auf einer täuschend echten Seite eingetippt, die Angreifer waren im Postfach, und zwei Tage später flatterten Rechnungen mit geänderter Bankverbindung an die halbe Kundschaft. Eine Registration Campaign hätte denselben Mitarbeiter Wochen vorher beim Login angestupst, einen Passkey einzurichten – und genau die abgetippte Code-Nummer, die hier zum Verhängnis wurde, gäbe es dann gar nicht mehr. Das ist der eigentliche Charme: Die Kampagne arbeitet präventiv, im Moment der größten Aufmerksamkeit, statt hinterher beim Aufräumen.

Die Risiken sind allerdings real und teils hausgemacht. Erstens die UX-Falle: Im Zustand „Microsoft managed" sind unbegrenzte Snoozes aktiv. Der Nutzer kann den Passkey also bis zum Sankt-Nimmerleins-Tag wegklicken – du bekommst die Reibung, aber nicht zwingend die Sicherheit. Wer Verbindlichkeit will, muss in den Zustand „Enabled" wechseln und das Snooze-Limit auf drei setzen. Zweitens die Randfälle: Bei AAGUID-Beschränkungen, erzwungener Attestierung oder reinen Synced-only- beziehungsweise Device-bound-only-Profilen greift der Nudge unter „Microsoft managed" gar nicht erst – genau diese Reibung war ja der Grund für die Vollbremsung im April.

Drittens die Geräte-Realität: Weil pro Gerät-Browser-Kombination bewertet wird, kann ein Nutzer sich vollkommen sicher fühlen („hab ich doch eingerichtet") und am Zweitgerät trotzdem genervt werden. Das ist technisch korrekt, fühlt sich für den Anwender aber nach Schikane an – und Schikane erzeugt Tickets. Viertens: Mobil und Linux fallen raus, und wer viele Mac- oder Mischflotten betreibt, sollte die Logik der Nudge-Unterdrückung kennen, bevor die ersten „warum schon wieder"-Mails eintrudeln.

Was müssen wir jetzt schon vorbereiten?

Der erste Schritt ist banal, wird aber gern vergessen: Die Passkey-Methode (FIDO2) muss in der Authentication-Methods-Policy überhaupt aktiviert sein, und der Schalter „Allow self-service setup" muss an sein. Ohne diese beiden Haken läuft keine Passkey-Kampagne, egal wie schön der Rest konfiguriert ist. Für eine Authenticator-Kampagne wiederum muss der Authentifizierungsmodus auf „Any" oder „Push" stehen – im Modus „Passwordless" sind die Nutzer für den Nudge nicht berechtigt.

Zweitens: Triff bewusst die Grundsatzentscheidung „Enabled" gegen „Microsoft managed". Willst du Kontrolle über Zielmethode, Snooze-Verhalten und Verbindlichkeit, dann ist „Enabled" dein Zustand – hier konfigurierst du Passkey explizit und setzt das Snooze-Limit. Vertraust du den Microsoft-Defaults und willst den Auto-Piloten, nimm „Microsoft managed" – aber wisse, dass unbegrenzte Snoozes und die Ein-Tages-Dauer dann nicht verhandelbar sind und der Push erst greift, wenn dein Tenant die Voraussetzungen erfüllt (FIDO2 aktiv, Self-Service erlaubt, keine AAGUID-Beschränkung).

Drittens: Bau dir einen Rettungsweg, bevor du Druck machst. Richte einen TAP-Prozess ein, damit Nutzer ohne starke Methode überhaupt sauber an ihren ersten Passkey kommen. Schließe Break-Glass-Konten, Service-Identitäten und sensible Sonderfälle über Exclude-Targets aus. Und überlege parallel, ob du die Verbindlichkeit nicht ohnehin besser über Conditional Access mit Authentication Strengths erzwingst – der Nudge motiviert, aber die Authentifizierungsstärke ist der Hebel, der wirklich „phishing-resistent oder kein Zugriff" durchsetzt.

Viertens: Change-Kommunikation. Erkläre den Leuten vorab, was ein Passkey ist, warum er sicherer ist als das alte SMS-Spielchen und dass der Anstupser kein Fehler, sondern Absicht ist. Wer den Unterschied zwischen „Skip for now" und „jetzt einrichten" versteht, klickt nicht panisch herum und ruft nicht beim Support an. Ein kurzer Intranet-Artikel mit Screenshots und ein, zwei Sätzen zur Begründung erspart dir hundert Tickets mit dem Betreff „Mein Login fragt mich auf einmal nach irgendwas Komischem".

Und fünftens, der Teil, den alle überspringen wollen: Monitoring und Rückwärtsgang. Lege vor dem Start fest, woran du Erfolg misst – etwa den Anteil der Konten mit registriertem Passkey im Authentication-Methods-Activity-Report – und definiere eine klare Abbruchkante. Eine Kampagne ist kein Einbahnstraßen-Projekt: Du kannst den Zustand jederzeit über das Admin Center oder die Graph-API auf „Disabled" zurückdrehen, wenn die Tickets explodieren. Wer diesen Notausgang vorher dokumentiert hat, diskutiert im Ernstfall nicht hektisch über das Wie, sondern drückt einfach den Knopf – und das ist im Sicherheitsbetrieb mehr wert als jede schöne Präsentation.

Häufig gestellte Fragen

Brauche ich eine Entra-ID-P1- oder P2-Lizenz für die Registration Campaign?

Nein. Für die Registrierungskampagne gibt es keine Lizenzanforderung – du musst lediglich Microsoft Entra MFA aktiviert haben. Premium-Funktionen wie Conditional Access mit Authentication Strengths setzen allerdings eine entsprechende Lizenz voraus, wenn du den Nudge zusätzlich verbindlich absichern willst.

Was passiert, wenn ein Nutzer den Passkey dauerhaft mit „Skip for now" wegklickt?

Im Zustand „Microsoft managed" sind Snoozes unbegrenzt, der Nutzer kann also theoretisch ewig aufschieben. Willst du die Einrichtung erzwingen, wechselst du in den Zustand „Enabled" und aktivierst das Snooze-Limit – nach drei Aufschüben ist die Registrierung dann Pflicht.

Warum sieht ein Nutzer den Nudge auf einem Gerät, auf einem anderen aber nicht?

Weil der Passkey-Nudge pro Gerät-Browser-Kombination bewertet wird, nicht pro Konto. Existiert auf der aktuellen Kombination bereits ein lokaler Passkey – etwa Windows Hello for Business auf Windows mit Chrome – bleibt der Anstupser aus; auf einer anderen Plattform ohne passenden Schlüssel erscheint er erneut.

Kann ich Authenticator und Passkey gleichzeitig bewerben?

Nein. Eine Registrierungskampagne kann pro Tenant immer nur eine Zielmethode ansprechen, entweder Authenticator oder Passkey. Wenn du beide ausrollen willst, planst du das nacheinander oder kombinierst die Kampagne mit Conditional Access für die Verbindlichkeit.

Funktioniert der Nudge auch für Gäste und auf Mobilgeräten?

Gast- und B2B-Nutzer werden angestupst, sofern sie in der Kampagne enthalten sind. Auf Mobilgeräten läuft die Registrierungskampagne dagegen nicht, und Linux-Nutzer sehen den Passkey-Nudge ebenfalls nicht, weil dort keine FIDO2-Passkeys verfügbar sind.