A code that cannot exist unless the authentication passed.
Proofcall does not evaluate your users' credentials. It asks Microsoft a question that can only be answered by a successful multi-factor authentication, and reads the answer.
Two objects in your directory.
Setup creates a Conditional Access authentication context and a single policy bound to it. Both are visible in your own portal, and both are yours.
An authentication context
A label — c1 — that an application can ask for. On its own it does nothing at all.
One policy bound to that context
Require multi-factor authentication, every time, with sign-in frequency set so no existing session is accepted. It is scoped to the context and to nothing else.
This policy cannot lock anyone out. A policy scoped to an authentication context is evaluated only when an application explicitly asks for that context. Nothing else in your estate does. It cannot affect Outlook, Teams, SharePoint, VPN or any normal sign-in, and there is no path by which it denies access to anything.
Five things must be true before a code is issued.
Microsoft verifies the token's signature, issuer and audience. These are the authorisation decisions applied on top, and every one of them closes a specific attack.
nonce
The token was minted for this verification, not replayed from a previous one.
tid
The person signed in to the expected tenant, not one an attacker controls.
oid
They authenticated as themselves, not merely as somebody valid. Without this check, anyone with an account in the tenant could pass MFA and be verified as the finance director.
acrs
The Conditional Access policy actually ran. Absent this, a routine single-factor sign-in would satisfy the flow.
auth_time
The authentication happened seconds ago, on this call — not days ago in a session the browser still had open.
Then, and only then
A six-digit code is issued to the caller's browser. It is stored only as an HMAC, compared in constant time, and burned on first use or failure.
Evidence, not an assertion.
Every verification records which method was used, when the authentication happened, whether it was phishing-resistant, and whether a human or an automated agent drove it. Attribution is a fixed field — there is no anonymous verification.
Method, named
"Windows Hello at 14:32" is a stronger thing to read back to an auditor than "verified". Where Entra reports the method, the record names it.
Human or agent, always
An AI service desk agent can drive the flow. Whether it did is recorded in the same position in every view and every export, permanently.
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.