IAM4.1 The Authentication Landscape

Authentication as a governance problem

Authentication is the process of proving an identity claim. A user says "I am priya.sharma@northgateeng.com." Authentication is how the system verifies that claim before granting any access. The strength of that verification determines how much trust the system can place in the identity, and every access decision downstream inherits that trust level.

The governance problem is not "does authentication exist?" Every Entra ID tenant has authentication. The governance problem is "does the authentication method match the sensitivity of the access it protects?" A user who authenticates with a password and SMS code gets the same access token as a user who authenticates with a FIDO2 security key. The identity platform doesn't distinguish between weak verification and strong verification unless you build authentication strength policies that enforce the distinction. Without those policies, the weakest registered method determines the effective security of every account.

This is why authentication is an IAM governance discipline, not just a security control. The authentication method landscape, the registration policies, the strength requirements, and the passwordless roadmap are architectural decisions that belong in the IAM program alongside identity lifecycle and access governance. A tenant that automates provisioning and governs access reviews but lets every user authenticate with password + SMS has a governance gap that undermines everything above it.

Estimated time: 50 minutes.

Your tenant's authentication posture

Before designing anything, discover what your tenant looks like right now. The authentication methods activity report tells you which methods users have registered and which methods they actually use to sign in.

Query the registration data programmatically for deeper analysis:

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","AuditLog.Read.All"

# Get authentication method registration details for all users
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

$report | Group-Object -Property MethodsRegistered | ForEach-Object {
    [PSCustomObject]@{
        Methods = ($_.Name -join ", ")
        UserCount = $_.Count
    }
} | Sort-Object UserCount -Descending | Format-Table -AutoSize

Methods                                           UserCount
-------                                           ---------
mobilePhone                                            142
mobilePhone, microsoftAuthenticatorPush                 89
microsoftAuthenticatorPush                              67
mobilePhone, microsoftAuthenticatorPush, fido2          12
fido2                                                    4
                                                        38

The empty row at the bottom is the critical finding — 38 users with no MFA method registered at all. These users authenticate with password only. Every Conditional Access policy that requires MFA will either block these users entirely or fail open if MFA isn't enforced.

Now identify which users are password-only:

$passwordOnly = $report | Where-Object {
    $_.MethodsRegistered.Count -eq 0 -or
    ($_.MethodsRegistered.Count -eq 1 -and $_.MethodsRegistered -contains "password")
}
Write-Host "Password-only users: $($passwordOnly.Count)"

# Check if any are administrators
foreach ($user in $passwordOnly) {
    $roles = Get-MgUserMemberOf -UserId $user.UserPrincipalName -All |
      Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.directoryRole' }
    if ($roles.Count -gt 0) {
        $roleNames = $roles.AdditionalProperties.displayName -join ", "
        Write-Host "  ⚠ ADMIN: $($user.UserDisplayName), roles: $roleNames"
    }
}

If any administrator accounts appear in the password-only list, that's your highest-priority finding. An administrator account with password-only authentication is the single most exploitable identity in your tenant. Password spray, credential stuffing, and phishing all target password-based authentication, and an administrator credential gives the attacker every permission that role holds.

The registration report also reveals SSPR (self-service password reset) registration gaps. SSPR requires users to register authentication methods before they can reset their own password, if a user hasn't registered for SSPR, every password reset requires an administrator. Check the SSPR coverage alongside MFA coverage because they share the same underlying registration:

$ssprGap = $report | Where-Object { -not $_.IsSsprRegistered }
Write-Host "Users without SSPR registration: $($ssprGap.Count)"
Write-Host "  These users cannot reset their own password"
Write-Host "  Every reset requires admin action ($25 per incident)"

# Users without EITHER MFA or SSPR: no self-service capability at all
$noSelfService = $report | Where-Object { -not $_.IsMfaRegistered -and -not $_.IsSsprRegistered }
Write-Host "`nUsers without MFA AND without SSPR: $($noSelfService.Count)"
Write-Host "  These accounts are password-only with no self-service, highest risk + highest cost"

