The Architectural Separation Microsoft Doesn't Highlight

Microsoft's documentation treats MFA configuration and SSPR configuration as separate administrative domains. They live in different portal blades, have different policy scopes, and are managed by different teams in most large organizations. That separation is operationally convenient and architecturally dangerous.

When you enforce MFA through Conditional Access, you're controlling the primary sign-in path. When a user initiates SSPR, they exit that path entirely. SSPR has its own authentication method requirements, its own registration enforcement, and its own audit trail — and unless you've explicitly aligned those controls, you have two authentication systems with different security postures protecting the same identity.

The Authentication Methods Policy in Entra ID (formerly Azure AD) is the unified control plane that governs which methods are available for both MFA and SSPR. Most organizations have not fully migrated to this policy from the legacy per-user MFA settings and the legacy SSPR method configuration. That migration gap means you may have methods enabled for recovery that you believe you've disabled globally.

Run this to audit your current authentication method policy state:

Connect-MgGraph -Scopes "Policy.Read.All"

$authMethodsPolicy = Get-MgPolicyAuthenticationMethodPolicy
$authMethodsPolicy.AuthenticationMethodConfigurations | 
    Select-Object Id, State, 
        @{Name="IncludedGroups"; Expression={$_.AdditionalProperties.includeTargets.id}} |
    Format-Table -AutoSize

This output tells you which methods are enabled and which groups they target. If you see MicrosoftAuthenticator, Sms, Voice, or Email enabled without tight group scoping, those methods are available for recovery flows across your tenant — regardless of what your Conditional Access policies say about primary authentication.

---

How Recovery Flows Become Bypass Flows

The mechanics of a recovery-based bypass are straightforward. An attacker who has obtained a username — trivially available from LinkedIn, email headers, or prior breaches — initiates SSPR from the sign-in page. If the tenant has SSPR enabled for all users (the Microsoft default recommendation for reducing help desk load), the attacker reaches the verification step.

What verification is required? Whatever methods the user registered, which may include:

• SMS to a phone number the user registered during onboarding and never updated
• Alternate email to a personal address outside your tenant's visibility
• Security questions if your tenant was configured before Microsoft deprecated them (legacy tenants may still have this active)
• Backup codes generated during authenticator app setup and stored insecurely

Each of these is a lower-assurance signal than the phishing-resistant MFA you've deployed for primary sign-in. SMS is SIM-swappable. Alternate email is outside your control plane. Security questions are social-engineerable. Backup codes are static credentials.

The attacker doesn't need to phish your FIDO2 key. They need to know the target's phone carrier and file a SIM swap request, or find the alternate email address in a data breach, or call the help desk and claim the authenticator app was lost.

This is not theoretical. The Lapsus$ group, documented by Microsoft's own threat intelligence reporting, explicitly targeted help desk and recovery flows as a primary initial access technique against organizations with mature MFA deployments. Recovery was the path of least resistance.

---

Mapping the Specific Attack Surfaces in Entra ID

Understanding which controls to harden requires knowing exactly where the gaps exist. In a standard Entra ID configuration, the following surfaces are independently exploitable:

SSPR with insufficient method requirements. SSPR can be configured to require only one authentication method for reset. If that method is SMS, a SIM swap attack completes the bypass. Require two methods minimum, and ensure neither is SMS or voice for privileged accounts.

Alternate email as a recovery method. Entra ID allows users to register a personal email address as an SSPR verification method. That address is outside your tenant's Conditional Access, outside your MFA enforcement, and outside your visibility. An attacker who compromises the personal email account owns the recovery path.

Temporary Access Pass (TAP) without expiry governance. TAP is a time-limited passcode that bypasses MFA — by design. It exists to onboard users and recover locked accounts. If TAP issuance is not restricted to a privileged role with audit logging, and if TAP lifetime is not minimized, it becomes an administrative backdoor. The default TAP lifetime is one hour, but it's configurable up to 8 hours, and some organizations extend it for operational convenience.

Legacy authentication method registration. Users who registered authentication methods before your current policy was enforced may have methods registered that are no longer permitted for new registrations. Those legacy registrations remain valid for recovery unless you explicitly revoke them.

Help desk override procedures. The most dangerous surface is the one that doesn't appear in any policy blade. If your help desk can reset a password after a voice call with identity verification based on employee ID and manager name, you have a social engineering target that bypasses every technical control you've deployed.

Use this KQL query in Microsoft Sentinel or Log Analytics to identify SSPR events that used lower-assurance methods:

// Identify SSPR completions using SMS or voice verification
// Table: AuditLogs (Entra ID diagnostic logs forwarded to Log Analytics)
AuditLogs
| where OperationName == "Reset password (self-service)"
| extend AuthMethodUsed = tostring(AdditionalDetails[0].value)
| where AuthMethodUsed in ("Mobile phone", "Office phone", "Alternate email")
| project TimeGenerated, UserPrincipalName, AuthMethodUsed, 
    ResultDescription, IPAddress = tostring(InitiatedBy.user.ipAddress)
