Microsoft Entra Verified ID: Issuance Architecture

Verified ID Entra Entra ID Verified ID Face Check Verifiable Credentials

This guide helps IT architects evaluate Microsoft Entra Verified ID issuance models in terms of trust, revocation, and operational responsibility. It focuses on the practical decision between third-party IDV-issued credentials and organization-issued credentials, and where each model fits best.

What Is Verified ID?

Microsoft Entra Verified ID is a managed verifiable credential (VC) service built on W3C and DIF open standards. A verifiable credential is a cryptographically signed digital claim issued by a trusted authority, stored in the holder's wallet, and presented to verifiers without involving the issuer in the transaction. The verifier checks the credential against the issuer's public key and, where applicable, checks revocation status without requiring the issuer to participate in each presentation. Microsoft Authenticator is the primary wallet for Microsoft-delivered flows and is currently required for Face Check. The underlying standards support any conformant wallet, but real-world interoperability still varies by scenario.

Verified ID Issuance Models: IDV vs. Self-Issuance

Verified ID supports two issuance models. Both can involve third-party identity verification. The key distinction is not whether proofing occurs. It is who signs the resulting credential, which determines trust portability, data liability, revocation control, and operational responsibility.

Dimension	IDV-issued credential	Org-issued credential
Issuer	Third-party identity verification provider such as AU10TIX, IDEMIA, Entrust, or Persona	Your organization through its own Verified ID authority
Trust Anchor	The IDV's issuer DID and reputation	Your organization's DID and onboarding process
Portability	Higher portability across employers, verifiers, and reuse scenarios	Usually strongest inside a known workforce or partner trust boundary
Revocation	Controlled by the IDV when the identity proofing itself is invalidated	Controlled directly by the organization for workforce lifecycle events
Data Liability	More raw identity evidence stays with the IDV	More assurance and evidence handling decisions stay with the organization
Best-fit Scenarios	Pre-employment proofing, account recovery, regulated onboarding, reusable identity	Workforce access, B2B trust inside known boundaries, immediate access termination

Third-Party IDV Partner Issuance

A specialist identity verification provider such as AU10TIX, IDEMIA, Entrust, or Persona acts as the issuing authority. The IDV performs document-grade proofing: government ID forensics, biometric selfie matching, liveness detection, and fraud analysis. After proofing, the IDV signs the credential with its own DID and delivers it to the holder's wallet.

Trust portability is the primary argument for this model. A verifier only needs to trust the IDV's did:web, a globally recognized issuer identity. Any verifier can technically validate the issuer DID and signature, but whether it accepts the credential depends on its trust policy and whether it recognizes that IDV as a trusted issuer. The IDV's reputation becomes the trust anchor, and that trust extends beyond any single organization.

Data liability stays with the IDV. The organization never receives government ID images or biometric captures, only the cryptographic attestation. IDV-as-issuer can materially reduce the organization's handling of raw identity and biometric evidence, which may simplify its data minimization and compliance posture depending on the integration design and contractual model.

Revocation is identity-centric. The credential survives employment changes; the IDV revokes only if the proofing itself is compromised. One verification can support later uses such as pre-employment, onboarding, account recovery, and KYC without repeated proofing.

Operational burden is minimal. Key management, DID hosting, revocation, and telemetry belong to the IDV. Security Store partners are zero-code to integrate; API-based partners require callback endpoints and token signing, but credential lifecycle management remains the IDV's responsibility.

Organization Self-Issuance

The organization configures its own Verified ID authority and signs credentials directly, sourcing claims from Entra ID directory data, backend systems, user input, or existing credentials via verifiable presentation attestation. The org's DID is the trust anchor.

Assurance inherits from the onboarding process. A VerifiedEmployee credential asserts "this person has an account in our directory." If the employee was onboarded without strong identity proofing, the credential's assurance may be far lower than its cryptographic protection suggests, regardless of the signing keys involved. Microsoft does not publish an official NIST IAL mapping for these patterns; any IAL framing should be treated as architectural analysis, not a Microsoft-backed classification. That is the proofing gap.

You can close that gap intentionally. The presentations attestation type lets the org require presentation of an IDV-issued credential before issuing its own credential, binding employment claims to a verified identity root. IDV proofing establishes who the person is; org issuance establishes what their relationship to the organization is. Together, the two steps support a broader assurance model.

The organization is the trust anchor. For internal access gating and B2B scenarios within a known trust boundary, that's sufficient. For external-facing scenarios, the credential may not be accepted without due diligence on the org's proofing practices.

