Entra ID Temporary Access Pass for Zero-Touch Onboarding

#Operational requirement

You are going to be handed this task in your first month: a new starter joins on Monday and needs into Entra ID before their laptop even boots. If the current process is a service desk agent typing a temporary password into a ticket, or emailing it, stop and read this before you touch anything. That password sits in plaintext in a mailbox or ticketing system until someone remembers to delete it. It will show up in an audit. It is also a live credential sitting in a system that is not designed to hold secrets.

Temporary Access Pass, TAP, is the correct fix. It is a time-boxed, revocable Entra ID authentication method that lets a new hire sign in exactly once, register Microsoft Authenticator as their primary method, and never see a traditional password. Configure it badly and you get one of two failures: the new hire is locked out on day one while the helpdesk scrambles, or the policy is scoped too wide and TAP quietly becomes a standing bypass that any administrator can hand out. Neither is acceptable. This runbook is the production-safe path: scoped policy, bounded lifetime, verified redemption, monitoring, and a rollback you can execute without panic.

#Prerequisites and required permissions

Confirm every item below before you make a single change. If any of these are missing, stop and escalate rather than working around them.

• Microsoft Entra ID P1 or P2 licensing on the tenant. TAP does not exist on the Free tier.
• Authentication Policy Administrator role to configure the TAP method policy. Global Administrator is only needed for the very first rollout if the role has never been delegated.
• Privileged Authentication Administrator or Authentication Administrator role to issue passes to individual users.
• Microsoft Graph PowerShell SDK installed, specifically the Microsoft.Graph.Identity.SignIns module.
• Delegated or application permissions Policy.ReadWrite.AuthenticationMethod and UserAuthenticationMethod.ReadWrite.All.
• An HR-driven onboarding group or dynamic group already built. Do not enable TAP against All users under any circumstance.
• A change ticket raised and approved before you flip the policy state, even for a pilot group.

#Step 1: Scope the Temporary Access Pass method policy

Go to Protection, Authentication methods, Policies, Temporary Access Pass in the Entra admin centre. Set the state to Enable and change the target from All users to a named security group, for example sec-NewHireOnboarding. Do this through Graph PowerShell instead of the portal so the change is scriptable, repeatable and reviewable by someone other than you.

1Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
2
3$params = @{
4 AuthenticationMethodConfigurations = @(
5 @{
6 "@odata.type" = "#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration"
7 Id = "TemporaryAccessPass"
8 State = "enabled"
9 IsUsableOnce = $true
10 DefaultLifetimeInMinutes = 60
11 DefaultLength = 8
12 MinimumLifetimeInMinutes = 10
13 MaximumLifetimeInMinutes = 480
14 }
15 )
16}
17
18Update-MgPolicyAuthenticationMethodPolicy -BodyParameter $params

Expected result: the policy shows Enabled with the target group listed, not All users. Before you run the command, export the current policy with Get-MgPolicyAuthenticationMethodPolicy | ConvertTo-Json -Depth 10 and save it to the change record. Do the same export after the change. Checkpoint: open the target group membership and confirm no service accounts or shared mailboxes are present. TAP against a shared identity is exactly the kind of finding an auditor writes up.

#Step 2: Set lifetime and one-time-use parameters

Set a default lifetime of 60 minutes with one-time-use set to true. The pass exists to bootstrap a single sign-in for Authenticator registration, not to act as a recurring credential, so it must die the instant it is redeemed. If your HR feed, Workday or SuccessFactors or similar, drives a dynamic group off hire date, a rule like the one below will populate membership automatically.

1(user.employeeHireDate -ge (Now()) ) and (user.employeeHireDate -le (Now()+P7D))

Expected result: the group fills a few minutes after the HR-driven provisioning sync completes. Capture a screenshot or export of the rule and the member count on rollout day. Checkpoint: dynamic group evaluation is not instant in most tenants. If you issue a pass before the user has actually landed in scope, policy evaluation will fail and you will spend twenty minutes debugging something that was simply a timing gap.

#Step 3: Issue a pass to a named new hire

Once the policy is confirmed enabled and the user is confirmed in scope, issue the pass individually. Never script this in bulk against a batch of accounts. Individual issuance keeps the audit trail tied to a named administrator action rather than an unattended job.

1Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
2
3$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "j.smith@kbytech.com" -BodyParameter @{
4 lifetimeInMinutes = 60
5 isUsableOnce = $true
6}
7
8$tap.TemporaryAccessPass

