Microsoft Entra Verified ID: Decentralised Identity Credentials for B2B Partner Verification
Every time an employee joins a partner meeting, every time a contractor needs temporary system access, and every time HR needs to confirm a credential for a background check, someone in your organisation is making a trust decision without cryptographic proof. Microsoft Entra Verified ID replaces that manual trust gap with tamper-proof, privacy-preserving digital credentials built on the W3C Verifiable Credentials standard — and it is available to every Microsoft 365 Business Premium tenant at no additional licence cost.
What Verified ID Actually Is
Entra Verified ID is Microsoft’s implementation of decentralized identity (DID). Instead of a central database that attests “this person works here,” the credential is issued to the user’s Microsoft Authenticator wallet as a signed JSON-LD document. When a relying party (a partner portal, a job board, a compliance auditor) asks for proof, the user presents the credential from their wallet. The relying party verifies the issuer’s cryptographic signature without ever calling back to your tenant — eliminating the privacy risk of centralised verification lookups.
The underlying identifier is a DID (Decentralised Identifier), a W3C standard URI that resolves to a DID document containing public keys. Microsoft hosts the did:web method, meaning your issuer DID resolves to a JSON document at a well-known URL under your verified domain — no blockchain required, no gas fees, no exotic infrastructure.
The Three Flows You Need to Understand
1. Credential Issuance
Your tenant acts as the issuer. You define a credential manifest — a JSON configuration that specifies which claims (job title, department, employee ID, clearance level) to pull from Entra ID and embed in the credential. When an employee opens a deep link or scans a QR code, Authenticator calls the Request Service API, your tenant validates the session, and Authenticator stores the signed credential. The whole flow takes under 30 seconds.
2. Credential Presentation
The relying party (your partner’s portal, your vendor’s onboarding form, your own external-facing application) embeds a presentation request via the same Request Service API. A QR code or deep link appears. The user scans with Authenticator, selects the credential, and approves the share. The relying party receives a signed presentation containing exactly the claims you configured — nothing more. Your tenant is not involved in real-time; the signature alone provides the proof.
3. Credential Revocation
When an employee leaves, you revoke the credential in Entra Verified ID. The credential’s status entry in the Status List 2021 bitstring flips to revoked. Any subsequent presentation check by a relying party will reject the credential. Revocation propagates within minutes — no need to chase down every relying party individually.
Key Use Cases for a Small Business in Berlin
| Scenario | Traditional approach | With Verified ID |
|---|---|---|
| Contractor onboarding to partner portal | Manual email with PDF copies of employment letter | Verified credential issued on day one, presented at portal login |
| B2B guest user verification | Business card + LinkedIn check | Partner presents Verified ID credential from their issuing tenant |
| Audit / compliance evidence | HR extracts PDF report per request | Auditor receives verifiable presentation, cryptographically bound to your signing key |
| Temporary elevated access | IT opens a ticket, manually grants access, hopes they remember to revoke | Time-limited credential gates access; revocation auto-removes access |
Configuration Walkthrough
Step 1 — Enable Verified ID in Entra Admin Centre
Navigate to Entra admin centre → Verified ID → Setup. Register your organisation — provide your verified domain (the one that hosts the did:web document), organisation display name, and notification email. Microsoft provisions your DID document at https://<your-domain>/.well-known/did.json. You do not need to modify DNS; you only need the domain to be verified in Entra.
Step 2 — Create a Credential Type
Go to Credentials → Add credential. Choose “Custom credential” or one of Microsoft’s pre-built types (Verified Employee, Verified Customer). For a custom type, upload two JSON files: the rules file (which Entra ID attributes to include as claims) and the display file (how the credential card looks in Authenticator — colours, logo, localised strings). Save. Your credential type is now ready for issuance.
Step 3 — Build the Issuance Flow
You have two options: use My Account portal (zero-code, built-in — employees go to myaccount.microsoft.com, find “Verified ID,” and tap Issue) or call the Request Service API from your own application. The API path is POST https://verifiedid.did.msidentity.com/v1.0/{tenantId}/verifiableCredentials/createIssuanceRequest. The response contains a URL you encode as a QR code or deep link.
Step 4 — Build the Verification Flow
In your relying party application (or your partner’s), call POST .../createPresentationRequest with the credential type you require and the claims you want to receive. On callback, your application receives the verified claims and the presentation JWT, which you should store as audit evidence. The Face Check add-on (requires Verified ID Premium) adds a real-time liveness check that matches the credential photo against the user’s camera — useful for high-assurance onboarding.
Privacy Architecture
Verified ID is privacy-preserving by design. Microsoft does not log credential presentations — the verification happens between the user’s wallet and the relying party. Your tenant’s involvement ends at issuance. The user controls which claims to share; the relying party sees only what was requested. Pairwise DIDs (a separate sub-DID per relying party, configurable) prevent correlation across different verifiers — the job board cannot tell that the user also presented credentials to your partner portal.
For GDPR-sensitive deployments: claims embedded in the credential are signed at issuance time. If the source attribute in Entra ID changes (e.g., employee moves department), the credential does not auto-update — you either revoke and re-issue, or design your credential rules to pull attributes dynamically at issuance. Plan your refresh cadence accordingly.
Integration with the Broader Identity Stack
Verified ID is not a replacement for Entra ID — it is a complement. Your employees still authenticate with Entra (passwords, MFA, or Windows Hello for Business). Verified ID handles the attestation problem: proving identity claims to external parties without giving those parties read access to your directory. Combined with Entra External Identities B2B, you can require that partner guest accounts present a valid Verified ID credential before being added to your tenant — cryptographic proof of employment before shadow account creation.
For small businesses in Berlin operating under GDPR, Verified ID reduces the risk of unnecessary data sharing during partner onboarding. Instead of emailing a PDF employment letter (which the recipient can store indefinitely), you issue a credential that can be revoked the moment the engagement ends.