Revocation is fully org-controlled. Termination immediately invalidates access, with no external dependency.

Issuance and verification are free. The Verified ID platform includes 50,000 transactions per month at no cost, with no per-credential fee and no per-verification charge, according to the Microsoft Entra Verified ID pricing page. For organizations already on Microsoft 365 E3, there is no incremental platform cost at all.

The Flows, Side by Side

The diagram below maps both models across Initiate, Proof, Issue, and Access phases. Orange steps are IDV-controlled, green are org-controlled, and purple marks holder verification at presentation time. The proofing gap note matters because the IDV step is optional in the right column. Without it, the org VC inherits only the assurance of the existing HR process.

Architecture overview showing browser, identity provider, and API trust flow

Identity Proofing vs. Holder Verification: The Critical Distinction

Identity proofing occurs at issuance time: Is this person who they claim to be? Document forensics, biometric matching, liveness detection. The outcome is a credential representing a verified real-world identity.

Holder verification occurs at presentation time: Is the presenter the same person the credential was issued to? It does not establish identity again; it confirms that the current presenter is the same person tied to the existing credential. Face Check is the platform's mechanism for this.

Holder verification without identity proofing provides no protection against credentials issued to unverified identities. Identity proofing without holder verification provides no protection against credential theft or transfer. A robust deployment addresses both.

Face Check Is Holder Verification, Not Identity Proofing

Face Check performs a one-to-one biometric match between a live selfie and the photo embedded in the credential. Azure AI Face handles liveness detection. Microsoft describes it as iBeta Level 2 conformant. The service returns only a confidence score to the verifier, never the selfie, photo, or biometric template. No biometric data is retained after processing.

What Face Check confirms: The presenter matches the credential photo. What it does not confirm: The validity of the original proofing or the presenter's legal identity.

Organizations relying on directory-sourced photos (as with VerifiedEmployee credentials) need profile photos populated in Entra ID before Face Check can be used. Custom credentials can also supply the photo claim directly at issuance time.

Face Check billing triggers when Azure AI processing completes, regardless of whether the match succeeds or fails. No charge is incurred if the flow fails before processing reaches Azure AI, such as QR code errors, user abandonment, or service errors. For organizations with high presentation volumes, the Entra Suite license ($12/user/month) includes 8 Face Checks per user per month pooled at the tenant level, with $0.25 per check for overages, as documented on the Microsoft Entra Verified ID pricing page. That can change the cost calculus significantly compared to pure pay-as-you-go.

Security Store Integration: The Low-Code Path

Security Store partners such as AU10TIX, IDEMIA, and LexisNexis/TrueCredential integrate through the Entra admin portal without custom API work. An administrator selects the provider, procures through the Microsoft Security Store (Azure subscription required), and activates. Microsoft orchestrates the cryptographic exchange.

Pricing: At the time of writing, AU10TIX charges a flat $1.00 per transaction on its Microsoft Security Store listing: successful ID verifications, failed ID verifications, and VC presentations each incur the same rate. Fraud rejections still bill because the IDV completed its work. The free trial includes 100 transactions of each type; pay-as-you-go applies from transaction 101. VC presentations are billed independently from issuance, so verification-heavy workflows accumulate per-presentation cost. API-based partners outside the Security Store negotiate pricing directly; rates vary by volume, geography, and contract terms. Always confirm current rates before sizing any deployment. Security Store purchases are eligible for Microsoft Azure Consumption Commitment (MACC) drawdown.

Both product experiences that currently embed this path, Account Recovery and Entitlement Management Access Packages, are in public preview and subject to change according to Microsoft's account recovery overview and integration guidance for IDV partners. Account Recovery covers lost-auth-method recovery via IDV proofing, Face Check, and Temporary Access Pass issuance. Entitlement Management gates access requests on presentation of a trusted issuer's credential. Custom workflows or non-Security Store partners require the API-based integration path.

Summary

The two issuance models are complementary, not competing. IDV-as-issuer delivers trust portability, data minimization, and identity persistence. It is a better fit for pre-employment proofing, account recovery, regulated contexts, and scenarios where the verifier has no prior relationship with the organization. Org-as-issuer delivers full lifecycle control, immediate revocation, and tight integration with internal systems. It fits workforce credentials within a known trust boundary especially well.

The strongest deployments combine both: an IDV-issued identity credential as a long-lived root of trust, an org-issued relationship credential chained from it for employment-specific claims, and Face Check for biometric holder binding at presentation time. Each layer answers a different security question while keeping trust, liability, revocation, and operational responsibility clearly separated.