Microsoft Entra Verified ID is a decentralized identity solution that enables issuance and verification of verifiable credentials (VCs) without relying on a central authority. This chapter covers the architecture, components, and configuration of Entra Verified ID, including decentralized identifiers (DIDs), verifiable credentials, and the roles of issuer, holder, and verifier. For the MS-102 exam, this topic appears in approximately 5-8% of questions under objective 2.3 'Implement and manage identity governance and access.' Understanding the flow of VC issuance and verification, as well as the use of Microsoft Authenticator as a wallet, is critical for exam success.
Jump to a section
Imagine you need to prove your age to enter a club. Instead of handing over your physical driver's license (which reveals your full name, address, and exact birth date), you use a digital passport app that only shows a cryptographically signed attestation that you are over 21. The club's scanner verifies the signature using the issuing authority's public key, without ever seeing your other personal data. This is exactly how Microsoft Entra Verified ID works: the issuer (e.g., a government) signs a verifiable credential (VC) containing specific claims (e.g., age > 21) using their private key. The holder stores the VC in a digital wallet app (e.g., Microsoft Authenticator). When a verifier (e.g., the club) asks for proof, the holder presents a presentation derived from the VC, which includes a zero-knowledge proof that satisfies the verifier's request without revealing extra data. The verifier checks the signature against the issuer's public key published in a decentralized identifier (DID) document. The entire system is built on decentralized identifiers and verifiable credentials standards (W3C), ensuring that no central authority tracks every presentation.
What is Microsoft Entra Verified ID?
Microsoft Entra Verified ID is a managed service within Microsoft Entra that allows organizations to issue and verify verifiable credentials (VCs) based on open standards from the World Wide Web Consortium (W3C) and the Decentralized Identity Foundation (DIF). It enables a trust model where issuers (e.g., employers, universities) digitally sign claims about a subject, holders store these claims in a digital wallet, and verifiers can cryptographically verify the claims without contacting the issuer each time. This eliminates the need for a central identity provider to broker every verification.
Why Decentralized Identity?
Traditional identity systems rely on a central authority (e.g., Microsoft Entra ID) to authenticate users and issue tokens. This creates a single point of failure, privacy concerns (the central authority can track all authentications), and limited interoperability. Decentralized identity shifts control to the user (holder) using DIDs and VCs. DIDs are globally unique identifiers that are cryptographically verifiable and do not require a central registry. VCs are tamper-evident credentials that contain claims and are signed by the issuer's DID.
Key Concepts and Components
Decentralized Identifier (DID): A globally unique identifier that is created and controlled by the entity (issuer, holder, verifier). DIDs are stored on a decentralized ledger (ION, a layer 2 network on top of Bitcoin) or in a DID document that contains public keys and service endpoints. Microsoft Entra Verified ID uses the did:ion method.
Verifiable Credential (VC): A set of claims (e.g., "employee ID: 12345", "role: Administrator") that is cryptographically signed by the issuer. The VC is encoded in JSON-LD and follows the W3C Verifiable Credentials Data Model.
Verifiable Presentation (VP): A subset of claims derived from one or more VCs, presented to a verifier. The holder can selectively disclose claims (e.g., only show that they are over 18 without revealing their exact birth date) using zero-knowledge proofs.
Issuer: The entity that creates and signs VCs. For example, a university issues a VC for a diploma. The issuer must have a DID and publish a DID document.
Holder: The entity that receives and stores VCs in a digital wallet (e.g., Microsoft Authenticator). The holder controls the private keys used to present VCs.
Verifier: The entity that requests and validates a VP. The verifier checks the issuer's signature using the issuer's DID document.
Microsoft Authenticator: The primary digital wallet for storing VCs. It supports the presentation of VCs via QR codes or deep links.
How It Works: Issuance Flow
The issuer creates a VC by defining a credential contract in the Microsoft Entra admin center. This contract specifies the claims, rules, and the issuer's DID.
The holder requests a VC via a QR code or deep link. The request includes the issuer's DID and the credential type.
The issuer authenticates the holder (e.g., via Entra ID sign-in) and verifies the claims (e.g., checks HR database for employee status).
The issuer signs the VC using its private key and sends it to the holder's wallet. The VC contains the claims, issuer DID, issuance date, and a cryptographic proof (signature).
The holder stores the VC in their wallet. The wallet generates a key pair for the holder, and the holder's DID is included in the VC as the subject.
How It Works: Verification Flow
The verifier sends a presentation request to the holder, specifying the required claims (e.g., "employee status = active"). This request is typically a QR code.
The holder's wallet selects the appropriate VC and generates a VP. The VP includes the requested claims and a proof signed by the holder's private key.
The holder presents the VP to the verifier (e.g., by scanning a QR code or clicking a deep link).
The verifier resolves the issuer's DID to obtain the issuer's public key. It also resolves the holder's DID to verify the holder's signature.
The verifier validates the cryptographic signatures, checks the VC's expiration date, and ensures the VC has not been revoked (by querying the issuer's revocation list via the DID document).
If valid, the verifier accepts the claims.
Decentralized Identifiers (DIDs) and ION
Microsoft Entra Verified ID uses the did:ion method. ION is a decentralized, layer 2 network that runs on top of the Bitcoin blockchain. DIDs are created by generating a key pair and anchoring the DID document to ION. The DID document contains:
The DID itself
Public keys (for signing and key agreement)
Service endpoints (e.g., for revocation)
Verification methods
DID operations (create, update, deactivate) are submitted as batches to ION, which uses Sidetree protocol. The DID document is immutable once anchored; updates require creating a new version and deactivating the old one.
Configuration Steps
To set up Entra Verified ID in your tenant:
Create a verifiable credentials service in the Microsoft Entra admin center. This registers your tenant as an issuer.
Define a credential contract that specifies the claims and rules. For example, a "Verified Employee" credential might include displayName, jobTitle, and email.
Register a decentralized identity (DID) for your tenant. This is automatically created when you set up the service.
Configure the wallet – users install Microsoft Authenticator and add the VC by scanning a QR code.
Issue credentials using Microsoft Graph API or the admin center.
Verify credentials by creating a verifier application that uses the Microsoft Entra Verified ID SDK.
Microsoft Graph API and PowerShell
You can automate issuance and verification using Microsoft Graph. For example, to issue a VC via Graph:
POST https://graph.microsoft.com/beta/identity/verifiableCredentials/issuance
Content-Type: application/json
{
"credentials": [
{
"type": "VerifiedEmployee",
"claims": {
"displayName": "John Doe",
"jobTitle": "Administrator"
}
}
],
"subject": {
"id": "user@contoso.com"
}
}To verify a VP, use:
POST https://graph.microsoft.com/beta/identity/verifiableCredentials/presentationsPowerShell cmdlets are available via the Microsoft.Graph module. For example:
Connect-MgGraph -Scopes "VerifiableCredential.Issuance.All"
New-MgIdentityVerifiableCredentialIssuance -CredentialType "VerifiedEmployee" -SubjectId "user@contoso.com"Revocation
Issuers can revoke VCs by updating their DID document with a revocation list endpoint. The verifier checks this endpoint during verification. Revocation is not immediate; it depends on how often the verifier fetches the list. The issuer can set a credentialStatus property in the VC that points to a RevocationList2021 or StatusList2021 entry.
Security Considerations
Private keys for DIDs must be stored securely. Microsoft manages the issuer keys in Azure Key Vault.
The holder's wallet uses the device's secure enclave (TPM on Windows, Secure Enclave on iOS, TEE on Android) to store private keys.
VCs are not encrypted by default; they are signed but the claims are visible to the holder and verifier. For sensitive data, use selective disclosure or encryption.
Replay attacks are mitigated by including a nonce from the verifier in the VP.
Interoperability
Entra Verified ID is compatible with other W3C-compliant wallets and issuers. However, Microsoft Authenticator is the primary wallet for Microsoft’s ecosystem. Verifiers can be any application that can resolve DIDs and verify signatures.
Limitations and Default Values
DIDs are public; anyone can resolve them.
The service is available in all Microsoft Entra regions but may have latency for DID resolution.
Credential types must be defined in the tenant; you cannot use arbitrary types.
The maximum number of VCs per user is not limited by the service, but wallet storage may vary.
The default credential expiration is 1 year, but can be customized.
Exam Tips
Know the three roles: issuer, holder, verifier.
Understand that VCs are signed by the issuer, not the holder.
Remember that the verifier does not need to contact the issuer for every verification; it only needs the issuer's DID.
Be aware that Microsoft Authenticator is the recommended wallet.
The exam may ask about revocation: the status is checked via a URL in the VC.
ION is the underlying decentralized network; DIDs are anchored to Bitcoin.
Zero-knowledge proofs are used for selective disclosure.
Summary
Microsoft Entra Verified ID provides a standards-based, decentralized identity solution that reduces reliance on central identity providers. It enables secure, privacy-preserving verification of claims using DIDs and VCs. Configuration involves setting up the service, defining credential contracts, and integrating with Microsoft Graph. The exam focuses on the architecture, flow, and components rather than deep cryptographic details.
Create Verifiable Credentials Service
In the Microsoft Entra admin center, navigate to 'Verifiable credentials' under 'Identity Governance'. Click 'Setup' to create a new service. This registers your tenant as an issuer and automatically generates a decentralized identifier (DID) using the did:ion method. The DID is anchored to the ION network (a Bitcoin-based layer 2). The service creates a key pair for signing VCs; the private key is stored in Azure Key Vault. You must assign the 'Verifiable Credential Issuer' admin role to manage the service. This step is prerequisite for any issuance or verification.
Define a Credential Contract
After the service is created, you define a credential contract (also called a credential type). This specifies the claims (e.g., 'displayName', 'email') and rules for issuance. The contract is a JSON-LD document that includes the credential schema, display properties, and the issuer's DID. You can create a custom credential or use a built-in template like 'VerifiedEmployee'. The contract is stored in your tenant and referenced during issuance. Rules can include requiring the subject to sign in with Entra ID or be a member of a specific group.
Issue a Verifiable Credential
To issue a VC, the holder (user) receives a request via QR code or deep link. The request contains the issuer's DID and credential type. The user scans the QR code with Microsoft Authenticator. Authenticator generates a key pair for the user (holder DID) and sends a request to the issuer. The issuer authenticates the user (e.g., via Entra ID) and validates the claims (e.g., checks HR database). If valid, the issuer signs the VC with its private key and sends it to the wallet. The wallet stores the VC, which includes the issuer DID, subject DID, claims, issuance date, and signature. The VC is now ready for presentation.
Present a Verifiable Credential
A verifier (e.g., a web app) creates a presentation request specifying required claims (e.g., 'employee status = active'). The request includes a nonce to prevent replay attacks. The holder opens their wallet, selects the relevant VC, and approves the presentation. The wallet generates a Verifiable Presentation (VP) that includes the requested claims and a proof signed by the holder's private key. The VP is sent to the verifier via a callback URL or QR code. The verifier then validates the VP by resolving the issuer's DID to obtain the public key, verifying the signature, checking expiration, and checking revocation status via the credentialStatus endpoint.
Verify the Presentation
The verifier receives the VP and performs cryptographic validation. First, it resolves the issuer's DID (e.g., did:ion:... ) to get the issuer's DID document, which contains the public key (verificationMethod). It verifies the issuer's signature on the VC. Then it resolves the holder's DID to verify the holder's signature on the VP. It checks the nonce to ensure the VP is fresh. It also checks the VC's expiration date and revocation status by querying the URL specified in the credentialStatus property (e.g., a StatusList2021 endpoint). If all checks pass, the verifier accepts the claims. The entire process takes a few seconds and does not require contacting the issuer in real time.
Enterprise Scenario 1: Employee Onboarding and Badges
A large enterprise wants to issue digital employee badges that can be used to access buildings and internal portals without a central card system. They deploy Microsoft Entra Verified ID to issue a 'VerifiedEmployee' credential to each new hire. The HR system triggers issuance via Microsoft Graph when an employee is added. The employee receives a QR code in their onboarding email, scans it with Microsoft Authenticator, and stores the VC. For building access, a verifier at the door scans the employee's wallet's QR code; the verifier checks the VC's signature and that the employee is still active (by checking revocation list). The issuer sets a 1-year expiration and revokes VCs immediately upon termination. This eliminates the need for physical badges and reduces costs. Common misconfiguration: not setting up the revocation list, so terminated employees retain access until the credential expires.
Scenario 2: University Diploma Verification
A university issues digital diplomas as VCs. Graduates receive a VC containing their degree, major, and graduation date. Employers can verify the diploma by having the graduate present the VC from their wallet. The verifier (HR system) resolves the university's DID and validates the signature. This eliminates the need for transcripts or third-party verification services. The university must ensure its DID is well-known and that the revocation list is maintained (e.g., if a diploma is rescinded). Performance considerations: the verifier must cache DID documents to avoid repeated ION lookups, which can be slow (seconds). Microsoft provides a DID resolver API. Common pitfall: the university forgets to update the DID document when keys expire, causing verification failures.
Scenario 3: Secure Remote Access for Contractors
A company needs to grant temporary access to contractors. They issue a 'ContractorAccess' VC valid for 90 days. The contractor stores it in their wallet. When accessing a VPN, the VPN gateway acts as a verifier and requests the VC. The contractor presents it, and the gateway verifies the signature and checks revocation. If the contractor's contract is terminated early, the issuer revokes the VC, and the gateway denies access immediately. This is more secure than passwords and does not require provisioning accounts in Entra ID. Scale: thousands of contractors can be supported with minimal overhead. Issues arise if the verifier does not check revocation status, allowing revoked contractors access.
Exam Focus for MS-102 Objective 2.3
This section covers exactly what the MS-102 exam tests regarding Microsoft Entra Verified ID. The exam objective 2.3 includes 'Implement and manage identity governance and access,' and within that, 'Manage verifiable credentials.' Expect 3-5 questions on this topic, often scenario-based.
Common Wrong Answers and Why Candidates Choose Them
'Verifiable credentials are stored in Entra ID.' – Wrong. VCs are stored in the user's wallet (Microsoft Authenticator). Entra ID only manages the issuer configuration and DID. Candidates confuse this because Entra ID stores traditional identity data.
'The verifier must contact the issuer every time to validate a VC.' – Wrong. The verifier uses the issuer's DID to get the public key and validate offline. The exam tests that verification does not require real-time issuer involvement.
'DIDs are stored on the Ethereum blockchain.' – Wrong. Microsoft uses ION (on Bitcoin). Candidates may assume any blockchain; the exam specifies ION.
'The holder signs the VC.' – Wrong. The issuer signs the VC. The holder signs the VP. This is a common trick.
Specific Numbers and Terms to Know
DID method: did:ion
Underlying network: ION (Bitcoin layer 2)
Wallet app: Microsoft Authenticator
Standard: W3C Verifiable Credentials Data Model
Revocation list format: StatusList2021 (or RevocationList2021)
Default credential validity: 1 year (configurable)
Roles: issuer, holder, verifier
Edge Cases and Exceptions
Revocation latency: Revocation is not instant; it depends on how often the verifier fetches the status list. The exam may ask about best practices: use short expiration or frequent status checks.
Key rotation: Issuers must update their DID document when keys rotate. Old VCs remain valid until expiration unless revoked.
Multiple issuers: A holder can have VCs from different issuers. A verifier can request claims from multiple VCs in one presentation.
Zero-knowledge proofs: The exam may mention selective disclosure but not require deep knowledge of ZKPs.
How to Eliminate Wrong Answers
If an answer says 'credential is stored in Entra ID' or 'Azure AD,' eliminate it.
If an answer says 'verifier must contact issuer,' eliminate it.
If an answer mentions 'Ethereum' or 'Hyperledger,' eliminate it (Microsoft uses ION/Bitcoin).
If an answer says 'holder signs the credential,' eliminate it.
Look for answers that mention 'Microsoft Authenticator', 'DID', 'ION', 'W3C', and 'signature verification.'
Microsoft Entra Verified ID uses the did:ion method on ION (Bitcoin layer 2).
Three roles: issuer, holder, verifier.
VCs are signed by the issuer; VPs are signed by the holder.
Verification does not require contacting the issuer in real time.
Microsoft Authenticator is the recommended wallet app.
Revocation is done via a status list (StatusList2021) pointed to by the VC.
Default credential validity is 1 year (configurable).
The exam tests scenario-based understanding of issuance and verification flows.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Entra Verified ID
Decentralized using DIDs and ION
Holder stores credentials in wallet
Verifier validates offline using DID document
Privacy-preserving with selective disclosure
Interoperable across organizations (W3C standards)
Traditional Identity (Entra ID)
Centralized identity provider (Microsoft Entra ID)
User credentials stored in Entra ID
Verifier must contact Entra ID to validate tokens
Reveals all claims in the token
Tied to a single identity provider
Mistake
Verifiable credentials are stored in Microsoft Entra ID.
Correct
VCs are stored in the user's digital wallet (Microsoft Authenticator). Entra ID only stores the issuer configuration and DID documents.
Mistake
The verifier must contact the issuer every time to verify a credential.
Correct
The verifier uses the issuer's DID to obtain the public key from the decentralized ledger (ION) and validates the signature locally. No real-time contact with the issuer is required.
Mistake
Microsoft Entra Verified ID uses the Ethereum blockchain.
Correct
It uses ION, a layer 2 network on top of Bitcoin. The DID method is did:ion.
Mistake
The holder signs the verifiable credential.
Correct
The issuer signs the VC. The holder signs the verifiable presentation (VP) when presenting the credential.
Mistake
Revocation is immediate and automatic.
Correct
Revocation is not immediate; it depends on how often the verifier fetches the revocation list. The issuer updates a status list, and verifiers must poll it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A VC is the signed credential issued by an issuer containing claims about a subject. A VP is a subset of claims from one or more VCs, presented to a verifier. The VP is signed by the holder (subject) to prove control of the VC. In short, VCs are stored; VPs are presented.
The issuer publishes a revocation list (StatusList2021) at a URL specified in the VC's credentialStatus property. The verifier fetches this list during verification to check if the VC is revoked. Revocation is not immediate; it depends on how often the verifier polls the list. Issuers can also set short expiration times to reduce reliance on revocation.
Yes, any W3C-compliant wallet can store and present VCs. However, Microsoft Authenticator is the primary wallet for Microsoft's ecosystem and is recommended for integration with Entra Verified ID. The exam focuses on Microsoft Authenticator.
ION (Identity Overlay Network) is a decentralized, layer 2 network on Bitcoin that anchors DID documents. It provides a public, immutable ledger for DIDs without requiring a central registry. Microsoft Entra Verified ID uses the did:ion method to create and resolve DIDs.
Use the POST endpoint: https://graph.microsoft.com/beta/identity/verifiableCredentials/issuance with a JSON body containing the credential type and claims. The subject is identified by email or user ID. The issuer must have the VerifiableCredential.Issuance.All permission.
The issuer must rotate its keys by updating the DID document with a new public key and deactivating the old one. Existing VCs signed with the old key will no longer be verifiable unless the verifier caches old keys. The issuer should also revoke all VCs and reissue new ones.
Yes, it supports selective disclosure using zero-knowledge proofs (ZKPs). The holder can prove a claim (e.g., 'age > 21') without revealing the exact value (e.g., birth date). This is part of the W3C standard and is available in Microsoft Authenticator.
You've just covered Microsoft Entra Verified ID — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?