Ending Lost-Phone MFA Resets With Self-Service Access Passes

The Old Way: an employee cracks their phone screen over the weekend, wipes it, restores from a cloud backup

The New Way: identity verification and MFA method reset stop being a live phone call and become a governed, time-boxed, self-service workflow built on Microsoft Entra ID

#Prerequisites and Permissions

• Microsoft Entra ID P1 (P2 recommended) — Temporary Access Pass is included in the Authentication Methods Policy at no extra licence cost, but Conditional Access enforcement requires P1.
• An app registration with the Microsoft Graph application permissions UserAuthenticationMethod.ReadWrite.All and User.Read.All, admin-consented once by a Global Administrator and never touched again.
• The service principal running the automation should hold the Authentication Administrator Entra role, not Global Administrator, and ideally be activated only just-in-time through Privileged Identity Management (PIM).
• A verified HR system of record (Workday, SAP SuccessFactors, or an HR attribute sync into Entra) so the flow can confirm manager relationship without asking the user.
• ServiceNow (or Power Automate with a Microsoft Forms front end) to host the intake catalogue item.
• Test scope: pilot with a single department, TAP lifetime capped at 60 minutes, single-use only, no permanent Conditional Access changes. Blast radius if misconfigured is limited to one tenant-wide authentication method policy setting, which can be reverted in under a minute (see Rollback).

#Implementation Steps

#

Step 1: Enable Temporary Access Pass in the Authentication Methods Policy

Action: patch the tenant-wide policy to switch TAP on with sensible lifetime bounds.

1Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
2
3$body = @{
4    "@odata.type" = "#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration"
5    state = "enabled"
6    isUsableOnce = $true
7    minimumLifetimeInMinutes = 60
8    maximumLifetimeInMinutes = 480
9    defaultLifetimeInMinutes = 60
10    defaultLength = 8
11} | ConvertTo-Json
12
13Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/TemporaryAccessPass" -Body $body -ContentType "application/json"

Expected result: a passcode returned once, never re-displayable. Evidence: the response object logged (with the passcode value redacted in the ticket, kept only in the secure delivery channel).

#

Step 6: Deliver the passcode out-of-band

Action: send the passcode via SMS to the phone number already verified in Entra, or have the manager relay it in person. Never send it to the same device that just failed authentication.

Expected result: user enters the TAP at the sign-in prompt in place of the authenticator push. Evidence: sign-in log entry (Step 7 verification) showing authentication method “Temporary Access Pass”.

#

Step 7: Revoke the broken authentication method and force re-registration

1$methodId = "f9e8d7c6-b5a4-3210-9876-543210fedcba"
2Invoke-MgGraphRequest -Method DELETE -Uri "https://graph.microsoft.com/v1.0/users/$userId/authentication/microsoftAuthenticatorMethods/$methodId"

Expected result: HTTP 204, old method removed, user prompted to register a fresh authenticator or, ideally, a phishing-resistant passkey during the same TAP session. Evidence: updated authentication methods list for the user showing zero legacy methods and one new registration timestamp.

#

Step 8: Push the audit event to the ticketing system and close the loop

1{
2  "event": "tap_issued",
3  "requestId": "RITM0010542",
4  "userPrincipalName": "j.harker@kbytech.com",
5  "approvedBy": "k.seward@kbytech.com",
6  "tapLifetimeMinutes": 60,
7  "isUsableOnce": true,
8  "issuedAtUtc": "2024-05-01T09:15:00Z",
9  "deliveryChannel": "sms-verified-number",
10  "oldAuthMethodRevoked": true,
11  "ticketAutoClose": true
12}

Expected result: ServiceNow request auto-closes with the full audit trail attached; no technician assignment ever occurs unless the escalation conditions below fire.

#Verification and Expected Evidence

Confirm the flow worked end to end by pulling the sign-in log for the affected user and checking the authentication method actually used.

Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'j.harker@kbytech.com'" -Top 1 | Select-Object CreatedDateTime, AuthenticationMethodsUsed, Status

