Prove someone works for you without the other organisation ever calling you to check.
Verified ID issues cryptographically signed credentials that a person holds in their own wallet and presents to whoever needs them. Microsoft states the point plainly: the credential is portable, cryptographically signed proof the holder can present to any verifier without that verifier needing to contact the issuer or any central authority.
- Three rolesIssuer, holder, verifier
- did:webThe supported trust system, generally available
- Open standardsW3C DIDs and Verifiable Credentials
- AuthenticatorThe wallet people already have
Seven things to understand before deciding whether this fits your problem.
Three roles, and only one of them is you at any moment
The issuer creates and signs credentials about a subject. The user, or holder, keeps the credential and chooses when to present it. The verifier requests a credential and validates it against the public key in the decentralized public key infrastructure. Most organisations are an issuer for one use case and a verifier for a different one, and the two projects look nothing alike.
The verifier never has to contact you
Microsoft states this directly in a published note: the credential is portable, cryptographically signed proof that can later be presented to any verifier without the verifier needing to contact the issuer or any central authority. That is the whole value proposition. It removes the phone call, the email chain and the reference letter from every verification you currently field.
did:web, which means your domain is the trust anchor
Microsoft states it currently supports the did:web trust system, describing it as a permission-based model that allows trust using a web domain existing reputation, and that the method is generally available. That is worth knowing because it removes the objection people arrive with. Verified ID does not require a blockchain, it uses the reputation of a domain you already control.
Microsoft Authenticator is the wallet, which people already have
Microsoft describes Authenticator creating decentralized identifiers, facilitating issuance and presentation requests, and managing backup of the identifier seed through an encrypted wallet file. Adoption is materially easier when the wallet is an application your workforce already installed for multifactor authentication rather than something new to roll out.
Issuance still starts with normal authentication
Microsoft is careful about this and so are we. In the published flow the employee signs in with a username and password through Authenticator, which passes an ID token to the issuing service, and once that token is validated the credential is created and signed with the issuer identifier. The sign-in step is traditional authentication and is separate from the credential itself.
Presentation happens over open standards, often by QR code
The verifier uses open standards such as Self-Issued OpenID Provider and Presentation Exchange to request credentials. The published example is a website link with a QR code the person scans with their phone camera, which initiates a request for a specific credential that Authenticator analyses before giving the person the option to approve.
The holder keeps a record of every presentation
Microsoft notes that the transaction is logged in the holder wallet application, and that log entries help the holder track where and to whom they presented a credential. That is a genuine privacy property rather than a marketing one, and it is worth surfacing in any internal discussion about whether this is more or less intrusive than the process it replaces.
No, this does not require a blockchain.
Almost every first conversation about Verified ID stalls on this, and the published answer settles it in one paragraph.
- Microsoft states that it currently supports the did:web trust system, and describes it as a permission-based model that allows trust using a web domain existing reputation. The did:web method is generally available.
- In practice that means the trust anchor is a domain your organisation already owns and already controls, published through the well known DID configuration mechanism. There is no distributed ledger to run, join or pay for.
- The standards implemented are published and open: W3C Decentralized Identifiers, W3C Verifiable Credentials, and several Decentralized Identity Foundation specifications including Sidetree, Well Known DID Configuration, DID-SIOP and Presentation Exchange.
- That matters commercially as well as technically. A credential built on open standards can be verified by an organisation that does not use Microsoft, which is what makes the model useful outside your own tenant in the first place.
Four things that keep a Verified ID project from becoming a demo nobody uses.
We start from a verification that already happens and costs you
Employment confirmations, contractor onboarding, membership checks, alumni status. If your organisation already answers a recurring verification request by hand, that is the use case with a measurable before and after. Starting from the technology rather than from an existing cost is how these projects end as pilots.
We design the claim set to be as small as it can be
A credential proving employment does not need a job title, a department, a start date and an employee number unless the verifier genuinely uses them. Fewer claims means a smaller privacy footprint, a simpler schema and a credential that stays valid longer. It also makes the internal approval conversation considerably shorter.
We design expiry and revocation before issuance
A portable credential that a verifier can check without contacting you is powerful precisely because it works offline from your systems, which means the lifecycle has to be designed into the credential rather than enforced by a lookup. Validity periods, reissuance and what happens when somebody leaves are decisions taken at the schema stage.
We settle the trust system question in the first meeting
Microsoft supports the did:web trust system, which uses your existing web domain reputation and is generally available. Getting that on the table immediately removes the blockchain objection that otherwise consumes the first two meetings, and it reframes the project as a use of a domain you already control.
Six UAE situations where portable credentials solve a real problem.
Contractor and vendor onboarding at scale
A main contractor verifying that a subcontractor engineer holds a current certification, works for whom they claim, and has completed the required induction. Today that is a folder of PDFs checked by a coordinator. As credentials it is a scan at the gate, verified cryptographically, with no call to the employing company.
A firm that fields constant employment verification requests
Banks, landlords, visa processes and background screeners all ask employers to confirm employment. Microsoft published scenario is exactly this shape: the employer issues proof of employment, the employee holds it, and a third party accepts it. Every request answered that way is a request your HR team never sees.
An institution issuing credentials to alumni
Degrees, diplomas and professional qualifications are verified by employers constantly and forged regularly. A signed credential in the graduate own wallet, presentable to any employer without the institution being contacted, addresses both problems at once, and the graduate keeps a log of where they presented it.
Verifying clinical or professional licensure
Locum staff, visiting specialists and agency clinicians all arrive with credentials somebody has to check. A verifiable credential issued by whoever holds the authoritative record turns that check into a scan, and because verification does not require contacting the issuer, it works outside office hours and across time zones.
Site access based on training and certification
Safety inductions, equipment certifications and permits to work are all attributes that expire and that gatekeepers currently verify from a list. Credentials with designed validity periods, presented at the gate by QR code, make the check verifiable rather than administrative, which is the difference on the day something goes wrong.
A group that wants to accept credentials rather than issue them
The verifier side is often the easier starting point and is frequently overlooked. Microsoft notes a verifier can use open standards to perform presentation and verification, or configure their own Entra tenant and let the Verified ID service do most of the work. For organisations receiving credentials from partners, that second option is a short project.
How organisations prove attributes about people today.
| Feature | Verifiable credentials | Letters, PDFs and phone calls | A directory account only |
|---|---|---|---|
Works outside your directory | Yes | Yes | No |
Cryptographically verifiable | Yes | No | Yes, but only in your tenant |
Verifier can check without contacting you | Yes | No | No |
Holder controls what is shared | Yes | No | No |
Holder sees where it was presented | Yes | No | No |
Forgery resistance | High | Low | Not applicable |
Effort per verification | None | High | Not applicable |
Built on open standards | Yes | Not applicable | Partly |
Requires the verifier to use Microsoft | No | Not applicable | Yes |
Scales to partners and the public | Yes | Poorly | No |
Five pieces, and what each is responsible for.
| Component | What Microsoft says it does | What it means for you | |
|---|---|---|---|
| W3C Decentralized Identifiers | Identifiers users create, own and control independently of any organisation or government, linked to decentralized public key infrastructure metadata | The identifier is not issued by you and cannot be revoked by you, which is the point | |
| Trust system | did:web, a permission-based model using a web domain existing reputation, generally available | Your domain is the trust anchor, so no ledger and no new infrastructure | |
| Wallet, Microsoft Authenticator | Creates identifiers, facilitates issuance and presentation requests, manages backup of the identifier seed in an encrypted wallet file | Most of your workforce already has it installed for multifactor authentication | |
| Microsoft Resolver | An API that looks up and resolves identifiers using did:web and returns the DID Document Object with public keys and service endpoints | How a verifier finds your public key without contacting you | |
| Entra Verified ID Service | An issuance and verification service in Azure with a REST API for W3C Verifiable Credentials signed with did:web | Where your issuance and verification solutions are built, or which does most of the work for you |
Five steps, and the adoption question is answered before the build.
- 1
Pick a verification that already costs you something
We look for a recurring request your organisation answers by hand today, with a measurable volume and a named team absorbing it. That gives the project a before and after rather than a demonstration, and it identifies the verifier population, which is the part that determines success.
- 2
Establish your role and your trust anchor
Issuer, verifier, or both, since they are different projects. Then the domain that anchors your decentralized identifier, since Microsoft supports the did:web trust system, which uses a web domain existing reputation and is generally available. This is also where the blockchain question gets settled permanently.
- 3
Design the schema, the lifecycle and the experience
The smallest claim set that satisfies the verifier. Validity period, reissuance and revocation designed in, because a portable credential is verified without contacting you. Then the issuance trigger, where sign-in passes an ID token to the issuing service, and the presentation trigger, typically a link or QR code.
- 4
Build issuance and verification, and test both sides
Using the Verified ID service in Azure and its REST API, with Authenticator as the wallet. Verification is tested from the other side of the transaction, including the case where the verifier is not a Microsoft customer, since open standards such as Self-Issued OpenID Provider and Presentation Exchange are what make that possible.
- 5
Run a real pilot with a real verifier
A credential nobody accepts has no value, so the pilot includes the accepting party from the start rather than after the build. We also establish the support path for holders, because lost phones, reinstalled applications and wallet backup questions all arrive in the first month.
What organisations ask about Entra Verified ID.
Fifteen questions that decide whether Verified ID is the right tool.
The problem
- Who currently verifies this, and how?Usually a phone call or a PDF.
- How often does that happen?Volume is what makes the case.
- Is the verifier outside your directory?If not, use conditional access instead.
- Would the holder benefit from portability?That is the model core advantage.
- What happens today when a claim is faked?The current failure cost sets the value.
Your role
- Are you the issuer, the verifier, or both?Two different projects.
- Which domain anchors your identifier?did:web uses your domain reputation.
- What claims go in the credential?Fewer is better and more private.
- How long should a credential be valid?Expiry design matters as much as issuance.
- What happens when someone leaves?Revocation has to be designed, not assumed.
The experience
- Does your population have Authenticator?Most workforces already do.
- How is issuance triggered?Sign in passes an ID token to the issuing service.
- How is presentation triggered?A link or QR code is the published pattern.
- What happens if a phone is lost?The wallet backs up an encrypted seed file.
- Who supports the holder when it fails?Somebody has to, on day one.
The pages around this one.
Entra ID Governance
The internal side of identity lifecycle, where most access decisions still belong.
Entra entitlement management
How external partners get access to your resources, as distinct from proving attributes.
Passwordless authentication
The other Entra project that depends on Authenticator adoption.
Name one verification your team answers by hand every week.
That is the use case. Employment confirmations, certification checks, membership status, contractor onboarding. If somebody in your organisation currently picks up the phone to confirm it, a credential can replace the call entirely.
Related Services
Explore more solutions that work great with this service
Entra ID Governance
Joiner mover leaver, access packages and guests that expire on their own
Entra Entitlement Management
Access packages that expire on their own
Passwordless and Passkeys
Three seconds instead of sixty nine, and it cannot be phished
Entra Conditional Access
The control that decides who reaches your data
Microsoft Entra
Identity and access management solutions
SSO Solutions
Single sign-on across all SaaS apps
MFA Solutions
Entra MFA, passwordless, FIDO2
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own