When a Temporary Access Pass becomes permanent attacker MFA

A Temporary Access Pass is a legitimate, time-limited credential that lets a user bootstrap their own sign-in methods. The trouble starts when whoever can issue one points it at someone else.

How the attack works

An operator holding the Authentication Administrator role issues a TAP for a target user, outside any helpdesk ticket. They sign in with that pass from an unfamiliar location, and inside the bootstrapped session they register their OWN authenticator app and passkey on the victim account. From that point the attacker satisfies MFA independently of the user. A later password reset by the victim changes nothing, because the attacker never relied on the password. In ATT&CK terms this is T1098, Account Manipulation, paired with T1556, Modify Authentication Process.

Why it works

A TAP is designed to register security info, so using it to add new MFA methods looks like normal onboarding. The abuse is enabled by who can issue passes and by a TAP policy that allows long-lived, reusable passes. The durable credential the attacker plants lives in the identity plane, decoupled from the password entirely.

How to fix it

Containment is not a password reset. Delete the attacker-registered authenticator and passkey, revoke the user’s refresh tokens and sessions so issued tokens die, and clear any active TAP so it cannot bootstrap again. For the root cause, scope TAP issuance to a small enrolled group, set the policy to one-time and short-lived, and gate the issuing roles behind just-in-time activation with approval. The Entra audit and sign-in logs name the issuing admin and every rogue registration.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse the TAP-then-registration sequence and the cleanup that actually dislodges the attacker.