Prove who is on the phone before you touch the account.
The caller completes a fresh multi-factor authentication against your own Microsoft Entra ID, using a method they have already registered, and reads back a code that exists only because that authentication succeeded.
Knowledge questions verify nothing.
Date of birth, manager's name, the last four digits of an employee number — all of it is obtainable, and a service desk under time pressure has no way to tell a prepared caller from a genuine one. The attacks that walked through UK retail help desks in 2025 did not defeat a control. They answered the questions.
The desk carries the risk
An engineer is asked to reset MFA, change a phone number or add a mailbox rule. Every one of those is an account takeover if the caller is not who they say. The decision sits with whoever picked up the phone.
Scripts do not scale to judgement
Verification policies get written, then quietly bypassed for the caller who sounds senior and impatient. The exception is the attack path.
The evidence is a note
"Verified caller" in a ticket is an assertion, not proof. When an auditor or insurer asks how you knew, there is nothing underneath it.
The code travels from the caller to the engineer. Never the reverse.
This is the decision everything else follows from, and it is what separates proof from a notification.
The engineer never sees the code
No screen in the product displays it. The API does not return it. If it did, an engineer could read it to a caller, and a convincing attacker would be handed the answer.
An approval prompt is not proof
Firing a push at the real user's phone proves the phone is reachable and that they will tap Approve. Both are true while an attacker is on the line.
Because the genuine user approving something tells you nothing about the caller.
An attacker rings claiming to be Alice
A prompt fires at Alice's actual phone. Alice is mid-meeting, has seen a hundred of these, and taps Approve. The desk records a successful verification and proceeds. Alice has confirmed only that she has a phone.
This is push-bombing, and it is named tradecraft in the CISA advisory on Scattered Spider. Several products work this way.
The same attacker rings claiming to be Alice
Alice authenticates and a code appears on her screen. The attacker is on the phone and cannot see it. Alice, who did not call anyone, is now looking at a page telling her to report this if she did not contact the service desk.
The attempt fails, and it fails loudly, at the desk of the person being impersonated.
The access this needs, stated plainly.
Proofcall is a third-party application asking for directory access, and you are right to want the specifics before you grant it. Every permission below is read-only in normal running.
| Permission | Why | When |
|---|---|---|
Organization.Read.All |
Read your organisation name and confirm you hold Entra ID P1, without which Conditional Access does not exist and the product cannot work. | Always |
User.Read.All |
Resolve the person the engineer names to a stable directory object, so a renamed account cannot be confused with a different one. | Always |
UserAuthenticationMethod.Read.All |
Tell the engineer, before they start, whether the caller has any multi-factor method registered at all. Optional — refuse it and we simply stop offering the warning. | Always |
Policy.Read.ConditionalAccess |
Notice when your Conditional Access policy has been changed or removed, so you find out from a dashboard rather than from a failed verification during an incident. | Always |
Policy.ReadWrite.ConditionalAccessAuthenticationContext.ReadWrite.All |
Create the authentication context and the one policy bound to it, during setup. Granted as the administrator running setup, not to the application — so it expires with their session and cannot be used without a signed-in Conditional Access administrator. | Setup only |
We will not perform privileged actions on your users' accounts unless the caller has proven control of your own multi-factor authentication.
The request this cannot verify is the one most worth verifying.
"I have lost my phone, please reset my MFA" is circular by definition — the caller cannot complete multi-factor authentication, which is the entire point of the call. It is also the single most abused service desk request.
We refuse rather than fail open
When a caller has no registered method, the API returns a refusal and says so. It does not quietly downgrade to something weaker and call it verified.
Vouching is recorded as vouching
A nominated colleague can authenticate and vouch for them. That is a weaker claim and every screen, record and export says so in those words. It never looks like direct proof.
Per engineer, not per verification.
Charging per verification would bill you more every time you applied a security control. Seats keep the bill predictable and the incentive pointing the right way.
One organisation verifying its own staff. Single tenant, single consent.
- One Microsoft Entra tenant
- Unlimited verifications
- Direct and approver verification
- Email and read-aloud delivery
- Full audit trail and CSV export
- Drift monitoring on your CA policy
Verifying callers across many client tenants, with PSA linkage and per-client records.
- Unlimited client tenants
- Self-serve tenant onboarding
- ConnectWise ticket writeback
- Per-client drift monitoring
- Agent credentials with capability limits
- MCP server for AI service desk agents
Self-hosted, private tenancy, or procurement that needs a paper trail.
- Everything in Managed provider
- Self-hosted or private deployment
- SSO and SCIM for engineer accounts
- Custom data residency
- Security review and DPA support
Prices exclude VAT. Every plan includes the full verification flow — the difference is how many tenants you onboard and what you connect it to.
The ones that come up first.
Does this require our users to install anything?
No. They use a multi-factor method they have already registered in your tenant. If they sign in to Microsoft 365 today, they can be verified today.
What if the caller has no MFA registered at all?
The verification is refused rather than downgraded, and the engineer is told why. A nominated colleague can authenticate and vouch for them instead — recorded, everywhere, as vouching rather than as proof.
Will the Conditional Access policy lock our users out?
It cannot. The policy is scoped to an authentication context, which means it is evaluated only when an application explicitly requests that context. Nothing else in your estate requests it, so the policy never applies to Outlook, Teams, SharePoint, VPN or any ordinary sign-in.
Do you need permission to change our Conditional Access permanently?
No. Setup needs it, and takes it as a delegated permission belonging to the administrator running setup — so it expires with their session. In normal running the application holds read-only access.
Can an AI agent run this?
Yes, and whether one did is recorded permanently. Agent credentials carry explicit capabilities, so you can allow an agent to start verifications while reserving the highest-risk actions for a named human.
What do we need on the Microsoft side?
Entra ID P1 for Conditional Access, and a Global Administrator to complete setup once. Setup checks the licence before it changes anything.
Run it against a real call this afternoon.
Setup is one consent and one policy, and finishes by verifying you — so you see the whole flow work before you put it in front of an engineer.