In vielen Tenants, die ich mir anschaue, taucht bei neuen Usern oder gesperrten Konten immer dasselbe Problem auf. Mitarbeitende sollen ihre ersten Authentifizierungsmethoden einrichten, haben aber kein initiales Passwort oder kommen an ihre bisherigen Methoden nicht mehr heran. Mit temporären Passwörtern behilft man sich zwar, doch das ist lästig und obendrein ein Sicherheitsrisiko. Genau dafür gibt es den Temporary Access Pass (TAP). Viele Organisationen kommen ohne diese Funktion in Microsoft Entra ID kaum noch aus, wenn sie kennwortlose Verfahren wie Microsoft Authenticator, FIDO2-Schlüssel oder Windows Hello for Business sauber einführen wollen.

Der TAP ist ein befristeter Code für die Registrierung neuer Methoden

Administratoren oder der Helpdesk stellen den TAP als zeitlich begrenzten Code aus. Je nach Einstellung lässt er sich einmal oder mehrmals verwenden, um sich bei Microsoft 365 anzumelden und dabei neue Authentifizierungsmethoden zu registrieren. Beim Onboarding tritt er an die Stelle des initialen Passworts. Außerdem hilft er, wenn ein User sämtliche Authentifizierungsmethoden verloren hat, etwa weil das Handy weg ist, oder in einem anderen Supportfall. MFA ersetzt der TAP allerdings nicht. Er ist lediglich das Werkzeug, mit dem man MFA-Methoden einrichtet oder zurücksetzt. Eine kompakte Übersicht der Einsatzmöglichkeiten findet ihr in der offiziellen Dokumentation von Microsoft.

Nur ausgewählte Rollen stellen TAPs aus, und eine Richtlinie begrenzt ihre Laufzeit

In der Regel vergeben Rollen wie Authentication Administrator oder Privileged Authentication Administrator einen TAP. In der Praxis erlebe ich jedoch häufig, dass Helpdesks deutlich mehr Rechte haben als nötig. Für Social-Engineering-Angriffe ist das eine Einladung. Rollen und Prozesse müssen daher klar getrennt sein, und TAPs sollten nur dedizierte, eng überwachte Helpdesk-Gruppen erstellen dürfen. Gültigkeitsdauer und Verwendbarkeit (einmalig oder mehrfach) konfiguriert man zentral in der Authentifizierungsmethodenrichtlinie, wie in dieser Übersicht beschrieben. Dort könnt ihr z. B. festlegen, dass ein TAP höchstens acht Stunden gilt (Standard: eine Stunde) und nach der ersten Anmeldung verfällt. Alternativ darf er für einen begrenzten Zeitraum mehrfach genutzt werden.

Praxistipp: Für Einmalzugänge empfiehlt sich eine kurze Lebensdauer (z. B. 30–60 Minuten). Einen längeren Zeitraum würde ich nur für Ausnahmen vorsehen, etwa beim internationalen Rollout oder für Mitarbeitende mit ungewöhnlichen Arbeitszeiten.

In vielen Unternehmen lohnt es sich, für unterschiedliche Szenarien eigene TAP-Profile anzulegen, zum Beispiel für Onboarding und Recovery. Verwalten und auswerten lässt sich das bequem im Entra Admin Center. Wer automatisieren möchte, kommt mit einem kurzen PowerShell-Befehl aus:

# Beispiel: Einmal-TAP für 30 Minuten
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId [email protected] -IsUsableOnce $true -LifetimeInMinutes 30

Mit Autopilot richten neue Mitarbeitende ihr Gerät per TAP selbst ein

Bei neuen Endgeräten spart der TAP besonders viel Arbeit. Über Windows Autopilot melden sich User direkt mit dem TAP an und registrieren danach auf dem neuen Gerät ihre passwortlosen Methoden wie FIDO2 oder Windows Hello for Business. Der Helpdesk hat dadurch weniger zu tun, und der Start verläuft ohne Reibung, gerade wenn überwiegend remote oder hybrid gearbeitet wird. Nach meiner Erfahrung gehört das Gespann aus TAP und Autopilot mittlerweile fast schon zum Standard eines modernen Onboardings. Achtet dabei darauf, dass das TAP-Zeitfenster für die komplette Einrichtung reicht, aber nicht so lang ist, dass es zum Missbrauch einlädt.

Conditional Access behandelt den TAP als starke Authentifizierung

Wie sich der TAP mit bestehenden Conditional-Access-Richtlinien verträgt, wird oft unterschätzt. Weil er als starke Authentifizierung zählt, erfüllt er viele CA-Richtlinien. Bei vertraulichen Anwendungen will man das aber nicht unbedingt. Für besonders kritische Anwendungen solltet ihr den TAP deshalb gezielt ausschließen oder für den TAP-Registrierungsprozess eigene Richtlinien anlegen. Dabei helfen die Conditional-Access-Berichte und eine regelmäßige Überprüfung der Richtlinien, die ich im Beitrag „Conditional Access: Best Practices“ näher beschrieben habe.

Die Identitätsprüfung am Helpdesk entscheidet über die Sicherheit

So praktisch der TAP auch ist, die eigentliche Schwachstelle bleibt die Identitätsprüfung am Helpdesk. Mir begegnen immer wieder Fälle, in denen ein einfacher Anruf oder eine E-Mail genügt, um einen TAP zu bekommen – für Social Engineering ideale Bedingungen. Unternehmen brauchen an dieser Stelle belastbare und nachvollziehbare Abläufe. Infrage kommen Rückrufnummern, Videocalls, ein zweites Kenntnismerkmal oder die Bestätigung durch Vorgesetzte. Die Technik schützt eben nur so gut, wie die Organisation dahinter mitspielt. Außerdem rate ich, die Ausstellung von TAPs eng zu überwachen und regelmäßig zu auditieren.

flowchart TD
  user["Mitarbeiter"] --> helpdesk["Helpdesk/Admin"]
  helpdesk --> tap["TAP generieren"]
  tap --> login["Login mit TAP"]
  login --> regauth["Neue Auth-Methode registrieren"]
  regauth --> fertig["Zugriff auf Dienste"]

Abbildung: Ablauf einer Registrierung oder Wiederherstellung mit dem TAP

Der TAP gehört als fester Baustein in den Identity-Lifecycle

Der Temporary Access Pass wird oft unterschätzt, bringt das Identity Management im Alltag aber spürbar voran. In einer Arbeitswelt, die immer häufiger ohne Passwörter auskommt und zunehmend mobil und dezentral organisiert ist, ermöglicht er einen sicheren und unkomplizierten Einstieg oder Wiederzugang. Ich empfehle, den TAP fest im Lifecycle zu verankern, aber immer mit klaren Prozessen und restriktiven Berechtigungen. Wer ihn richtig aufsetzt, schafft die Voraussetzung für MFA, FIDO2 und weitere Methoden und spart sich viele Supporttickets und unsichere Notlösungen. Weitere Tipps zur Umstellung der Authentifizierungsmethoden findet ihr im Artikel „Authentifizierungsmethodenrichtlinie in Entra ID migrieren“.