Prove someone works for you without the other organization ever calling you to check.
What this issues is a cryptographically signed credential that a person keeps in their own wallet and presents to whoever needs to see it. The point is stated plainly in the documentation: that credential is portable, cryptographically signed proof, and the holder can present it to any verifier without that verifier having to contact the issuer or any central authority at all.
- Three rolesIssuer, holder, verifier
- did:webThe supported trust system, generally available
- Open standardsW3C DIDs and Verifiable Credentials
- AuthenticatorThe wallet people already have
Seven things worth understanding before deciding whether this fits the problem you have.
Three roles exist, and you occupy only one of them at any given moment
An issuer creates and signs a credential about a subject. The holder, meaning the person themselves, keeps that credential and decides when to present it. A verifier requests the credential and validates it against the public key held in the decentralized public key infrastructure. Most businesses turn out to be an issuer for one use case and a verifier for an entirely different one, and those two projects look nothing like each other.
The verifier never has to contact you
A published note puts it directly: the credential is portable, cryptographically signed proof that can be presented later to any verifier, with no requirement for that verifier to contact the issuer or any central authority. That is the entire value proposition in one line. It removes the phone call, the email chain and the verification letter from every verification request your team currently fields.
It runs on did:web, which makes your own domain the trust anchor
The currently supported trust system is did:web, described as a permission-based model deriving trust from the existing reputation of a web domain, and the method is generally available. Knowing that removes the objection most people walk into the room holding. There is no blockchain requirement here. It uses the reputation of a domain you already own and control.
Microsoft Authenticator is the wallet, which people already have
Authenticator is described as creating the decentralized identifiers, facilitating both issuance and presentation requests, and managing backup of the identifier seed through an encrypted wallet file. Adoption gets considerably easier when the wallet is an application your workforce already installed for multifactor authentication, rather than something new you have to roll out and explain.
Issuance still starts with normal authentication
The documentation is careful on this point and so are we. In the published flow, the employee signs in with a username and password through Authenticator, which passes an ID token across to the issuing service, and once that token validates, the credential is created and signed with the issuer identifier. That sign-in step is traditional authentication and it sits separately from the credential itself.
Presentation happens over open standards, often by QR code
Requesting a credential relies on open standards, Self-Issued OpenID Provider and Presentation Exchange among them. The published example is a website link carrying a QR code that somebody scans with their phone camera. That scan initiates a request for a specific credential, which Authenticator analyzes before offering the person the option to approve it.
The holder keeps a record of every presentation
Each transaction is logged inside the holder wallet application, and those log entries help the holder track where and to whom they presented a credential. That is a genuine privacy property rather than a marketing claim, and it belongs in any internal discussion about whether this approach is more or less intrusive than whatever process it replaces.
No, this does not require a blockchain.
Nearly every opening conversation about this stalls on exactly that question, and the published answer settles it inside a single paragraph.
- The trust system currently supported is did:web, described as a permission-based model deriving trust from the existing reputation of a web domain. That method is generally available.
- In practical terms your trust anchor becomes a domain the business already owns and already controls, published through the well known DID configuration mechanism. No distributed ledger to run, none to join, and none to pay for.
- Every standard implemented is published and open. That means W3C Decentralized Identifiers, W3C Verifiable Credentials, and a number of Decentralized Identity Foundation specifications including Sidetree, Well Known DID Configuration, DID-SIOP and Presentation Exchange.
- That has commercial weight as well as technical weight. A credential built on open standards can be verified by a business running no Microsoft products at all, and that portability is the only reason this model is useful beyond your own tenant.
Four things that keep a Verified ID project from becoming a demo nobody uses.
We begin from a verification that already happens and already costs you money
Employment confirmations. Contractor onboarding. Membership checks. Alumni status. Wherever your business already answers a recurring verification request by hand, that is the use case carrying a measurable before and after. Starting from the technology instead of from an existing cost is exactly how these projects finish their lives as pilots.
The claim set gets designed as small as it can possibly be
A credential proving somebody is employed does not need to carry a job title, a department, a start date and an employee number unless the verifier genuinely uses every one of them. Fewer claims produce a smaller privacy footprint, a simpler schema, and a credential that stays valid for longer. It also makes the internal approval conversation dramatically shorter.
We design expiry and revocation before issuance
A portable credential a verifier can check without contacting you is powerful for exactly one reason: it works entirely offline from your systems. That same property means the lifecycle has to be designed into the credential rather than enforced by a lookup somewhere. Validity periods, reissuance, and what happens the day somebody leaves are all decisions taken at the schema stage rather than afterwards.
The trust system question gets settled in the first meeting
The supported trust system is did:web, which draws on the existing reputation of your web domain and is generally available. Putting that on the table immediately removes the blockchain objection that otherwise consumes the first two meetings entirely, and it reframes the project as making use of a domain you already control.
Six US situations where portable credentials solve a real problem.
Contractor and vendor onboarding at scale
Picture a general contractor checking that a subcontractor technician holds a current certification, works for the company they claim to, and has completed the required orientation. Today that means a folder of PDFs and a coordinator reading through them. As credentials it becomes a scan at the gate, verified cryptographically, with nobody calling the employing company at all.
A company that fields constant employment verification requests
Lenders, landlords and background screeners all approach employers asking them to confirm employment. The published scenario has precisely 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 has to see. Whether any given verifier chooses to accept credentials remains entirely their decision, which is exactly why the pilot has to include them from day one.
An institution issuing credentials to alumni
Degrees, diplomas and professional qualifications get verified by employers constantly and forged with depressing regularity. A signed credential sitting in the graduate own wallet, presentable to any employer with no need to contact the institution at all, addresses both problems simultaneously. The graduate also keeps a log of everywhere they presented it.
Verifying clinical or professional licensure
Locum staff, visiting specialists and agency clinicians all turn up carrying credentials that somebody has to check. A verifiable credential issued by whoever holds the authoritative record turns that check into a scan. And since verification never requires contacting the issuer, it works perfectly well at three in the morning and across time zones.
Site access based on training and certification
Safety orientations, equipment certifications and permits to work all share two properties: they expire, and a gatekeeper currently verifies them against a printed list. Credentials carrying designed validity periods, presented at the gate by QR code, turn that check from an administrative act into a verifiable one. On the day something goes wrong, that distinction is the whole difference.
A company that wants to accept credentials rather than issue them
Being the verifier is frequently the easier place to start, and it is just as frequently overlooked entirely. A verifier can either use open standards to perform presentation and verification themselves, or configure their own Entra tenant and let the Verified ID service handle most of the work. For any business receiving credentials from partners, that second route is a genuinely short project.
How organizations 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
W3C Decentralized Identifiers
- What Microsoft says it does
- Identifiers users create, own, and control independently of any organization or government, linked to decentralized public key infrastructure metadata
- What it means for you
- You neither issue this identifier nor have the ability to revoke it, and that is entirely the point
Component
Trust system
- What Microsoft says it does
- The did:web method, a permission-based model built on the existing reputation of a web domain, generally available
- What it means for you
- Your own domain becomes the trust anchor, which means no ledger and no new infrastructure
Component
Wallet, Microsoft Authenticator
- What Microsoft says it does
- It creates the identifiers, handles issuance and presentation requests, and backs up the identifier seed inside an encrypted wallet file
- What it means for you
- Most of your people already have it on their phone for multifactor authentication
Component
Microsoft Resolver
- What Microsoft says it does
- An API that looks up and resolves an identifier through did:web, returning the DID Document Object carrying the public keys and service endpoints
- What it means for you
- This is how a verifier locates your public key without ever contacting you
Component
Entra Verified ID Service
- What Microsoft says it does
- An issuance and verification service running in Azure, exposing a REST API for W3C Verifiable Credentials signed using did:web
- What it means for you
- Where your issuance and verification solutions get built, and which does most of the work on your behalf
Five steps, with the adoption question answered before anybody builds anything.
- 1
Pick a verification that already costs you something
We go looking for a recurring request your business answers by hand today, one carrying measurable volume and a named team absorbing the effort. That gives the project a genuine before and after rather than a demonstration, and it identifies the verifier population, which is the factor determining whether any of it succeeds.
- 2
Establish your role and your trust anchor
Issuer, verifier, or both, because those are genuinely different projects. After that comes the domain anchoring your decentralized identifier, since the supported trust system is did:web, drawing on a web domain existing reputation and generally available. This is also the point at which the blockchain question gets settled permanently.
- 3
Design the schema, the lifecycle, and the experience
We settle on the smallest claim set that still satisfies the verifier. Validity period, reissuance and revocation all get designed in from the start, because a portable credential gets verified without anybody contacting you. Then the issuance trigger, where a sign-in passes an ID token to the issuing service, and the presentation trigger, which is normally a link or a QR code.
- 4
Build issuance and verification, and test both sides
Built on the Verified ID service in Azure and its REST API, with Authenticator serving as the wallet. Verification gets tested from the far side of the transaction, including the case where the verifier is not a Microsoft customer at all, since open standards like Self-Issued OpenID Provider and Presentation Exchange are precisely what make that possible.
- 5
Run a real pilot with a real verifier
A credential that nobody accepts is worth nothing at all, so the pilot brings the accepting party in from the beginning rather than after the build is finished. We also establish the support path for holders, because lost phones, reinstalled applications and questions about wallet backup all arrive during the first month without fail.
What organizations ask about Entra Verified ID.
Fifteen questions that settle whether this is the right tool for you.
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?The sign-in hands an ID token across 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 the identity lifecycle, which is where most access decisions still belong.
Entra Entitlement Management
How external partners actually reach your resources, which is a separate question from proving attributes about themselves.
Passwordless authentication
The other Entra project that depends on Authenticator adoption.
Name a single verification your team handles manually every week.
Whatever you named is the use case. Employment confirmations. Certification checks. Membership status. Contractor onboarding. Wherever somebody in your business currently picks up a phone to confirm something, a credential can replace that call outright.
Related Services
Explore more solutions that work great with this service
Microsoft Entra ID Governance
Entra ID Governance implementation for US organizations: automating
Learn moreMicrosoft Entra Entitlement Management
Access packages, catalogs and time-boxed entitlements
Learn morePasswordless Authentication and Passkeys
Passwordless authentication rollouts for US organizations using
Learn moreMicrosoft Entra Conditional Access Design
Conditional Access design and review for US organizations:
Learn moreMFA Solutions
Multi-factor authentication implementation for US businesses on
Learn moreMicrosoft Entra
Identity and access management solutions
Learn more