The overlap matters because MFA and SSPR share authentication method registrations in Entra ID. When you run the Authenticator registration campaign in section 4.2, it closes both the MFA gap and the SSPR gap simultaneously, users who register Authenticator for MFA automatically satisfy the SSPR registration requirement. The registration campaign produces two governance improvements with a single action.

What your users actually use to sign in

Registration tells you what methods users have set up. Usage tells you which methods they actually use. A user might have Authenticator registered but still authenticate with SMS because their Conditional Access policy accepts any MFA method and SMS prompts faster than an Authenticator push.

Query the sign-in logs to determine actual method usage over the last 30 days:

$signIns = Get-MgAuditLogSignIn -Filter "createdDateTime ge $((Get-Date).AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ'))" -All `
  -Property UserDisplayName,AuthenticationMethodsUsed,AuthenticationDetails,Status

$methodUsage = @{}
foreach ($s in $signIns) {
    if ($s.Status.ErrorCode -eq 0) {
        foreach ($method in $s.AuthenticationMethodsUsed) {
            if (-not $methodUsage[$method]) { $methodUsage[$method] = 0 }
            $methodUsage[$method]++
        }
    }
}

Write-Host "Authentication method usage (last 30 days, successful sign-ins):"
$methodUsage.GetEnumerator() | Sort-Object Value -Descending |
  ForEach-Object { Write-Host "  $($_.Key): $($_.Value) authentications" }

Authentication method usage (last 30 days, successful sign-ins):
  Mobile app notification: 4,218 authentications
  Mobile phone SMS: 2,891 authentications
  Password: 1,456 authentications
  FIDO2 security key: 89 authentications
  Windows Hello for Business: 0 authentications

The usage data reveals something the registration data can't: even when users have multiple methods registered, they default to the most convenient one. If SMS is faster than a push notification (it often is on older devices), users choose SMS. If the Conditional Access policy doesn't require a specific method strength, users choose the path of least resistance every time. The usage distribution is the ground truth of your authentication posture, not the registration report.

Compare registration (what users have) against usage (what users do). The gap between the two tells you where governance is needed. If 89 users have Authenticator registered but only 4,218 of 8,654 successful authentications used it, you have a method preference problem that registration policies alone won't fix. Authentication strength policies (section 4.7) solve this by requiring specific methods for specific access scenarios.

The three authentication tiers

Authentication methods divide into three tiers based on their security properties. The tiers aren't marketing categories, they correspond to specific attack resistance characteristics.

Tier 1: Password-based. The user provides something they know. Passwords are phishable (the user can be tricked into entering them on a fake login page), replayable (a stolen password works until it's changed), and shareable (the user can give the password to someone else). Password-based authentication is the weakest tier because the credential has no binding to the user's identity, anyone who knows the password IS the user from the system's perspective.

Tier 2: Password + MFA. The user provides something they know plus something they have or are. MFA dramatically reduces account compromise because the attacker needs both factors. But not all MFA methods are equal. SMS codes are vulnerable to SIM swapping (the attacker convinces the carrier to transfer the victim's phone number to a new SIM) and SS7 interception (exploiting the signaling protocol that routes SMS messages between carriers). Push notifications without number matching are vulnerable to MFA fatigue attacks: the attacker triggers dozens of push notifications until the user approves one to stop the noise. Microsoft enforced number matching by default starting in 2023 specifically to counter this attack. TOTP codes from an authenticator app are better, they require physical access to the registered device, but they're still phishable because the user can enter the code on a fake login page that proxies it to the real service.

The critical vulnerability across all Tier 2 methods is the AiTM (adversary-in-the-middle) attack. An AiTM proxy sits between the user and the legitimate login page. The user sees what looks like the real Microsoft sign-in page. They enter their password: the proxy forwards it to the real service. The service sends an MFA challenge: the proxy relays it to the user. The user completes the MFA (enters SMS code, approves push, enters TOTP): the proxy captures the session token issued by the real service. The attacker now has a valid session token that bypasses all future MFA challenges for the duration of the token's lifetime. Every Tier 2 method is vulnerable to this attack because the credential verification happens in the user's browser, which the proxy controls.

Tier 3: Phishing-resistant. The credential cannot be phished because the authentication protocol cryptographically binds the credential to the legitimate service. FIDO2 security keys, Windows Hello for Business, and certificate-based authentication are phishing-resistant. When a user authenticates with a FIDO2 key, the key verifies the domain of the service requesting authentication before signing the challenge. A fake login page at login.microsoftonline.com.evil.com would fail because the domain doesn't match the registered relying party. The credential never leaves the device, can't be phished, can't be replayed, and can't be shared.

The domain verification happens in hardware or in the operating system's credential provider, not in the browser. This is the architectural difference: Tier 2 methods verify in the user's browser (which the proxy can control), while Tier 3 methods verify in the key's firmware or the OS credential provider (which the proxy can't reach). The AiTM attack fails against Tier 3 because the proxy page has the wrong domain, and the credential refuses to sign.

The governance question is which tier each user population requires. The answer depends on the access each population has and the risk tolerance your organization accepts.

# Categorize users by current authentication tier
$allUsers = $report | Select-Object UserDisplayName, UserPrincipalName, MethodsRegistered, IsMfaRegistered, IsSsprRegistered

$tier1 = ($allUsers | Where-Object { -not $_.IsMfaRegistered }).Count
$tier3 = ($allUsers | Where-Object { $_.MethodsRegistered -contains "fido2" -or $_.MethodsRegistered -contains "windowsHelloForBusiness" }).Count
$tier2 = $allUsers.Count - $tier1 - $tier3

Write-Host "Authentication tier distribution:"
Write-Host "  Tier 1 (password only): $tier1 ($([math]::Round($tier1/$allUsers.Count*100))%)"
Write-Host "  Tier 2 (password + MFA): $tier2 ($([math]::Round($tier2/$allUsers.Count*100))%)"
Write-Host "  Tier 3 (phishing-resistant): $tier3 ($([math]::Round($tier3/$allUsers.Count*100))%)"

Authentication tier distribution:
  Tier 1 (password only): 38 (11%)
  Tier 2 (password + MFA): 298 (85%)
  Tier 3 (phishing-resistant): 16 (4%)

Most tenants show a distribution similar to this: a small tail of password-only users, a large middle of password + MFA, and a tiny fraction of phishing-resistant. The authentication architecture from this module shifts the distribution rightward, reducing Tier 1 to zero, moving privileged users to Tier 3, and establishing the governance policies that prevent regression.

The cost of password-based authentication

Password-based authentication isn't just a security problem, it's an operational cost that most organizations never quantify. Quantifying it makes the business case for passwordless investment.

# Estimate password-related operational cost
$totalUsers = (Get-MgUser -All -Filter "userType eq 'Member'" -ConsistencyLevel eventual -CountVariable total).Count

# Password resets in the last 90 days
$resetEvents = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Reset password (by admin)' or activityDisplayName eq 'Reset password (self-service)'" -All |
  Where-Object { $_.ActivityDateTime -gt (Get-Date).AddDays(-90) }

$adminResets = ($resetEvents | Where-Object { $_.ActivityDisplayName -eq 'Reset password (by admin)' }).Count
$selfResets = ($resetEvents | Where-Object { $_.ActivityDisplayName -eq 'Reset password (self-service)' }).Count

# Cost modeling
$helpdeskCostPerReset = 25  # Industry average: $20-30 per password reset ticket
$quarterlyHelpdeskCost = $adminResets * $helpdeskCostPerReset
$annualProjection = $quarterlyHelpdeskCost * 4

Write-Host "Password reset activity (last 90 days):"
Write-Host "  Admin-initiated resets: $adminResets"
Write-Host "  Self-service resets: $selfResets"
Write-Host "  Estimated helpdesk cost (quarter): `$$quarterlyHelpdeskCost"
Write-Host "  Projected annual cost: `$$annualProjection"