Expected result: a one-time alphanumeric value is returned. Log the request timestamp, your UPN and the target user’s UPN in the ticketing system. Do not log the pass value itself. Checkpoint: Graph shows this value exactly once. If you lose it before handing it over, delete the method and reissue a new one; Graph will not return the original value a second time.

Hand the pass to the new hire out of band. A verified phone call, a supervised in-person handover, or a video call where identity has already been checked against HR records are all acceptable. Email is not. Emailing the pass defeats the entire reason you moved off shared passwords.

#Step 4: Validate redemption and Authenticator registration

Have the new hire browse to https://aka.ms/mysecurityinfo and sign in using their UPN with the TAP value in place of a password. Expected result: Entra ID prompts immediately for security info registration, and the new hire should register Microsoft Authenticator with push notifications and number matching enabled as the primary method.

Pull the sign-in log entry for that event. In the admin centre go to Identity, Monitoring and health, Sign-in logs, filter by user and by authentication method equal to Temporary Access Pass, and export it into the onboarding evidence folder. Checkpoint: because the pass is one-time-use, redemption consumes it automatically. Run the command below and expect an empty result.

1Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId "j.smith@kbytech.com"

#Step 5: Build a bounded Conditional Access exception for the onboarding window

New hires rarely have a compliant or hybrid-joined device on day one. A blanket device-compliance requirement in Conditional Access will block their very first sign-in even after TAP succeeds. Build a narrowly scoped policy, for example CA100-Onboarding-DeviceGrace, targeting only the onboarding group, requiring MFA but omitting the compliant-device grant control. Set it to expire, or attach a scheduled access review, within 24 hours. Do not leave this exception standing.

Expected result: the new hire authenticates on an unmanaged device long enough to enrol into Intune and reach a compliant state. Capture the Conditional Access policy JSON export and the access review record with its due date. Checkpoint: check the exclusion list carefully. Nesting the wrong group here is a common mistake, and it can quietly exempt an entire department from device compliance rather than just the intended cohort.

#Change control and monitoring

Every state change to the TAP method policy, and every Conditional Access exception created against it, must be tied to a change ticket with a named approver. Log the before-and-after policy JSON as attachments on that ticket. Set a recurring weekly check against the Entra ID Usage and insights, Authentication methods report, and confirm no TAP method remains active against any account outside the onboarding group. A leftover TAP on a standard user account is a live bypass of your normal sign-in controls, and it will not show up unless someone actually looks for it.

If your tenant has Microsoft Sentinel or a SIEM ingesting Entra sign-in logs, build an alert on authentication method equal to Temporary Access Pass combined with a target user outside the onboarding group’s object IDs. That alert should page someone, not sit in a dashboard nobody opens.

#Verification

Confirm three artefacts exist for every onboarding case before you close the ticket: the authentication method policy export from before and after Step 1, the sign-in log entry from Step 4 showing TAP redemption followed by Authenticator registration, and the Conditional Access exception review record from Step 5 with its expiry date populated. If any one of these three is missing, the case is not verified, regardless of whether the new hire successfully signed in.

#Common Traps

#Rollback

If a scoping error exposes TAP to the wrong population, or the pilot needs to be reversed, follow these steps in order and do not skip the logging step.

1. Disable the method policy immediately by setting State = "disabled" in the same Update-MgPolicyAuthenticationMethodPolicy call, restoring from the pre-change JSON export you saved in Step 1.
2. Remove any TAP methods issued in error with Remove-MgUserAuthenticationTemporaryAccessPassMethod -UserId <upn> -TemporaryAccessPassAuthenticationMethodId <id>.
3. If the dynamic group rule itself was wrong, remove the affected users manually and correct the rule before re-enabling anything.
4. Set the Conditional Access exception from Step 5 to Report-only rather than deleting it, which keeps the definition for audit while stopping it from granting access.
5. Record the rollback action, the timestamp, and the reason in the change management system, referencing the original ticket number.

#Operational Summary

A correctly scoped, time-boxed Temporary Access Pass removes the weakest link in most onboarding processes: the shared or emailed temporary password sitting in a mailbox. The discipline that makes this safe in production is narrow targeting, one-time-use enforcement, passes issued individually with a traceable audit trail, weekly monitoring against stray active passes, and a Conditional Access exception that expires rather than lingering for months. A junior engineer who can enable the scoped policy, issue a pass, verify redemption in the sign-in logs, monitor for leftovers, and roll the entire change back cleanly has demonstrated a genuinely production-relevant identity governance skill, not a lab exercise. Keep the ticket, the exports, and the log entries together for every case; that evidence trail is what turns a working configuration into a defensible one.