Help Desk Identity Verification: Moving Beyond the MFA Prompt

Series: Verifying the Caller · Part 1 of 3 Part 1: The problem (you are here) · Part 2: Issuing the credential (coming soon) · Part 3: The verification event (coming soon)

A couple of years back I published an article showing how to verify a caller at the help desk by sending them a Microsoft Authenticator push prompt from PowerShell. It became my most popular article, and ever since writing it something hasn't sat right with me. There had to be a better answer.

Help desk identity verification is now a front door for real attacks. The crew tracked as Scattered Spider went through the IT service desk at MGM in 2023, and the 2025 attacks on Marks & Spencer and Co-op are widely reported to have started the same way: someone rang the help desk, impersonated an employee, and talked an agent into resetting their credentials. CISA and the FBI describe exactly this pattern in their joint advisory on Scattered Spider, and the UK's NCSC responded to the retail incidents by telling every organisation to review how their help desk authenticates staff before resetting passwords.

The timing is not getting kinder either. Microsoft retires SMS and voice MFA in Entra ID from 1 February 2027, and every user who loses their only sign-in method that week is another caller asking your agents for a reset.

Microsoft's official answer is Entra Verified ID. On the surface you issue a "credential" and later "verify" it. Underneath there is a lot to understand before you could trust it with a password reset, and one design decision that determines what a verification actually proves.

TL;DR

• An MFA push prompt proves someone is holding an unlocked phone. It does not prove who is on the call, and building a business process around approving out-of-band prompts trains users to do exactly what social engineers want.
• Entra Verified ID gives the caller a signed credential to present, with claims the agent can actually check, and an optional live face match called Face Check.
• Verification only proves what issuance proved. Issue credentials to anyone with a password and you have built an expensive way to verify a phished account.
• The core service is included with Entra ID. Face Check is metered at US$0.25 per check unless you hold Entra Suite.
• Microsoft ships a sample and a self-service recovery flow, not an agent-facing product. For the caller on the phone with your agent, you are building a small web app. Modern 42 has built one, and it is coming to a public repository with this series.

Why MFA push verification falls short

Let's start by drilling into why the out-of-band MFA prompt is begging to be taken advantage of.

When your agent sends a push prompt and the caller approves it, you have proven one thing: someone is holding an unlocked phone registered to that account.

Look at what that yes or no cannot tell you:

• It proves possession of a device, not the identity of the person on the call. Anyone holding the unlocked phone passes.
• The phone itself could be compromised. You are anchoring your trust to a device you cannot see or control.
• Push fatigue works for the attacker. Users conditioned to approve prompts will approve one more just to make them stop.
• Coaching gets around it. Real intrusion scripts include lines like "you'll get a prompt from IT in a second, just hit approve". The victim does the attacker's work for them.
• There are no claims in the answer. The agent gets a binary yes and has to treat it as an identity decision, with no name or employee ID to check against.

There is a second problem, and we created it ourselves. Making the prompt an official process trains users that approving MFA prompts outside of a login is normal, which is exactly the behaviour social engineering relies on.

What help desk identity verification actually needs

So if the push prompt is out, what does good look like?

Stop treating the device as the most trusted thing in the chain. The check needs to land on the human, and standard MFA cannot do that. Passkeys and FIDO2 keys are phishing resistant, and a push approval is not even that, but all of them only prove control of a key. Biometric passkeys are not so biometric either, if you know how they actually work.

At the moment the call comes in, I want five things:

• Bind a person to a credential, not just to a device that anyone could be holding.
• Carry claims the agent can actually check, like name, employee ID and department.
• Make coaching hard. Approving on autopilot should not be enough to pass.
• Produce an auditable record of every verification event.
• Ideally, prove liveness. A biometric check of the human at the moment of the call, matched against an authoritative source.

Enter Microsoft Entra Verified ID

This is where Microsoft Entra Verified ID earns its place at the help desk. It is Microsoft's implementation of decentralised identity, built on the W3C Verifiable Credentials standard, and it sits outside your normal authentication stack. Rather than a directory lookup, a credential is something the user holds and presents themselves, stored in a wallet inside Microsoft Authenticator. In a sense it is a passkey-like credential: a public and private key pair with claims and issuer information attached.¹

How you issue this credential, and how you verify it, is almost entirely your problem to solve. You could hand credentials out to anyone with no guard rails, or only to employees who have signed in with phishing resistant MFA on a compliant device, the same kind of step-up you would put in front of any other privileged action.

When it comes time to verify, Microsoft's APIs can prove three things: that the credential was issued by the issuer it names, that the claims inside have not been altered since, and, through a paid add-on called Face Check, that the person presenting it is a live match for the photo it carries. What is missing from that list is any proof that the claims were true in the first place.

If you only remember one thing from this article: how you issue a credential determines what verifying it can prove.

That is the thread that runs through this whole series.

Does Verified ID require my passport or personal information?