The cost calculation is conservative, it counts only direct helpdesk time. It doesn't include the productivity loss for the user waiting for a reset, the security risk during the reset window (when the user may share a temporary password over email or chat), or the cost of investigating password spray attacks against password-based accounts.

The broader cost model has three components beyond helpdesk tickets. First, lockout productivity loss: each password reset takes the user out of work for 15–30 minutes while they wait for IT, reset the password, and update the credential on their devices. At $50/hour average labor cost, 323 annual resets produce $2,400–$4,800 in lost productivity. Second, password spray investigation cost: your SOC spends time triaging alerts generated by password spray campaigns against your tenant. These alerts don't exist if the accounts don't have passwords. Third, the expected value of a credential compromise: the M-Trends data consistently shows that compromised credentials are the top initial access vector. If the average cost of investigating and remediating a credential-based breach is $50,000 and the annual probability of a password-based compromise is 5%, the expected annual cost is $2,500, on top of the operational costs. The passwordless investment isn't justified by helpdesk savings alone. It's justified by the reduction in the attack surface that generates the most incidents.

Query the password spray signal in your tenant to quantify the attack pressure:

# Password spray indicators in the last 90 days
$riskySigns = Get-MgAuditLogSignIn -Filter "riskState eq 'atRisk' and createdDateTime ge $((Get-Date).AddDays(-90).ToString('yyyy-MM-ddTHH:mm:ssZ'))" -All `
  -Property UserDisplayName,RiskDetail,RiskLevelAggregated,Status

$passwordSpray = $riskySigns | Where-Object { $_.RiskDetail -like "*password*" -or $_.RiskDetail -like "*spray*" }
Write-Host "Risky sign-ins (last 90 days): $($riskySigns.Count)"
Write-Host "Password-related risk events: $($passwordSpray.Count)"
if ($riskySigns.Count -gt 0) {
    Write-Host "  ⚠ Each risk event triggers SOC investigation time"
    Write-Host "  Annual projection: ~$([math]::Round($riskySigns.Count * 4 * 0.5)) investigation hours"
}

At Northgate Engineering: NE's authentication posture diagnostic reveals 38 password-only accounts (4.7% of 810 users), 4 of which hold administrative roles. 672 users (83%) have password + SMS or push. 100 users (12%) have Authenticator with number matching. Zero users have FIDO2 or Windows Hello. Password resets in the last quarter: 89 admin-initiated ($2,225 helpdesk cost) plus 234 self-service. The annual projected password cost is $8,900 in helpdesk time alone, enough to fund FIDO2 keys for every administrator. ADR-IAM4-001 documents the finding: "Current authentication posture relies entirely on phishable methods. Passwordless deployment is a security priority and a cost reduction opportunity."

Decision-point simulation

Scenario 1. Your CISO reviews the authentication tier distribution and asks: "Why can't we just enable the Conditional Access policy to require phishing-resistant MFA for everyone and skip the phased rollout?" What's the operational risk of that approach?

If you enforce phishing-resistant MFA for all users today, every user who hasn't registered a FIDO2 key, Windows Hello, or certificate-based credential gets locked out. That's 95% of most tenants. The phased approach exists because you need to deploy the methods before you can require them. Registration comes first, enforcement comes second, and the gap between registration and enforcement is where the governance work happens, registration campaigns, TAP bootstrapping for passwordless, and gradual policy tightening. Module 5's Conditional Access policies enforce what this module deploys.

Scenario 2. A department head pushes back on the passwordless roadmap: "Our team uses shared workstations. FIDO2 keys and Windows Hello don't work for shared environments because they're tied to a specific device or person." Is this accurate, and what's the solution?

Partially accurate. Windows Hello for Business is device-bound, it works on the device where it was enrolled and can't authenticate on a different machine. That makes it unsuitable for shared workstations. But FIDO2 security keys are portable: the user carries the key and can authenticate on any device that supports FIDO2 (which includes any modern browser). For shared workstation environments, FIDO2 keys are the correct passwordless method. The user inserts the key, touches it, and authenticates. When they remove the key, the session is no longer bound to them. CBA with smart cards also works for shared environments, same principle (portable credential, device-independent authentication).

Scenario 3. Your password reset cost analysis shows $8,900 annually. The CFO says "That's not enough to justify a passwordless project." How do you respond?

The $8,900 captures only direct helpdesk cost. The complete cost includes: productivity loss per password reset (15–30 minutes per incident × 323 annual resets = 80–160 lost work hours), security investigation cost for password spray alerts (your SOC spends time triaging alerts that wouldn't exist without passwords), and the expected value of a credential compromise incident (average breach cost × probability of password-based compromise). The M-Trends data shows that compromised credentials remain the primary initial access vector. The passwordless investment isn't justified by helpdesk savings alone, it's justified by the reduction in the attack surface that generates the most incidents.

Reusable script, authentication posture diagnostic

# IAM4.1. Authentication Posture Diagnostic
# Run against your tenant to assess current authentication state

Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All","AuditLog.Read.All","Directory.Read.All"

# 1. Registration distribution
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

$tier1 = ($report | Where-Object { -not $_.IsMfaRegistered }).Count
$tier3 = ($report | Where-Object { $_.MethodsRegistered -contains "fido2" -or $_.MethodsRegistered -contains "windowsHelloForBusiness" }).Count
$tier2 = $report.Count - $tier1 - $tier3

Write-Host "`n=== Authentication Tier Distribution ==="
Write-Host "  Tier 1 (password only): $tier1 ($([math]::Round($tier1/$report.Count*100,1))%)"
Write-Host "  Tier 2 (password + MFA): $tier2 ($([math]::Round($tier2/$report.Count*100,1))%)"
Write-Host "  Tier 3 (phishing-resistant): $tier3 ($([math]::Round($tier3/$report.Count*100,1))%)"

