Microsoft Entra Verified ID: Set Up, Secure and Use Workplace Credentials

Help desks still reset passwords and MFA for whoever sounds convincing on the phone, and Microsoft Entra Verified ID is Microsoft's answer to proving who the caller really is. Verified ID lets an Entra tenant issue W3C verifiable credentials, such as the built-in VerifiedEmployee workplace credential, to a user's Microsoft Authenticator wallet, and lets an application or service desk ask for that credential back, optionally with a Face Check selfie match. This guide covers how the service is set up, which roles and app permissions control it, how revocation and signing keys work, what is and is not logged, and the configuration choices that keep a strong verification step strong. It is written for Entra administrators, identity architects and service desk owners. For the vendor-neutral model behind it, see the Verifiable Credentials Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Quick setup is the default path and uses a Microsoft-managed, shared regional signing key, a did:web identifier hosted by Microsoft, a two requests per second limit and a maximum credential validity of six months.
• The verifier decides the security level. acceptedIssuers, allowRevoked and validateLinkedDomain are request settings, and validateLinkedDomain defaults to false, so a relying party that copies a sample can accept credentials from an unverified domain.
• Face Check binds the credential to a live face with a configurable confidence threshold of 50 to 100 (default 70); the verifier receives only the score, and the selfie is discarded.
• Revocation only works if you planned it: exactly one claim can be indexed, and a credential type with no indexed claim cannot be revoked.
• Logging is thin. The Entra audit log records Admin API management changes, not issuance or presentation, so the verifying application must log every verification itself.

How identity and access work in Microsoft Entra Verified ID

Verified ID turns the tenant into a credential issuer (an "authority" with a decentralised identifier), the user's Microsoft Authenticator into a holder wallet, and any application that calls the Request Service API into a verifier. The issuer signs credentials as JWT-VCs; the verifier checks the signature against the public keys in the issuer's DID document, checks revocation status, and optionally checks that the DID is linked to a domain the issuer controls. Background on DIDs is in the Decentralised identifiers (DIDs) guide.

Supported standards

Quick setup versus advanced setup

Decision guidance: quick setup suits most workforce scenarios, especially help desk verification and MyAccount issuance, because it removes key custody and DID hosting. Choose advanced setup when you need credentials valid longer than six months, throughput above two requests per second, control over the signing key lifecycle for audit reasons, or a DID on a domain you host. Smaller organisations should rarely take on Key Vault custody just for Verified ID.

Issuance paths

• MyAccount: after quick setup, users sign in to myaccount.microsoft.com and choose Get my Verified ID to issue themselves a VerifiedEmployee credential. Admins can remove the option or restrict it to selected groups; changes take some minutes to apply. MyAccount uses the user's Entra profile photo, which becomes the reference image for Face Check.
• Custom issuance: an app calls the Request Service API with an idTokenHint or ID token attestation, for custom credential types including a photo claim (display type image/jpg;base64url).
• Identity verification partners: an IDV provider proofs a new hire against a government document and issues a credential that your onboarding flow consumes; see the Identity Proofing and KYC Guide.

Face Check and help desk recovery

Face Check compares a real-time selfie captured in Microsoft Authenticator with the photo in the presented credential, using Azure AI Vision Face API detection, match and liveness. Microsoft documents that at a threshold of 50 the chance that the person in the selfie is not the credential owner is one in 100,000, and at 90 it is one in a billion; higher thresholds reject more genuine users. The selfie is discarded after processing and is not shared with the verifier, which receives the confidence score and a signed MicrosoftFaceCheckReceipt. Face Check works only with Microsoft Authenticator, which Microsoft states is a control against injection attacks.

Microsoft's "verified helpdesk" pattern addresses total loss recovery: the caller has lost every authenticator, the service desk sends a presentation request for VerifiedEmployee with Face Check, and on success an automation issues a Temporary Access Pass so the user can register new methods. Process design for the desk itself is in the Account Recovery and Help Desk Security Guide and the Help Desk Identity Verification Policy Template.

Limitation to plan around: a user who lost the phone has also lost the wallet. Total loss recovery with Verified ID therefore needs the user to reinstall Authenticator and obtain a credential again through a path that does not depend on the lost authenticators, typically an IDV partner credential or in-person verification for privileged staff.

Admin roles and privileged access

The signing key is the crown jewel of an advanced setup authority. Because the Key Vault must use the Access Policy model rather than Azure RBAC, review its access policies separately from your usual RBAC reviews, enable soft delete and purge protection, and restrict network access. See the Azure RBAC and Service Principals Guide and the Entra ID Security Guide for tenant-wide role hardening.

Integrations, API tokens and service accounts

Every issuer, verifier and admin automation is an application identity with its own credential, and these are the non-human identities most often left over-permissioned.

• Split issuance from verification: a help desk verifier needs only PresentRequest. Granting Create.All lets a compromised verifier app issue credentials too.
• Use certificates or managed identities for the client credentials flow instead of client secrets; see the Entra Client Secrets Security Guide.
• Protect the callback: the Request Service posts results to an internet-reachable callback URL and supports only an api-key or Authorization header. Generate a high-entropy value, check it on every callback, and correlate callbacks to the original requestId and state so a forged callback cannot mark a caller as verified.
• Help desk automations that issue a Temporary Access Pass hold Graph permissions to manage authentication methods. That app is effectively an MFA reset tool: scope it tightly, alert on its use and keep its credential in a vault.

