Du hast in deinem Unternehmen Hardware TOTP Token ausgerollt, um Usern ohne Smartphone oder mit besonderen Sicherheitsanforderungen eine zuverlässige MFA-Methode zu bieten? Perfekt! Aber dann das: Deine User werden trotzdem ständig zur Installation des Microsoft Authenticators aufgefordert. Beim nächsten Sign-In wieder. Und wieder. Und wieder.
Willkommen in der Welt der Microsoft Entra ID Registration Campaign – einem Feature, das eigentlich hilfreich sein soll, aber bei Hardware Token Usern zu einem echten Praxisproblem wird. In diesem Artikel zeige ich dir, warum das passiert und wie du es mit wenigen Handgriffen lösen kannst.
Was ist die Microsoft Authenticator Registration Campaign?
Die Registration Campaign ist ein „Nudging-Mechanismus“ in Microsoft Entra ID, der User während des normalen Sign-In-Prozesses dazu auffordert, Microsoft Authenticator einzurichten. Das Ganze läuft so ab:
- User meldet sich normal an
- Führt MFA wie gewohnt durch (z.B. mit SMS, Hardware Token, oder einer anderen Methode)
- Nach erfolgreicher MFA erscheint ein Prompt zur Einrichtung von Microsoft Authenticator
- User kann den Einrichtungsprozess durchlaufen oder „Skip for now“ wählen
Die Idee dahinter ist gut: Microsoft möchte die Adoption von Authenticator Push Notifications erhöhen, da diese sicherer und benutzerfreundlicher sind als SMS oder Anrufe. Die Campaign zielt dabei spezifisch auf Push Notifications ab – nicht auf TOTP-Codes im Authenticator.
Konfiguration der Registration Campaign
Als Administrator kannst du die Campaign granular steuern:
- Scoping: Du kannst festlegen, welche User oder Gruppen zur Registrierung aufgefordert werden sollen (Include) und welche ausgenommen werden (Exclude)
- Snooze-Verhalten: Du kannst konfigurieren, wie oft User den Prompt „wegklicken“ können (0-14 Tage pro Snooze, unlimited oder limited snoozes)
- Erzwingung: Nach einer bestimmten Anzahl von Snoozes kann die Registrierung verpflichtend werden
Wichtig zu verstehen: Die Campaign prüft nur eine einzige Bedingung – hat der User Microsoft Authenticator Push Notifications eingerichtet? Wenn nein, wird der Prompt angezeigt. Welche anderen MFA-Methoden der User bereits hat, spielt dabei keine Rolle.
Hardware TOTP Token in Entra ID
Hardware TOTP (Time-based One-Time Password) Token – auch OATH Hardware Token genannt – sind physische Geräte, die alle 30 oder 60 Sekunden einen neuen sechsstelligen Code generieren. In Microsoft Entra ID sind sie eine vollwertige MFA-Methode und stehen in der System-Preferred MFA Hierarchie an Position 5 (TOTP).
Die Hierarchie sieht so aus:
- Temporary Access Pass (TAP)
- Passkey (FIDO2)
- External authentication methods
- Microsoft Authenticator notifications
- Time-based one-time password (TOTP) ← Hardware OATH Token
- Telefon (SMS/Anruf)
- Certificate-based authentication
Typische Einsatzszenarien
Hardware TOTP Token werden in der Regel bewusst eingesetzt für:
- User ohne Smartphone: Mitarbeiter in Produktionsumgebungen, Lager, oder Bereiche mit Smartphone-Verbot
- Hohe Sicherheitsanforderungen: Privilegierte Accounts oder regulierte Industrien
- Datenschutz-Bedenken: User, die keine privaten Geräte für geschäftliche Zwecke nutzen möchten
- Backup-Methode: Als Fallback für Authenticator oder FIDO2
In all diesen Fällen ist die Entscheidung für Hardware-Token eine bewusste organisatorische Wahl – und genau hier entsteht das Problem mit der Registration Campaign.
Das Problem: Warum werden Hardware Token User „belästigt“?
Jetzt kommen wir zum Kern des Problems. Stell dir vor:
- Du hast einem User ein Hardware TOTP Token zugewiesen
- Der User nutzt dieses Token erfolgreich für MFA
- Die Registration Campaign ist für „All users“ aktiviert
Was passiert?
Der User wird bei jedem Sign-In nach der MFA-Eingabe (mit seinem Hardware Token!) zur Installation von Microsoft Authenticator aufgefordert. Er kann „Skip for now“ wählen, aber nach der konfigurierten Snooze-Zeit (z.B. 1 Tag) kommt der Prompt wieder. Und wieder. Und wieder.
Falls du „Limited snoozes“ konfiguriert hast (z.B. maximal 3x snoozen), wird nach dem dritten Snooze die Authenticator-Registrierung verpflichtend – selbst wenn der User ein vollständig funktionales Hardware Token hat!
Warum ignoriert die Campaign das Hardware Token?
Die Antwort liegt in der Funktionsweise der Registration Campaign. Sie prüft ausschließlich, ob der User Microsoft Authenticator Push Notifications eingerichtet hat. Das ist die einzige Bedingung.
Die Campaign fragt nicht:
- Hat der User bereits andere sichere MFA-Methoden wie Hardware TOTP?
- Ist der User bereits mit sicheren Authentifizierungsmethoden ausgestattet?
- Wurde dem User bewusst eine alternative Methode zugewiesen?
In der offiziellen Microsoft Learn FAQ wird das explizit bestätigt:
„Will a user who signs in with a 3rd party authenticator app see the nudge?“
Yes. If a user is enabled for the registration campaign and doesn’t have Microsoft Authenticator set up for push notifications, the user is nudged to set up Authenticator.
Das gleiche gilt für Hardware TOTP Token: Die Campaign sieht sie nicht als Grund, den User vom Authenticator-Prompt zu verschonen.
Warum ist das problematisch?
Auf den ersten Blick könnte man sagen: „Na und? Der User kann doch einfach snoozen.“ Aber in der Praxis entstehen mehrere Probleme:
1. Organisatorischer Konflikt
Wenn du als Organisation bewusst Hardware Token ausrollst – sei es aus Sicherheits-, Datenschutz- oder praktischen Gründen – dann möchtest du, dass diese User das Token nutzen. Die Registration Campaign unterläuft diese Entscheidung, indem sie die User ständig zur Authenticator-Installation drängt.
Das kann zu Verwirrung führen: „Warum soll ich Authenticator installieren, wenn ich doch ein Token bekommen habe?“
2. Schlechte User Experience
User mit Hardware Token haben bereits eine sehr sichere MFA-Methode (Position 5 in der System-Preferred Hierarchie – höher als SMS!). Sie müssen aber:
- Bei jedem MFA-Prompt nach dem Snooze-Intervall den Authenticator-Prompt sehen
- Wiederholt auf „Skip for now“ klicken
- Im schlimmsten Fall (limited snoozes) nach 3x snoozen zur Registrierung gezwungen werden
Das ist nicht nur nervig, sondern untergräbt auch das Vertrauen in die von IT-Abteilung bereitgestellte Lösung.
3. System-Preferred MFA hilft nicht
Man könnte denken: „Aber Hardware TOTP ist doch Teil der System-Preferred MFA – sollte das nicht automatisch funktionieren?“ Leider nein.
System-Preferred MFA bestimmt nur, welche Methode beim MFA-Prompt bevorzugt wird (also während der eigentlichen Authentifizierung). Die Registration Campaign läuft aber nach dem MFA-Prompt als separater Schritt. System-Preferred MFA kann den Authenticator-Registrierungs-Prompt nicht verhindern.
4. Hardware Token wird nach Authenticator-Einrichtung „nutzlos“
Hier wird es besonders problematisch: Angenommen, ein User ist von der ständigen Registration Campaign so genervt, dass er den Microsoft Authenticator doch einrichtet – in der Hoffnung, endlich Ruhe zu haben.
Was passiert dann?
Durch die System-Preferred MFA Hierarchie wird der User ab diesem Zeitpunkt immer zur Authentifizierung mit dem Authenticator aufgefordert. Denn Microsoft Authenticator Push Notifications stehen auf Position 4 in der Hierarchie, während TOTP auf Position 5 steht. Das System bevorzugt automatisch die höher priorisierte Methode.
Das Ergebnis:
- Der User wird nun standardmäßig zur Authenticator-Push-Notification aufgefordert
- Das Hardware Token liegt nutzlos herum
- Der User fragt sich: „Warum habe ich überhaupt ein Token bekommen, wenn ich es nie nutzen kann?“
- Die organisatorische Entscheidung für Hardware Token wurde komplett untergraben
Besonders ärgerlich: Viele User, die Hardware Token erhalten haben, können den Authenticator aus gutem Grund nicht nutzen (kein Smartphone, Datenschutzbedenken, Sicherheitsrichtlinien). Sie werden praktisch gezwungen, eine Methode einzurichten, die sie nicht verwenden können oder sollen – nur um die Campaign-Prompts loszuwerden.
Selbst wenn der User das Hardware Token weiterhin nutzen möchte, muss er bei jedem MFA-Prompt aktiv auf „Use another method“ klicken und dann das Token auswählen. Das ist genau das Gegenteil dessen, was du als Administrator mit der Hardware Token-Bereitstellung erreichen wolltest.
Die Lösung: Hardware Token User ausschließen
Die gute Nachricht: Die Lösung ist einfach und elegant. Du musst lediglich deine Hardware Token User von der Registration Campaign ausschließen. Microsoft bietet dafür group-based exclusions an, die genau für solche Szenarien gedacht sind.
Schritt 1: Security Group für Hardware Token User
Erstelle eine Security Group (z.B. „MFA-HardwareTokenUsers“ oder „Exclude-AuthenticatorCampaign“) und füge alle User hinzu, die Hardware TOTP Token nutzen.
Wichtiger Hinweis: Dynamische Gruppen basierend auf „hat Hardware OATH Token“ sind leider nicht möglich, da es keine entsprechenden User-Attribute gibt, die in Dynamic Group Queries verwendet werden können. Du musst die Gruppe also manuell pflegen.
Alternative: Falls du viele Hardware Token User hast, kannst du ein Azure Functions Script schreiben, das über die Graph API prüft, welche User Hardware OATH Token haben, und die Gruppenmitgliedschaft automatisch aktualisiert. Das ist allerdings optional – für die meisten Umgebungen reicht die manuelle Pflege aus.
Schritt 2: Gruppe von Registration Campaign ausschließen
Jetzt schließt du die Gruppe von der Registration Campaign aus.
Via Entra Admin Center
- Melde dich als Authentication Policy Administrator (oder höher) im Entra Admin Center an
- Navigiere zu Entra ID → Authentication methods → Registration campaign
- Bei „Excluded users and groups“ klicke auf „Add users and groups“
- Füge deine Hardware Token Gruppe hinzu
- Klicke auf Save
Wichtig: Wenn ein User sowohl in einer Include- als auch in einer Exclude-Gruppe ist, hat Exclude Vorrang. Der User wird nicht zur Registrierung aufgefordert.
Schritt 3: Verifizierung
Um zu testen, ob der Ausschluss funktioniert:
- Melde dich als Test-User an, der in der ausgeschlossenen Gruppe ist
- Führe MFA mit dem Hardware Token durch
- Nach erfolgreicher MFA sollte kein Authenticator-Registrierungs-Prompt erscheinen
Falls der Prompt weiterhin erscheint, überprüfe:
- Ist der User tatsächlich Mitglied der Exclude-Gruppe?
- Wurde die Policy gespeichert/aktualisiert?
- Warte ggf. einige Minuten für die Replikation der Policy-Änderung
Alternative Ansätze
Neben der group-based exclusion gibt es noch einige alternative Ansätze, je nachdem wie deine Umgebung aussieht:
Granulares Include statt Exclude
Statt „All users“ mit Exclusions kannst du die Campaign nur auf spezifische Gruppen anwenden:
- Gruppe: „MFA-SMS-Users“ (User, die nur SMS/Voice haben)
- Gruppe: „MFA-ThirdPartyOTP-Users“ (User mit Third-Party Authenticator Apps)
Vorteil: Mehr Kontrolle, keine User werden versehentlich geprompted
Nachteil: Mehr administrativer Aufwand, neue User müssen aktiv zugewiesen werden
Unlimited Snoozes aktivieren
Wenn du die Campaign generell beibehalten möchtest, aber User nicht zwingen willst:
- Setze „Limited number of snoozes“ auf Disabled
- User können unbegrenzt snoozen und die Registrierung vermeiden
Vorteil: Flexibler für alle User
Nachteil: User sehen weiterhin den Prompt (schlechte UX für Hardware Token User)
ging für User, die tatsächlich von Authenticator profitieren würden (z.B. SMS-User)
Best Practices
Basierend auf den Erkenntnissen aus der Praxis hier einige Empfehlungen:
- Proaktiv ausschließen: Schließe Hardware Token User vor der Aktivierung der Registration Campaign aus, nicht erst nachdem User sich beschweren.
- Gruppenpflege etablieren: Etabliere einen Prozess zur Pflege der Exclusion-Gruppe. Wenn ein neuer User ein Hardware Token erhält, sollte er automatisch (oder zeitnah) zur Gruppe hinzugefügt werden.
- Kommunikation: Informiere deine User über die Gründe für Hardware Token vs. Authenticator. Transparenz erhöht die Akzeptanz.
- Monitoring: Nutze die Authentication Methods Activity Reports in Entra ID, um die tatsächliche Nutzung zu überwachen. So siehst du, ob deine Strategie aufgeht.
- Policy-Alignment: Stelle sicher, dass deine Authentication Methods Policy Hardware OATH für die entsprechenden Gruppen aktiviert hat und die Token ordnungsgemäß registriert sind.
- Backup-Methoden: Auch wenn Hardware Token die primäre Methode ist, sollten User idealerweise eine Backup-Methode registriert haben (z.B. Telefonnummer für SMS als Notfall-Fallback).
Fazit
Die Microsoft Entra ID Registration Campaign ist ein nützliches Feature, um die Adoption von Microsoft Authenticator Push Notifications zu fördern. Allerdings berücksichtigt sie nicht, ob User bereits andere sichere MFA-Methoden wie Hardware TOTP Token nutzen.
Das führt zu einem Praxisproblem: User mit Hardware Token werden ständig zur Authenticator-Installation aufgefordert, obwohl sie bereits eine sichere und bewusst gewählte MFA-Methode haben. Oft auch aus dem Grund, dass sie den Authenticator gar nicht nutzen können. Das sorgt für Verwirrung, schlechte User Experience und untergräbt organisatorische Entscheidungen.
Die Lösung ist einfach: Group-based exclusion. Erstelle eine Security Group für deine Hardware Token User und schließe diese von der Registration Campaign aus. Das verhindert den Prompt und ermöglicht deinen Usern, die bereitgestellte Hardware-Lösung ohne Ablenkung zu nutzen.
Ausblick: Ab März 2026 wird die Registration Campaign für Tenants mit aktivierten Synced Passkeys auf Passkeys statt nur Microsoft Authenticator abzielen. Das könnte das Verhalten leicht ändern, aber die grundsätzliche Empfehlung zur group-based exclusion für Hardware Token User bleibt bestehen.
Meine Empfehlung: Nutze die group-based exclusion proaktiv als Standard-Konfiguration für alle Hardware Token Deployments. Deine User werden es dir danken!
Referenzen und weiterführende Informationen
Alle Informationen in diesem Artikel basieren auf der offiziellen Microsoft Learn Dokumentation. Hier findest du die wichtigsten Quellen:
- How to run a registration campaign to set up Microsoft Authenticator
- OATH tokens authentication method
- How to manage OATH tokens in Microsoft Entra ID (Preview)
- System-preferred multifactor authentication (MFA)
- Manage authentication methods for Microsoft Entra multifactor authentication
- How to migrate to the Authentication methods policy
