The credentials themselves
- The signing keys, held in your Microsoft tenant
- The credential format and the wallet experience
- Whether a credential is valid, and its status
- The underlying Verified ID service and its availability
How it works
The Microsoft Entra Verified ID option.
If your organisation already runs Microsoft Entra, DiligenceID can administer Verified ID issuance and checking for you — alongside the credentials it issues itself, in one place.
The important distinction
Worth getting straight before anything else, because it decides who is responsible for what.
The administration around them
- Connecting to your tenant and discovering what is there
- Triggering issuance and presentation requests
- Withdrawing credentials through Microsoft
- One interface and one activity record across both providers
A credential issued through Microsoft is a Microsoft credential and behaves like one everywhere downstream: Microsoft signs it, and it keeps Microsoft's format, status handling and wallet experience. DiligenceID gives you one place to run both providers.
What setting it up involves
You create a workspace
A Microsoft issuer workspace in DiligenceID, separate from any native issuer you run.
You connect your tenant
DiligenceID authenticates to your Microsoft tenant using an application registration you create and control. You can revoke that access at any time.
We check the connection works
A read-only validation confirms DiligenceID can reach the services it needs, before anything is issued. Nothing is changed in your tenant during this step.
Your existing credentials are discovered
Credential types already defined in your tenant are found and mapped in, rather than recreated.
You activate it
Once ready, issuance and checking run through DiligenceID against your Microsoft tenant.
What you need to provide
- A Microsoft tenant with Verified ID set up
- Verified ID is a Microsoft service with its own licensing and setup. DiligenceID does not provide it, resell it or configure your tenant for you.
- An application registration
- Created in your tenant, with the permissions DiligenceID needs to act on your behalf. You own it and you can withdraw it.
- A decision about which credentials go where
- Some organisations issue everything through Microsoft. Some use native DiligenceID credentials for selective disclosure and Microsoft for credentials tied to their workforce directory. Both are fine; mixing them needs a deliberate choice.
Planning around the two providers
Each provider has its own wallet
Microsoft credentials go into a wallet supporting Microsoft's format, typically Microsoft Authenticator. DiligenceID credentials go into a wallet supporting SD-JWT. Decide which your recipients will use before you issue.
Status handling differs
Withdrawal goes through Microsoft's own mechanism rather than the DiligenceID status list. Both give you immediate withdrawal, along different paths.
Selective sharing differs
The SD-JWT selective sharing described elsewhere on this site applies to credentials DiligenceID issues. Microsoft credentials follow Microsoft's behaviour, worth evaluating on its own terms.
Microsoft owns the underlying service
Availability, roadmap and changes to Verified ID sit with Microsoft. DiligenceID gives you one place to administer it, and we track those changes so your configuration keeps working.
Verified ID is a Microsoft product integration. Where this site describes open protocol support, that refers to credentials DiligenceID issues itself. See the standards
Already running Entra?
Tell us what is in your tenant today and what you want people to be able to prove. We will show you how the two providers sit side by side.