Logging and detection

Microsoft's release notes state that Verified ID reports events in the Entra audit log for management changes made via the Admin API, and that issuance and presentation are not logged there. Detection therefore splits into two layers.

• Entra audit log: alert on authority creation, credential definition changes, MyAccount issuance scope changes, and revocation calls. Correlate with PIM activations of Authentication Policy Administrator.
• Verifier application log (yours to build): for every presentation record requestId, credential type, issuer DID, Face Check score, threshold, outcome, the help desk agent and ticket, and any follow-on action such as TAP issuance. Microsoft's planning guidance recommends capturing every validation attempt with unique transaction identifiers.
• Sign-in and audit for app identities: service principal sign-ins for issuer, verifier and TAP automation apps, and Graph audit events for Temporary Access Pass creation. See the Entra ID Sign-in Log Detection Guide.

Metrics:

• Percentage of help desk credential resets preceded by a successful Verified ID presentation (target near 100 percent for MFA and password resets).
• Face Check failure rate by threshold, and how many failures escalated to a fallback process.
• Time from leaver event to credential revocation.
• Number of app registrations holding Create.All or Admin API permissions (target: only those justified).
• Repeated failed verifications against the same identity in 24 hours (an indicator of an impersonation attempt).

Hardening baseline

1. Plan: decide quick or advanced setup, the credential types you need, the claim to index for revocation, and the Face Check threshold per scenario (for example 70 for general staff, higher for admin account recovery).
2. Pilot: run quick setup, restrict MyAccount issuance to a pilot group, and test the public test app flow before wiring the service desk.
3. Integrate: build the verifier with acceptedIssuers set to your own authority DID, allowRevoked false, validateLinkedDomain true and an explicit matchConfidenceThreshold.
4. Automate lifecycle: connect leaver events to the Admin API search and revoke calls, and if users obtain credentials through MyAccount, make sure the leaver process also disables the account so no new credential can be issued.
5. Expand: roll MyAccount issuance out by group, then make Verified ID mandatory for help desk resets of privileged and then all accounts.
6. Roll back: keep the previous help desk verification procedure documented as a fallback during the pilot; removing the MyAccount option or the verifier step reverts behaviour without touching the tenant. Opting out of Verified ID is one way: it deletes credential contracts and soft deletes keys, so never use it as a rollback.

Common misconfigurations

• validateLinkedDomain left at false: the default accepts credentials from issuers whose linked domain is unverified. Set it to true and pin acceptedIssuers.
• No acceptedIssuers on a VerifiedEmployee request: acceptedIssuers is optional, and leaving it out means the request does not restrict which issuer's credential of that type is accepted, while any organisation can set up Verified ID and issue its own VerifiedEmployee credentials. MSPs verifying several customers should list each customer's authority DID.
• Stale or weak profile photos: Face Check is only as good as the reference photo. If users can change their own Entra profile photo, an attacker with a session can swap it before obtaining a credential. Restrict photo updates and set photos from a trusted HR source.
• Credential types with no indexed claim: they can never be revoked; leavers keep a valid credential until it expires.
• Verification without a downstream control: a green result that an agent can ignore, or a TAP issued without recording the verification ID, gives no assurance.
• Over-scoped app permissions and client secrets on verifier and TAP automation apps, or a callback endpoint that does not check its header.

Framework mapping

Practitioner checklist

• Choose quick or advanced setup against the six-month validity and two requests per second limits.
• Make Authentication Policy Administrator PIM eligible and limit it to a small named group.
• Restrict MyAccount issuance to defined groups and control who can change profile photos.
• Index one claim on every custom credential type so it can be revoked, and wire revocation to leaver events.
• Set acceptedIssuers, allowRevoked false, validateLinkedDomain true and an explicit Face Check threshold in every verifier.
• Grant verifier apps PresentRequest only, use certificate credentials, and check the callback header and requestId.
• Log every presentation, score and resulting TAP or reset in the verifier, and forward it to the SIEM.
• Alert on Admin API changes in the Entra audit log and on TAP creation by automation apps.
• Design a total loss path for users who lost both phone and wallet.

Standards and references

• Microsoft Learn: Quick Microsoft Entra Verified ID setup
• Microsoft Learn: Use Face Check with Microsoft Entra Verified ID
• Microsoft Learn: Verified helpdesk with Microsoft Entra Verified ID
• Microsoft Learn: Revoke a verifiable credential
• Microsoft Learn: Microsoft Entra Verified ID Admin API
• Microsoft Learn: Request Service REST API presentation specification
• Microsoft Learn: Microsoft Entra Verified ID supported standards
• W3C: Verifiable Credentials Data Model

Related NHI Mgmt Group resources: Verifiable Credentials Guide · Account Recovery and Help Desk Security Guide · Help Desk Social Engineering Incident Playbook · Entra ID Security Guide