No. A credential can carry as little as you want, and claims are signed, not encrypted: the owner can read them in their wallet, and so can anyone they present to. Put as little in there as possible, and hash anything sensitive that has to be there, so a credential in the wrong hands exposes nothing.

Passports and driver licences only enter the picture in high assurance flows like Microsoft's own account recovery, where a third-party provider verifies the document before anything is issued. That brings privacy and employee uptake questions with it, and you do not need it for caller verification.

How Verified ID actually works

Three concepts carry the whole system: the credential, issuance, and presentation.

What is a verified credential?

A verified credential is a signed bundle of claims about its owner, bound to a key pair held in the user's Authenticator wallet. A claim can be a photo, a date of birth, an employee ID, or just a funny fact. Anyone who is presented with the credential can confirm three things via Microsoft's decentralised verification system:

1. Who the credential was issued by.
2. That the claims inside are exactly what that issuer signed.
3. Optionally, that the person presenting it is a live match for the photo it holds. That one is Face Check, and it is the only check that costs money.

You'll notice I have been careful not to say the claims are a true assertion of the identity presenting them. By the end of this post you will understand why.

My lab wallet. Two credential types from one issuer, and nothing stopped me issuing myself the same one five times. Every card is a signed bundle of claims the holder, and anyone they present to, can read. What gets issued, to whom, and how often is the whole of Part 2.

How is a credential issued?

Whenever the issuing party decides. Some organisations let employees self-issue through Microsoft's MyAccount page. Others build a web application so they control when a credential is granted and what has to be true first. Part 2 is about that decision, because it is where the security actually lives.

What is presentation?

Presentation is the act of challenging the user to provide their credential to satisfy your request. Your application creates a presentation request through the Request Service API, the user approves it in Authenticator, and Microsoft sends your application callbacks as the user progresses.

What Face Check costs (and why it shapes the design)

The first two of Microsoft's three claims come with every presentation. The third one, the live match, is the check a help desk cares about most, and it is the only one with a price tag on it.

During presentation, the user takes a live selfie in Authenticator, and Microsoft's Azure AI face service compares it against the photo claim inside their credential, liveness check included. Your application never sees the selfie. If the match clears the confidence threshold you set (default 70), you get back the score. If it doesn't, the whole presentation fails and you get no score at all. It moves you from "someone has this credential" to "the person holding this phone is the person this credential was issued to".

Without Face Check, presenting a credential is still someone holding an unlocked phone, just like the push prompt, only now with signed claims and an audit trail attached. Face Check is what puts the check on the human.

Now for the money, all in one place:

• The core Verified ID service is included with any Entra ID subscription, even the free tier, and covers 50,000 transactions per month, where a transaction is an issuance, a verification or a revocation. Beyond that, the tenant needs Entra ID P1 or P2.
• Face Check is metered separately at US$0.25 per check as of September 2026, call it 35 to 40 Australian cents. You are billed for every unique face match, pass or fail. A scan that never reaches the matching step is not billed.
• Entra Suite licences include 8 Face Check verifications per seat per month, pooled across the tenant, so for organisations already on Suite the marginal cost can be zero. Suite sits on top of a P1 or P2 base licence and lists at AU$18 per user per month on an annual commitment.

That looks cheap until you multiply it. A help desk doing 200 verified calls a week lands at roughly AU$3,500 to AU$4,000 a year, and an enterprise desk at ten times the volume is into serious money. An unprotected verification endpoint would also let someone run up that bill for you. Both facts shape the architecture in Part 3, where we gate who can trigger a Face Check and when.

The honest catch: this isn't out of the box

Time to set expectations, because this is the part the Microsoft demos gloss over.

What Microsoft gives you:

• The credential definition and issuance authority, configured in the Entra admin centre.
• Default self-service issuance through the MyAccount profile page.
• The Request Service APIs for issuance and presentation.
• A reference pattern for a verified help desk with a GitHub sample you can deploy to Azure. A sample, not a product: you host it, you own it, and it has no business rules of its own.
• Two built-in consumers of verification. Entitlement management access packages can require a Verified ID, with or without Face Check, on an ID Governance or Entra Suite licence. And since May 2026, Entra ID account recovery lets a fully locked-out user prove who they are with a government ID through a verification partner from the Microsoft Security Store, then hands them a Temporary Access Pass.

What Microsoft does not give you:

• Any agent-facing verification experience. There is still no screen where your help desk agent verifies the person on the phone.
• Any way to apply business rules to issuance without writing your own code.
• Any way to decide, per ticket, what the caller is allowed to have reset once they pass.

Want to control when a credential is issued, or what goes into it beyond directory data? You're building a web app. That's the trade. The upside is that the Microsoft side of the deployment is quick, while the app around it is the actual project.

Account recovery changes the question, so a word on it. It is self-service, it kicks in at sign-in for someone with no working method left, and it relies on a government ID checked by a paid third party rather than the employee credential your tenant issued. Good answer for the total lockout. No answer for the far more common call, where someone with a working account rings to change a phone number, unlock a device, or get a reset an attacker could use. That caller still lands on your agent, and that is the gap this series is about.

