It’s 4:52 PM on a Friday. Your help desk gets a call from someone who sounds exactly like a senior finance admin — same accent, right department, knows the last four of the employee ID they pulled off a LinkedIn-scraped org chart. They’re “traveling,” their phone “died,” and they need their MFA methods reset right now or a payment run misses the cutoff. The agent, trained to be helpful and measured on ticket close time, resets the methods. Ninety minutes later there’s a new authenticator enrolled on an attacker’s device and a golden path into your tenant.
That call is not hypothetical. It’s the opening move in the Scattered Spider playbook, the same technique that gutted MGM and Caesars, and by every incident-response retro I’ve read this year it remains the number-one initial-access vector of 2026. Not a zero-day. Not a phishing kit. A phone call and a confident voice.
Face Check in Microsoft Entra Verified ID going generally available — specifically its integration with Conditional Access authentication strengths — is the first control Microsoft has shipped that actually aims at the human in that loop instead of the token. It won’t fix your help desk’s culture. But it moves the trust decision off the agent’s judgment and onto a liveness-checked biometric match. That’s the story worth your attention.
What actually shipped
Face Check itself has existed as a premium capability of Verified ID for a while — it matches a live selfie captured in Microsoft Authenticator against the portrait photo bound inside a verified credential, and returns a match confidence plus a liveness signal. The privacy design is the genuinely good part: the verifier never receives the biometric template or the raw selfie. You get back a confidence score and a liveness verdict, and nothing that would turn your logs into a face database you now have to defend to a regulator.
What’s new at GA is the plumbing that makes it usable as an access gate rather than a one-off onboarding check. Face Check now slots into Conditional Access authentication strengths via authentication context, so you can demand a fresh, liveness-verified identity presentation on specific actions — admin role activation in PIM, access to a Tier-0 app, or the internal help-desk reset console itself. That last one is the point. You can require the person requesting the reset to prove they’re the human in the credential photo before an agent can touch their account.
How the match works, minus the marketing
The flow has four moving parts you need to understand before you design around it:
- A credential with a photo. Face Check needs a verified credential that carries a portrait — typically issued through an identity-verification partner (Au10tix, LexisNexis, IDEMIA and similar) after a government-ID proofing step, or a Microsoft Entra Verified ID Face Check-enabled workplace credential you issue yourself.
- Live capture in Authenticator. The user gets a presentation request, opens Microsoft Authenticator, and takes a selfie. Azure AI Face runs passive liveness to distinguish a real face from a photo, a screen replay, or a printed mask.
- Server-side match. The selfie is compared to the credential portrait. Your app receives a result payload, not an image.
- The policy decision. Your verifier logic — or, at GA, Conditional Access — decides whether the confidence and liveness results clear your bar.
A presentation request through the Request Service API looks roughly like this, with the Face Check block being the part that matters:
{
"includeReceipt": false,
"authority": "did:web:contoso.com",
"registration": { "clientName": "Helpdesk High-Assurance Verify" },
"callback": {
"url": "https://helpdesk.contoso.com/api/verifier/callback",
"state": "reset-ticket-88431",
"headers": { "api-key": "REDACTED" }
},
"requestedCredentials": [
{
"type": "VerifiedEmployee",
"acceptedIssuers": [ "did:web:contoso.com" ],
"configuration": {
"validation": {
"allowRevoked": false,
"faceCheck": {
"sourcePhotoClaimName": "photo",
"matchConfidenceThreshold": 70
}
}
}
}
]
}
The knob to argue about internally is matchConfidenceThreshold. Microsoft supports a range (roughly 50–100); the practical default lands around 70. Push it to 90 and you’ll cut false accepts but you’ll also start bouncing legitimate users with bad lighting, new glasses, or a beard they grew since the credential photo. Set it too low and you’ve built theater. Pilot with real staff before you pick a number, and expect to tune it per population.
Wiring it into Conditional Access authentication strengths
The GA integration works through authentication context. You define a context, bind a Conditional Access policy to it that requires the Verified ID / Face Check strength, and then have your sensitive app or workflow request that context. Conceptually:
- Create an authentication context (e.g.
c25 – Face Check Required) under Entra admin center → Protection → Conditional Access → Authentication context. - Author a CA policy scoped to that context, targeting the users and the resource (your help-desk tool, the PIM-eligible admin roles, your Tier-0 app), with the grant control set to require the Verified ID presentation.
- Have the protected resource demand the context at the sensitive step — a
claimschallenge for a custom app, or the built-in binding for PIM role activation.
For PIM specifically, this is the combination I’d deploy first: an eligible Global Administrator or Privileged Role Administrator activation that triggers a Face Check before elevation. If an attacker has phished a session token and even sits on a valid PIM-eligible assignment, they still can’t produce a live face matching the credential photo. That’s a meaningfully higher bar than a push notification the victim will approve out of fatigue.
The help-desk workflow you should actually build
Don’t bolt Face Check onto the old process. Redesign the process around it. The winning pattern I’ve seen:
- The help desk never resets credentials based on voice, callback number, or knowledge-based questions. Those are dead. Manager-in-the-loop verbal approval is dead too — attackers spoof managers.
- The reset console requires the requesting user to complete a Face Check presentation, initiated by the agent, before any reset control unlocks. The agent’s role becomes “start the verification and read the result,” not “decide if this sounds legit.”
- If the user genuinely can’t complete Face Check — lost device, no enrolled credential — you fall into a documented, deliberately slow exception path with in-person or supervisor escalation. Make the secure path the fast one and the exception path the annoying one. Attackers optimize for the annoying path when you make it the only bypass, so watch it closely.
The subtle win here isn’t cryptographic. It’s organizational: you’ve taken “be helpful under time pressure” off the agent and replaced it with a machine verdict they can’t be talked out of.
What it stops, and what it doesn’t
Passive liveness plus a portrait match kills the commodity attacks: a stolen photo held up to the camera, a screen replay of a Teams headshot, most off-the-shelf deepfake face-swap tooling that can’t satisfy depth and texture liveness cues in real time. For the vishing-driven reset scam, that’s the whole ballgame — the attacker on the phone simply is not the person in the credential and cannot become them on demand.
Be clear-eyed about the edges, though. Liveness detection and injection-attack resistance are an arms race, and well-funded adversaries are experimenting with real-time generative video and camera-feed injection. Face Check raises the cost dramatically; it does not make impersonation impossible forever. It’s also only as strong as the original proofing — if your credential issuance bound a photo to the wrong human, Face Check will faithfully verify the wrong human for years. Get your issuance IDV right, or you’ve built a very confident wall around the wrong door.
And it protects the flows you actually put it in front of. It does nothing for a token-theft path that never touches a Face Check-gated action. Treat it as one high-assurance control among phishing-resistant passkeys and device compliance, not a replacement for them.
Licensing, cost, and the gotchas
Verified ID is included with Entra ID P1/P2, but Face Check is a metered add-on billed per verification (historically around USD $0.25 per transaction — check current tenant pricing). That per-check meter shapes design: gate Face Check to genuinely sensitive events, not every sign-in, or your bill and your users will both revolt. Every user in scope needs a compatible credential provisioned in advance — you cannot Face Check someone who never enrolled, and enrollment is the project’s real long pole. Budget more time for issuance rollout than for the CA policy, which takes an afternoon. Also: Microsoft Authenticator is required for capture, so your BYOD and Authenticator posture is now on the critical path for password resets.
Where this is heading
Expect the roadmap to push Face Check deeper into native flows so you stop hand-rolling verifier apps — tighter first-party hooks into PIM activation, help-desk tooling, and eventually break-glass and SSPR paths are the obvious next steps, and some are still in preview even as the CA integration lands GA. Watch the release notes rather than the keynote for what’s actually shippable. The direction is unambiguous: Microsoft wants a verified, liveness-checked human behind every privileged action, and this is the first control that makes that a policy you can enforce instead of a principle you write in a standard nobody reads.
Start with one flow. Put Face Check in front of PIM Global Admin activation, pilot it with your own identity team, tune the confidence threshold on real faces, then move to the help-desk reset console. If you only ship one high-assurance control this quarter, this is the one that maps directly to how you’re most likely to get breached.