| order by TimeGenerated desc

Run this query weekly and route results to your SOC. Any privileged account appearing in this output is an immediate investigation priority.

---

Privileged Account Recovery Is a Separate Problem

Standard user account recovery is a governance problem. Privileged account recovery is an incident waiting to happen.

Global Administrators, Privileged Role Administrators, and Security Administrators should not be enrolled in SSPR at all. If a privileged account is locked out, recovery should require a break-glass procedure with physical or out-of-band verification — not a self-service flow that any authenticated request can initiate.

Entra ID allows you to exclude accounts from SSPR by group membership. This is not the default. You must explicitly configure it.

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod", "Group.Read.All"

$sspr = Get-MgPolicyAuthenticationMethodPolicy

$exclusionGroup = Get-MgGroup -Filter "displayName eq 'Privileged-Accounts-SSPR-Excluded'"


$privilegedRoles = @(
    "62e90394-69f5-4237-9190-012177145e10", # Global Administrator
    "e8611ab8-c189-46e8-94e1-60213ab1f814", # Privileged Role Administrator
    "194ae4cb-b126-40b2-bd5b-6091b380977d"  # Security Administrator
)

foreach ($roleId in $privilegedRoles) {
    $members = Get-MgDirectoryRoleMemberAsUser -DirectoryRoleId $roleId -ErrorAction SilentlyContinue
    if ($members) {
        foreach ($member in $members) {
            Write-Output "Privileged account: $($member.UserPrincipalName) — verify SSPR exclusion"
        }
    }
}

For break-glass accounts specifically, Microsoft recommends — and security architects should enforce — that these accounts have no registered SSPR methods, no registered MFA methods other than FIDO2 hardware keys stored physically, and that all sign-in activity is alerted in real time.

---

Compliance Frameworks Expect Equivalent Controls Across All Pathways

The governance dimension of this problem is underappreciated. SOC 2 Type II, ISO 27001:2022, HIPAA, and PCI-DSS v4.0 all contain requirements that apply to authentication controls broadly — not just to primary MFA.

PCI-DSS v4.0 Requirement 8.4 mandates MFA for all access into the cardholder data environment. If account recovery for accounts with CDE access can be completed without MFA-equivalent verification, that's a control gap auditors will flag. The requirement doesn't carve out an exception for "recovery flows."

ISO 27001:2022 Annex A Control 5.17 covers authentication information management and explicitly requires that reset and recovery procedures maintain equivalent security assurance to the original authentication mechanism. If your primary authentication is phishing-resistant and your recovery is SMS-based, you have a documented nonconformity.

HIPAA's Technical Safeguard requirements under 45 CFR §164.312(d) require covered entities to implement procedures to verify the identity of a person seeking access to electronic protected health information. A help desk procedure that resets credentials based on employee ID number does not satisfy this requirement for accounts with ePHI access.

When your next audit asks about authentication controls, the question won't stop at "do you have MFA?" It will extend to "what controls govern account recovery, and are they equivalent?" Most organizations cannot answer the second question with documentation.

---

A Hardening Strategy You Can Deploy

The following controls address the specific attack surfaces identified above. Implement them in sequence — each builds on the previous.

Migrate fully to the unified Authentication Methods Policy. Disable the legacy SSPR method configuration and the legacy per-user MFA settings. The unified policy is the only control plane that governs both flows consistently. Until you complete this migration, you cannot have a coherent view of what methods are available for recovery.

Set SSPR to require two methods, and remove SMS and voice from the permitted list for any account with privileged access or access to regulated data. Acceptable methods for recovery should be limited to Microsoft Authenticator (with number matching enabled), FIDO2 security keys, and certificate-based authentication where infrastructure supports it.

Restrict Temporary Access Pass issuance to a named role group with mandatory justification logging. TAP should require Privileged Identity Management (PIM) activation before issuance, with a maximum lifetime of 60 minutes and single-use enforcement enabled.

Audit registered authentication methods quarterly. Users who registered methods before your current policy was enforced may have stale, lower-assurance methods still active. Use the Microsoft Graph GET /users/{id}/authentication/methods endpoint to enumerate registered methods and compare against your policy baseline.

Implement a formal help desk identity verification procedure that does not rely on knowledge-based authentication. Acceptable alternatives include manager callback on a verified number, hardware token possession verification, or identity verification through a separate authenticated channel (such as a Teams call from the user's verified account). Document this procedure and include it in your SOC 2 or ISO 27001 evidence package.

Alert on all SSPR completions for accounts holding any Entra ID directory role. This is a one-line Sentinel alert rule. There is no legitimate reason a Global Administrator should be resetting their password through self-service. If it happens, it warrants investigation before the session is trusted.

---