Request a demo

Microsoft Entra Verified ID was built for identity verification.

Authentication factors help establish account control. Verified ID lets an employee present trusted identity evidence when a workflow needs to verify who they are.

By Fctr Identity 5 minute read

Microsoft Entra ID already gives organizations strong ways to authenticate employees. Microsoft Entra Verified ID answers a different question: how can someone present trusted evidence of who they are to a verification workflow?

That distinction matters whenever a helpdesk needs to establish identity before a sensitive support interaction. An authenticator push, one-time code, or passkey helps establish control of an authenticator bound to an account. Verified ID was designed to present trusted identity evidence.

What is Microsoft Entra Verified ID?

Verified ID is Microsoft's managed service for issuing and verifying digital credentials. Its model has three participants:

  1. An issuer creates a trusted credential. An employer, for example, can issue a VerifiedEmployee credential.
  2. The employee holds that credential in a compatible digital wallet such as Microsoft Authenticator.
  3. A verifier requests the credential and checks its issuer, type, validity, and the claims needed for the interaction.

The employee sees the request and chooses whether to present the credential. The verifier receives cryptographically verifiable evidence from an approved issuer instead of asking the employee to repeat personal information over the phone.

Why is Verified ID better suited to identity verification?

The simplest way I explain the difference is this:

An authentication factor helps prove control of an authenticator. A Verified ID presentation provides identity evidence from an issuer the organization trusts.

That gives an identity-verification workflow four useful properties:

  • Trusted issuer: the verifier defines which organization may issue the credential.
  • Relevant claims: the workflow requests the approved credential and information needed for that decision.
  • User-held evidence: the employee participates in a fresh presentation and chooses to share the credential.
  • Separation from application sign-in: Microsoft states that Verified ID does not itself satisfy Entra sign-in, MFA, or self-service password-reset requirements.

That last point is an advantage, not a limitation. The employee can complete an identity-verification exchange without using that exchange to create another Microsoft 365 session. The result belongs to the verification workflow.

What does Face Check add?

Face Check is an optional higher-assurance capability for Verified ID. It compares a real-time selfie with a trusted photo contained in the credential being presented.

Microsoft performs the comparison and returns the result to the requesting application. According to Microsoft's documentation, the verifier does not receive the captured selfie. An organization can therefore add a live-person check without turning the helpdesk into a collector of biometric images.

The organization decides when to require it. A standard workflow may request the approved credential. A higher-assurance workflow may request the credential and Face Check together.

Why can it be practical for Microsoft environments?

Verified ID can be more practical and cost-accessible than many Microsoft customers assume. It is part of the Entra platform, and Microsoft includes baseline Verified ID usage with Entra subscriptions. Face Check is available through Microsoft Entra Suite or consumption-based billing. Because allowances and pricing can change, teams should review Microsoft's current Verified ID pricing rather than rely on a number copied into an article.

Microsoft also provides a direct evaluation path:

  1. Set up Verified ID in the Entra tenant.
  2. Choose who can receive a VerifiedEmployee credential.
  3. Issue the credential through MyAccount and hold it in Microsoft Authenticator.
  4. Enable Face Check when the use case requires it.
  5. Connect the presentation request to the verification workflow.

Microsoft provides a test application for the credential and Face Check experience, and it documents an inline Get Verified pattern for service-desk applications. Organizations still choose their issuer, users, claims, assurance policy, and production workflow, but they do not have to invent a new identity-verification protocol to begin.

How does Fctr help?

This is why we added Microsoft Entra Verified ID with Face Check to Fctr. The useful outcome is not another standalone technology demonstration. It is seeing Verified ID work inside a support process.

Fctr gives the helpdesk one place to select the employee, initiate the organization-approved verification method, receive the result, and keep that evidence connected to the support interaction. A customer can continue using its existing supported authentication methods for ordinary verification and choose Verified ID when the workflow calls for identity-specific or higher-assurance evidence.

The verification result then stays connected to the support workflow. The organization's role and policy determine what the operator may do after identity is established.

You do not need to deploy Verified ID before you can start with Fctr. Start with the supported factors your organization already manages. When you want to add Microsoft Entra Verified ID and Face Check for identity-specific or higher-assurance workflows, Fctr already supports that verification method too.

If your team wants to see both approaches in a real helpdesk flow, talk with the Fctr team. We are happy to walk through:

  • what Verified ID and Face Check do;
  • the Microsoft setup and evaluation path;
  • which verification use cases may fit your environment; and
  • how Fctr uses Verified ID in a governed helpdesk workflow.

You can see the credential presented, the identity result returned, and the verification used in a workflow your support team already understands.

Sources