Here is the reason I have been careful not to say that verified claims prove identity. A credential is only as trustworthy as the process that issued it. Issue credentials to anyone who can log in to MyAccount with just a password, and Face Check will happily match a live face against a credential that a phished password created. Issue them only after phishing resistant MFA on a compliant device, and every verification from then on inherits that strength. Verification carries forward whatever trust issuance gave it.

One more limit. Face Check proves the person holding the phone matches the credential, not that they are the one on the call. A coached employee can still complete a Face Check for an attacker who has them on another line. The proof of concept narrows this: the agent reads the caller a PIN, and the presented credential has to match the identity the caller claimed, so an attacker cannot pass with some other credential they happen to hold. A relayed PIN is still a relayed PIN though. Part 3 covers how far that gets you and what stays a process control.

A working example: Modern 42's Verified ID help desk app

I won't pretend this is trivial to deploy. Microsoft's demos give you a feel for the moving parts but hide the complexity of production. The Entra configuration is the easy part. The business logic around the APIs decides whether Verified ID shines or falls over.

So I have built a proof of concept that I think gets you 90% of the way to a working pilot. It handles issuance, presentation, and the agent view for the caller verification scenario. The public repository is coming soon, and I will link it from every part of this series the day it lands, with follow-up articles on the Verified ID APIs and the architecture of the app. If you would rather not wait, tell me you want it and I will send you the link the day it is public, or walk you through the proof of concept before then.

Zoom

The agent console in the proof of concept, mid-verification. The agent types in who the caller claims to be, the app raises a presentation request, and the caller enters a PIN the agent reads out over the call. Only then is the credential checked, and it has to belong to the identity the agent typed. Face Check is off in this capture, and the debug panel is demo tooling, not part of the agent's view.

Is this all Verified ID can do?

No. Caller verification is just the use case I keep running into. The technology runs from the guided setup through to self-managed signing keys in Azure Key Vault on your own domain, and whatever you point it at, the issuance principle from this post goes with you.

So, should you do this?

Here is my honest read.

Worth pursuing if:

• Your help desk can reset passwords or MFA, which alone makes it an attack surface.
• You already hold Entra ID P1, P2 or Entra Suite licences.
• You have the capacity to own a small internal web application.

Hold off if:

• Nobody in your team can own that app.
• Your organisation is small enough that agents personally recognise every caller.
• Total lockouts are your only real problem. Entra ID account recovery may cover that on its own, at the price of a verification partner subscription.
• You are holding out for a turnkey agent-facing product, which Microsoft does not offer yet.

Next comes the decision everything else hangs off. Part 2: Issuing the credential you'll later trust. Custom issuance, out-of-band PINs, and keeping dirty directory data out of your credentials. It is where your help desk verification becomes worth trusting.

• Part 2: Issuing the credential you'll later trust (coming soon)
• Part 3: The verification event (coming soon)
• Demo app covering issuance, presentation and the agent view (coming soon, ask for the link)

While you wait, two related reads: why a stolen token keeps working after the user is cleaned up, and how step-up authentication protects the reset itself.

FAQ

Is Verified ID included in Entra ID P1? Yes. Verified ID is included with any Entra ID subscription at no extra cost, covering 50,000 transactions per month, where a transaction is an issuance, verification or revocation. P1 or P2 (including via M365 E3/E5) lets a tenant go beyond that allowance.

How much does Face Check cost? US$0.25 per face match as of September 2026, metered separately from the monthly transaction allowance and billed whether the match passes or fails. Entra Suite includes 8 Face Check verifications per seat per month, pooled across the tenant. Face Check is not included in P1, P2 or M365 E5 on their own.

Can you verify a Verified ID credential without building an app? Not for an agent taking a call. Access packages and Entra ID account recovery consume Verified ID out of the box, and Microsoft publishes a help desk sample, but there is no Microsoft product where an agent verifies a caller. That part, and the rules around it, are yours to build.

Does Entra ID account recovery replace help desk verification? It replaces the total-lockout call: a user with no working sign-in method proves their identity with a government ID through a Security Store partner and receives a Temporary Access Pass. It does not help an agent verify a caller who still has a working account.

Does a Verified ID prove the caller is who they say they are? Only as strongly as the process that issued the credential. Verification proves who issued it, that the claims are unaltered, and optionally that the presenter's face matches the photo. Whether the claims were true in the first place depends entirely on issuance.

Mandatory plug

This is the work Modern 42 does: Australian owned identity engineering across Canberra, Sydney, Melbourne and Brisbane. Help desk verification with Verified ID sits on our Secure Microsoft Entra ID line, next to the Conditional Access and lifecycle work it usually ships with.

If you want a second pair of eyes on your help desk process before Part 2 lands, book a 30-min discussion. No commitment, and an engineer on the line rather than a salesperson.