Expected output example:

1{
2  "CreatedDateTime": "2024-05-01T09:22:11Z",
3  "AuthenticationMethodsUsed": ["TemporaryAccessPass"],
4  "Status": { "errorCode": 0, "failureReason": null }
5}

Additional evidence to file against the request record: the Conditional Access “what if” report confirming the sign-in satisfied MFA, and a screenshot of the user’s authentication methods pane showing the new authenticator or passkey registered within the same session as the TAP.

#Rollback

If a TAP is issued to the wrong identity, or an approval is later found to be fraudulent, revoke immediately and force session termination.

1$tapId = "3d2ec39c-9a3d-4f2f-9b1c-5c1f8e2b6a11"
2Invoke-MgGraphRequest -Method DELETE -Uri "https://graph.microsoft.com/v1.0/users/$userId/authentication/temporaryAccessPassMethods/$tapId"
3Revoke-MgUserSignInSession -UserId $userId

If the tenant-wide feature itself needs to be paused (for example during a suspected mass social-engineering campaign against the helpdesk), disable the policy entirely and fall back to the manual verification process for the duration of the incident.

1$body = @{ "@odata.type" = "#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration"; state = "disabled" } | ConvertTo-Json
2Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/TemporaryAccessPass" -Body $body -ContentType "application/json"

Rollback trigger: any TAP issuance tied to a confirmed compromised approval, or more than three TAP requests tenant-wide within one hour outside business hours.

#Failure and Escalation Conditions

The following conditions must wake a human L3 identity technician, not be absorbed by the automation:

• The same user requests a TAP more than twice within a rolling 24-hour period — likely device instability or a targeted account, not a genuine hardware loss.
• The manager approval step times out after 4 business hours with no response — route to L3 for manual manager verification via a second channel.
• Graph API returns HTTP 403 or 401 on the issuance call — indicates the service principal’s permissions or PIM activation have lapsed; this is an automation health failure, not a user issue, and must page the identity engineering on-call.
• The sign-in log shows the TAP consumed from a geography or IP range inconsistent with the user’s normal pattern or device compliance state — treat as a potential account compromise, escalate to the Security Operations Centre, and do not close the ticket until reviewed.

Monitoring signal: a Sentinel analytics rule watching AuditLogs for “Admin registered temporary access pass” combined with a subsequent sign-in from an unmanaged or newly seen device within the TAP lifetime window.

#Measuring Ticket Deflection

Track these metrics for at least one full month before and after rollout to prove the engineering effort paid off:

• Volume of tickets categorised “MFA reset” or “account lockout” per week.
• Average technician handle time on this category — the manual process typically runs 12 to 20 minutes; the new flow should show near-zero technician minutes, with total resolution time bounded by manager approval latency instead.
• Percentage of TAP requests resolved with zero human touch end to end.
• Correlation with security incident data — a drop in helpdesk-impersonation attempts reported by the SOC.

1az monitor log-analytics query 
2  --workspace $LAW_ID 
3  --analytics-query "SigninLogs | where AuthenticationDetails has 'Temporary Access Pass' | summarize Count=count() by bin(TimeGenerated, 1d)" 
4  --output table

Expected output example: a daily count trending upward on self-service TAP usage while the parallel ServiceNow report for manually-worked “MFA reset” tickets trends toward zero over the same period. That divergence is the deflection metric leadership actually cares about — fewer humans touching a task that used to consume a meaningful share of L1 capacity every single week.

#References

For the underlying platform behaviour and API contract, see Microsoft Entra Temporary Access Pass overview and configuration guide and the Microsoft Graph temporaryAccessPassAuthenticationMethod API reference. For the broader case on why phishing-resistant authenticator registration should be the end state of any TAP session, see CISA guidance on implementing phishing-resistant multifactor authentication.