What we can see, and what we cannot.
You are being asked to grant a third-party application access to your directory. Here is the whole picture, including the parts that are inconvenient for us.
Credentials, factors and session material.
No password, ever
Authentication happens on Microsoft's own sign-in pages, in the user's browser. We receive an identity token afterwards, and nothing before it.
No authenticator, no seed, no device registration
Your users enrol nothing with us. They use the factors they already have. If you stop using Proofcall tomorrow, there is nothing to unwind on their devices.
No standing ability to change your Conditional Access
Setup needs policy write access. We take it as a delegated permission belonging to the administrator running setup, so it lives as long as their session does. The application itself never holds it.
Short-lived by design.
The verification session
Who was to be verified, who asked, and the outcome. Expires by default in minutes, and is swept continuously.
The code, as an HMAC
Never stored in the clear, compared in constant time, and deleted the moment the verification succeeds or fails.
The audit record
What was proven, by what method, at what time, driven by whom. This is the part you keep, and the part an insurer will ask for.
Things we are asked for and will not build.
Showing the code to the engineer
Proposed regularly as a troubleshooting aid. It inverts the control: an engineer who can see the code can read it to a caller, and a caller who has talked their way past the desk is handed the answer. There is no screen and no API field.
An approve/deny push as the primary flow
It proves reachability and habit, not identity. Microsoft's own NPS extension moved away from approve/deny for the same reason.
Letting a failed verification look like a pass
A refusal is a refusal. Vouching is labelled as vouching everywhere it appears, including in exports, because the weaker claim is the one that gets skim-read as the stronger.
Send-as permission in your tenant
Verification emails come from one mailbox we control, not from inside your estate. The alternative would need permission to send as any of your users, which is too much power to hold for slightly better deliverability.
Microsoft Entra ID P1.
Conditional Access is a P1 feature. Without it there is no authentication context, no policy, and no way to demand fresh multi-factor authentication on request — so the product cannot work. Setup checks your licensing before it changes anything and tells you straight away if this is a blocker.
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.