Temporary Access Pass is a loaded gun: using it without shooting yourself

A Temporary Access Pass is a time-limited passcode an admin issues so a user can sign in and register other authentication methods — onboard a new hire, recover a locked-out account, bootstrap passwordless. Useful. But the framing most people carry ("it skips MFA") is wrong in a way that hides the actual danger. Let's fix the model first, because the mitigations only make sense once you see what you're really defending against.

01It's not an MFA bypass — it's worse

A TAP satisfies MFA as a strong credential. That's the problem, not the reassurance.

A TAP doesn't skip multi-factor auth — it satisfies it, counting as a strong credential in its own right. That sounds reassuring until you follow the consequence: because it's strong enough to authenticate, it's strong enough to register new authentication methods. A TAP is a credential whose entire purpose is to mint other credentials.

Why "bootstrap" is the scary word

Whoever holds a valid TAP for an account can sign in and enroll a passkey, register Authenticator, or set up Windows Hello — their own. That's not one session of access; it's persistent access that survives the TAP's expiry, because the attacker now owns a permanent method on the account. A stolen password gets you in until it's reset. A stolen TAP gets you in, lets you plant your own key, and then you don't need the TAP anymore.

This is not theoretical. Documented tradecraft includes creating a TAP from a compromised admin account to seize a target, and the service-desk social-engineering playbook that groups like Scattered Spider have run repeatedly — talk the help desk into issuing a credential, then register an attacker-controlled MFA device for persistence. TAP is a first-class tool for exactly that pattern.

02The four risks, concretely

Name them so the controls have something to bite on.

Risk	What it looks like
Persistence bootstrap	A leaked/stolen TAP is used to register the attacker's own passkey or Authenticator — access outlives the TAP
Help-desk social engineering	An attacker calls posing as a locked-out user; the agent issues a TAP over the phone; game over
Privileged-account onboarding	A TAP issued for an admin (or an account eligible for admin roles) hands over the crown jewels
Over-long / reusable passes	A multi-use, multi-day TAP is a durable shared secret — everything wrong with a temporary password, dressed up as modern

03Lock the policy down to the floor

The defaults are generous. The allowed range is alarming. Configure deliberately.

The TAP policy (Entra ID → Authentication methods → Policies → Temporary Access Pass) sets tenant-wide lifetime, one-time-use, and length. Here are Microsoft's defaults and — importantly — how far the range actually stretches:

Setting	Default	Allowed range	What to set
Minimum lifetime	1 hour	10 min – 30 days	Keep low
Maximum lifetime	8 hours	10 min – 30 days	Cap at ~1 hour (8h max, not 30d)
Default lifetime	1 hour	10 min – 30 days	1 hour
One-time use	False	True / False	True — enforce single-use
Length	8	8 – 48 characters	Leave at 8+ (longer for higher assurance)

The 30-day maximum is a trap, and one-time-use defaults to OFF

That the maximum lifetime can be set to 30 days tells you the guardrails are yours to build — a month-long, reusable passcode is a standing backdoor. Worse, one-time use defaults to False, meaning out of the box a TAP can be used repeatedly for its whole validity window. Set one-time use to True and cap the maximum lifetime to hours, not days. If you never lower these, you've left the barn door open by default.

# create a strictly-scoped, single-use TAP (Graph PowerShell)
$props = @{ isUsableOnce = $true; lifetimeInMinutes = 60 } | ConvertTo-Json
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId newhire@contoso.com -BodyParameter $props

# audit: does this user currently have a TAP registered?
Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId someone@contoso.com

04Scope it — and keep it away from admins

Enabling TAP tenant-wide for everyone is the mistake.

The policy lets you include and exclude specific groups. Use that hard. TAP should be enabled only for the populations that genuinely need it — a controlled onboarding group, a trained recovery workflow — not switched on for the whole tenant by default.

Exclude privileged accounts from the TAP policy entirely

The single highest-value control here: exclude your admin / privileged-role-eligible accounts from TAP scope. A TAP that can onboard a fresh credential onto a Global Administrator is the worst-case bootstrap. If a privileged user genuinely needs recovery, handle it as a deliberate, heavily-verified exception — not a standing capability. Note also who can issue: only Privileged Authentication Administrators can create a TAP for admins; ordinary Authentication Administrators can't. Keep that boundary, and keep the privileged-issuer role tightly held.

05Fence it with Conditional Access authentication strengths

Let TAP in for bootstrap — and nowhere else.

Policy scoping controls who can hold a TAP; Conditional Access authentication strengths control what a TAP is allowed to do. The pattern that contains it:

# two custom authentication strengths
Bootstrap/Recovery strength   → INCLUDES Temporary Access Pass
                                (scope: onboarding/recovery flows, registration)
Normal sign-in strength       → EXCLUDES TAP; requires phishing-resistant
                                (passkey / WHfB) for day-to-day access to resources

With this split, a TAP works for the narrow job of getting a user to the point where they can register a real, phish-resistant method — and is rejected everywhere else. It can't be used to walk into sensitive apps or admin portals. Roll the strengths out in report-only first so you see what a TAP would and wouldn't satisfy before you enforce.

06The session outlives the pass — close that gap

A subtle one that surprises people: TAP expiry doesn't kill an existing session.

You'd assume that when the TAP expires, access ends. It doesn't, entirely. Tokens issued during a TAP sign-in are capped at the TAP's expiration at the moment of issuance — but TAP expiry does not retroactively invalidate a session that's already established. Session lifetime is governed by Conditional Access, so a user (or attacker) who signed in with a TAP can retain access longer than the TAP's lifetime depending on your CA session config.

Pair TAP with a tight sign-in frequency

To stop a TAP-established session from lingering, apply a short sign-in frequency to the flows where TAP is allowed, so the session is forced to re-authenticate (and can't ride on the expired pass). This is the same reason CAE matters for revocation — a credential going away doesn't automatically end the sessions it created. Don't assume "the TAP expired" means "the access is gone."

07Issue and monitor like it's a privileged action

The process around the TAP matters as much as the policy.

Even perfectly configured, a TAP is only as safe as the process that hands it out. The operational controls:

Control	Why
Verify identity out-of-band before issuing	Kills the help-desk phone-call attack — never issue on a caller's say-so alone
Deliver over a secure channel	Never email/SMS a TAP in clear; use a secure ticketing / one-time-secret tool
Alert on every TAP creation	A TAP registered on a privileged (or unusual) account is a high-signal event — watch for it
Alert on TAP → new-method registration	A TAP sign-in immediately followed by a passkey/Authenticator enrolment is the persistence pattern
Expire and delete promptly	Don't leave used or stale TAPs lying on accounts

Treat "a TAP was issued" and "a new auth method was registered right after a TAP sign-in" as detections, not just log lines — that sequence is precisely what an attacker's persistence step looks like, and it's the same telemetry you'd correlate in a linkable-token-identifier investigation.

The takeaway

TAP isn't an MFA bypass — it's a strong credential that mints other credentials, which is more dangerous, not less. Contain it on every axis: lock the policy to short-lived, single-use passes (the 30-day, reusable defaults are a backdoor); scope it to onboarding/recovery groups and exclude privileged accounts; fence it with Conditional Access authentication strengths so it can bootstrap and nothing else; pair it with a tight sign-in frequency so the session doesn't outlive the pass; and verify identity out-of-band before issuing, with alerting on issuance and on the TAP→registration sequence. Used that way, TAP is a safe onboarding tool. Used the way it ships by default, it's your softest target.