# 2. Password-only administrators
$passwordOnlyAdmins = $report | Where-Object { -not $_.IsMfaRegistered } | ForEach-Object {
    $roles = Get-MgUserMemberOf -UserId $_.UserPrincipalName -All |
      Where-Object { $_.AdditionalProperties['@odata.type'] -eq '#microsoft.graph.directoryRole' }
    if ($roles.Count -gt 0) { $_ }
}
Write-Host "`n=== Password-Only Administrators ==="
Write-Host "  Count: $($passwordOnlyAdmins.Count)"

# 3. Method distribution
Write-Host "`n=== Method Registration Distribution ==="
$methods = @{}
foreach ($u in $report) {
    foreach ($m in $u.MethodsRegistered) {
        if (-not $methods[$m]) { $methods[$m] = 0 }
        $methods[$m]++
    }
}
$methods.GetEnumerator() | Sort-Object Value -Descending |
  ForEach-Object { Write-Host "  $($_.Key): $($_.Value) users" }

# 4. Password reset cost (last 90 days)
$resets = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Reset password (by admin)'" -All |
  Where-Object { $_.ActivityDateTime -gt (Get-Date).AddDays(-90) }
$quarterCost = $resets.Count * 25
Write-Host "`n=== Password Reset Cost ==="
Write-Host "  Admin resets (90 days): $($resets.Count)"
Write-Host "  Estimated quarterly cost: `$$quarterCost"
Write-Host "  Projected annual cost: `$$($quarterCost * 4)"