A clear account of what gets verified.

What a successful direct check establishes.

The expected Microsoft account satisfied the requested authentication context, and the handler submitted the Proofcall code issued after that authentication. The evidence includes the account, tenant, authentication time and available method information.

This verifies account control. It does not establish legal identity, detect synthetic speech or prevent every form of social engineering. A compromised account or someone persuaded to relay a code remains part of the threat model.

Five checks before issuing a code.

• Request binding: the nonce matches the verification session.
• Organisation: the tenant matches the expected organisation.
• Account: the Entra object ID matches the expected person.
• Authentication context: the required context appears in the returned claims.
• Authentication age: the authentication timestamp is within the configured window.

Proofcall requests reauthentication. The exact prompt experience depends on Microsoft’s session rules, the tenant’s policies and the method used.

Passwords and authenticator secrets stay with Microsoft.

Callers sign in through their identity provider. Proofcall does not ask them to register a new factor, hand over their password or reveal their Microsoft Authenticator code.

The separate Proofcall code is stored as a session-bound HMAC. Verification sessions and codes have expiry windows and submission-attempt limits.

Directory access has a defined purpose.

Normal operation uses read access to resolve callers, check available authentication methods, inspect organisation licensing and check the verification policy. Onboarding uses delegated administrator permissions to configure the authentication context and Conditional Access policy.

Review the policy in your own tenant.

The verification policy is designed to target its authentication context. That is a narrower scope than applying a new requirement to every ordinary Microsoft 365 sign-in. Your administrator should review the resulting policy and test the intended workflow.

Evidence and recovery are distinct.

Verification events record the outcome and the initiating human or agent. Audit history and exports help your team review activity. Authoritative audit retention should be configured for your deployment and retention requirements.

When a colleague authenticates for someone who cannot, the result is an approver attestation. It is labelled separately from direct verification and should be evaluated under your organisation’s recovery policy.