Aug. 5, 2026
Microsoft Entra Verified ID - Simply Explained
Modern identity security extends far beyond passwords and multi-factor authentication. While Microsoft Entra ID, passkeys, and MFA help verify that someone controls a sign-in method, they cannot prove important real-world facts such as employment status, completed security training, professional certifications, contractor relationships, or verified identity during account recovery. In this Microsoft Knowledge Nuggets episode, Mirko Peters explains Microsoft Entra Verified ID in plain English, showing how organizations can replace manual document verification with secure, privacy-friendly digital credentials that improve trust while reducing administrative effort.
UNDERSTANDING MICROSOFT ENTRA VERIFIED ID
Microsoft Entra Verified ID enables organizations to issue, store, and verify digital credentials based on open standards for decentralized identity. Instead of emailing PDFs, screenshots, certificates, or identity documents, trusted organizations issue digitally signed credentials that individuals securely store inside the Microsoft Authenticator app. These credentials contain verified claims such as employee status, completed training, professional licenses, student enrollment, or supplier relationships. When another organization requests proof, users decide whether to share the required information while the verifier can validate the credential's authenticity, issuer, expiration date, and revocation status without relying on manual phone calls or email confirmations.
ISSUERS, HOLDERS, AND VERIFIERS: THE VERIFIED ID MODEL
Every Microsoft Entra Verified ID solution follows a simple three-party trust model. The issuer creates and digitally signs the credential after validating information from trusted business systems. The holder receives and securely stores the credential in their digital wallet within Microsoft Authenticator. The verifier requests specific claims to support a business decision such as granting access, approving onboarding, confirming qualifications, or validating identity during sensitive operations. This model significantly reduces document handling, minimizes unnecessary sharing of personal information, and creates a more secure verification process that scales across organizations.
FACE CHECK AND HIGH-ASSURANCE IDENTITY VERIFICATION
For higher-risk scenarios, Microsoft Entra Verified ID introduces Face Check to strengthen identity verification. Face Check compares a live selfie with the photo stored inside the verified credential, helping organizations confirm that the individual presenting the credential is the legitimate credential holder. The episode explores practical use cases including remote employee onboarding, privileged account recovery, contractor verification, privileged access requests, and high-security administrative operations. Combined with Microsoft Entra ID, Face Check provides stronger protection against impersonation attacks, deepfakes, stolen devices, and social engineering while supporting Zero Trust identity principles.
PRACTICAL MICROSOFT 365 USE CASES FOR VERIFIED ID
Microsoft Entra Verified ID integrates naturally with Microsoft 365 identity and governance scenarios. Organizations can automate remote onboarding, simplify secure account recovery, validate contractor relationships, confirm training completion before granting access to sensitive projects, and verify qualifications without exchanging physical documents. Combined with Microsoft Entra Access Packages, Microsoft Teams, SharePoint Online, enterprise applications, and Microsoft Entra role assignments, Verified ID enables organizations to make access decisions based on trusted business facts instead of manual document reviews. This reduces administrative overhead while improving both security and user privacy.
BUILDING A TRUSTED DIGITAL IDENTITY STRATEGY
Successfully implementing Microsoft Entra Verified ID requires careful planning around credential issuance, trusted issuers, claim definitions, expiration policies, revocation processes, governance, and user experience. Organizations should begin with a single business scenario that already involves manual identity verification, establish clear trust relationships, define credential lifecycles, and gradually expand their implementation. As digital identity continues evolving, Microsoft Entra Verified ID provides a scalable foundation for privacy-preserving verification that complements Microsoft Entra ID, MFA, passkeys, and Zero Trust architecture while helping organizations modernize identity proofing across employees, partners, contractors, students, and customers.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:04,080
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:04,080 --> 00:00:06,000
FM, I'm your host, Mirko Peters.
3
00:00:06,000 --> 00:00:10,760
Today's topic is one that almost everyone has heard of, but few people truly understand.
4
00:00:10,760 --> 00:00:12,560
Proving who you are beyond just signing in.
5
00:00:12,560 --> 00:00:16,320
You can have strong sign in security, you can use MFA, you can use a pass key instead of
6
00:00:16,320 --> 00:00:17,320
a pass word.
7
00:00:17,320 --> 00:00:20,240
But here's the thing, none of that automatically proves who sits behind the screen.
8
00:00:20,240 --> 00:00:22,360
It doesn't prove whether they still work for a company.
9
00:00:22,360 --> 00:00:25,720
It doesn't prove whether they completed the training needed for a sensitive project.
10
00:00:25,720 --> 00:00:26,960
Think about these situations.
11
00:00:26,960 --> 00:00:29,440
A help desk agent gets a call from someone locked out.
12
00:00:29,440 --> 00:00:33,760
A remote new hire needs equipment, a contractor needs access, an applicant has no company
13
00:00:33,760 --> 00:00:34,760
account yet.
14
00:00:34,760 --> 00:00:37,320
Those situations need more than a successful sign in.
15
00:00:37,320 --> 00:00:39,400
They need proof of a real world fact.
16
00:00:39,400 --> 00:00:44,280
By the end of this episode, you'll understand Microsoft Entra verified ID in plain English.
17
00:00:44,280 --> 00:00:47,080
You'll see how a digital wallet fits into the process.
18
00:00:47,080 --> 00:00:51,680
And you'll learn why an organization can often check a credential without calling the organization
19
00:00:51,680 --> 00:00:52,680
that issued it.
20
00:00:52,680 --> 00:00:54,240
Grab your coffee and let's dive in.
21
00:00:54,240 --> 00:00:55,480
Let's start with the problem.
22
00:00:55,480 --> 00:00:59,040
The old way of checking identity still creates a lot of risk.
23
00:00:59,040 --> 00:01:02,160
The problem identity checks still depend on manual trust.
24
00:01:02,160 --> 00:01:05,480
Imagine you need to prove that you completed data handling training before you can join
25
00:01:05,480 --> 00:01:06,480
a project team.
26
00:01:06,480 --> 00:01:07,800
Here's how it usually works.
27
00:01:07,800 --> 00:01:11,800
You download a certificate as a PDF, you attach it to an email, someone opens it, checks
28
00:01:11,800 --> 00:01:15,280
the name, checks the date, and decides whether it looks right.
29
00:01:15,280 --> 00:01:17,640
Sometimes that proof arrives as a screenshot.
30
00:01:17,640 --> 00:01:20,280
Sometimes it arrives through a shared spreadsheet.
31
00:01:20,280 --> 00:01:24,520
Sometimes a manager gets a message in team saying, yes, this person finished the course.
32
00:01:24,520 --> 00:01:25,520
The work gets done.
33
00:01:25,520 --> 00:01:28,600
But the proof travels around as loose files and informal messages.
34
00:01:28,600 --> 00:01:31,800
People must decide what to trust, often while they're busy with other work.
35
00:01:31,800 --> 00:01:33,520
That creates two problems at once.
36
00:01:33,520 --> 00:01:35,440
First, documents are easy to copy and change.
37
00:01:35,440 --> 00:01:39,360
A PDF can look convincing even when the course expired, the person never took it, or the
38
00:01:39,360 --> 00:01:41,320
certificate belongs to someone else.
39
00:01:41,320 --> 00:01:45,480
Second, the organization collecting that proof may receive far more personal data than it
40
00:01:45,480 --> 00:01:46,480
needs.
41
00:01:46,480 --> 00:01:50,280
A copy of a passport, a driver's license, or a student record often contains details
42
00:01:50,280 --> 00:01:52,560
that have nothing to do with the decision being made.
43
00:01:52,560 --> 00:01:54,880
You might only need to know that someone completed a course.
44
00:01:54,880 --> 00:01:58,520
Instead, you receive a full document and now need to store it, protect it, and decide
45
00:01:58,520 --> 00:01:59,680
how long to keep it.
46
00:01:59,680 --> 00:02:01,760
The pressure gets even worse at the help desk.
47
00:02:01,760 --> 00:02:05,760
Picture someone calling because they lost their phone, can't use their MFA method, and
48
00:02:05,760 --> 00:02:07,280
can't get into their work account.
49
00:02:07,280 --> 00:02:10,000
The caller might know their name, job title, and employee number.
50
00:02:10,000 --> 00:02:12,520
They might even sound like the person they claim to be.
51
00:02:12,520 --> 00:02:15,200
But a skilled attacker can know those details too.
52
00:02:15,200 --> 00:02:19,480
With AI voice tools and deepfake video, a calm voice on a call or a familiar face in
53
00:02:19,480 --> 00:02:23,080
a video meeting no longer gives staff enough confidence on its own.
54
00:02:23,080 --> 00:02:26,560
The help desk agent ends up making a high-risk decision under time pressure.
55
00:02:26,560 --> 00:02:28,920
If they refuse a genuine employee, work stops.
56
00:02:28,920 --> 00:02:33,840
If they approve the wrong person, an attacker may gain access to email files, teams, chats,
57
00:02:33,840 --> 00:02:35,400
or customer data.
58
00:02:35,400 --> 00:02:38,160
Many organizations also hold proof in separate places.
59
00:02:38,160 --> 00:02:42,320
HR knows whether someone works there, a training provider knows whether they pass the course.
60
00:02:42,320 --> 00:02:44,160
A university knows whether they study there.
61
00:02:44,160 --> 00:02:47,640
A licensing body knows whether a qualification remains current.
62
00:02:47,640 --> 00:02:51,240
When another organization needs one of those facts, it often asks for a document sends
63
00:02:51,240 --> 00:02:52,800
an email or makes a phone call.
64
00:02:52,800 --> 00:02:55,240
It's slow, hard to scale, easy to get wrong.
65
00:02:55,240 --> 00:02:56,680
Now let's clear up a common myth.
66
00:02:56,680 --> 00:02:58,680
MFA doesn't solve this specific problem.
67
00:02:58,680 --> 00:03:03,000
MFA proves that someone controls a sign-in method, such as an authenticate or prompt, phone
68
00:03:03,000 --> 00:03:04,000
or pasky.
69
00:03:04,000 --> 00:03:05,880
That is still a strong and useful check.
70
00:03:05,880 --> 00:03:09,160
But it doesn't prove that the person completed safety training yesterday, it doesn't
71
00:03:09,160 --> 00:03:11,760
prove that a contractor still works for an approved supplier.
72
00:03:11,760 --> 00:03:15,360
And it doesn't prove that an applicant without an intro account is qualified for the role.
73
00:03:15,360 --> 00:03:18,880
The check needs to move away from a person's account and to what a signed claim about that
74
00:03:18,880 --> 00:03:19,880
person.
75
00:03:19,880 --> 00:03:23,040
A verified ID comes in, but we'll cover that in the next nugget.
76
00:03:23,040 --> 00:03:25,600
What Microsoft Entra Verified ID actually is.
77
00:03:25,600 --> 00:03:27,720
So what is Microsoft Entra Verified ID?
78
00:03:27,720 --> 00:03:31,800
In plain English, it's Microsoft service for issuing and verifying digital credentials.
79
00:03:31,800 --> 00:03:35,200
A credential is like a signed digital card that proves a specific fact about you.
80
00:03:35,200 --> 00:03:38,480
Think of Microsoft Entra ID as the reception desk in an office building.
81
00:03:38,480 --> 00:03:41,680
It checks your sign-in and decides whether you can enter the building.
82
00:03:41,680 --> 00:03:44,480
Verified ID is more like a signed card you carry after your inside.
83
00:03:44,480 --> 00:03:48,760
That card might show you an employee, or that you completed a course, hold a license,
84
00:03:48,760 --> 00:03:51,480
yet a university, or work for an approved supplier.
85
00:03:51,480 --> 00:03:53,880
The card includes details called claims.
86
00:03:53,880 --> 00:03:58,120
Those are just the facts written on it, like your name, employee number, job title, course
87
00:03:58,120 --> 00:04:02,040
name, student status, a photo, and the issue and expiry dates.
88
00:04:02,040 --> 00:04:04,760
The organization decides which claims go on the credential.
89
00:04:04,760 --> 00:04:08,920
A training company might issue a credential saying you completed a data handling course,
90
00:04:08,920 --> 00:04:12,720
valid until a certain date, and it doesn't need your home address or phone number, just
91
00:04:12,720 --> 00:04:14,040
the essential facts.
92
00:04:14,040 --> 00:04:16,440
That small amount of shared data is the whole point.
93
00:04:16,440 --> 00:04:19,600
Your Microsoft Authenticator app can hold these credentials on your phone.
94
00:04:19,600 --> 00:04:23,720
Think of it as a digital wallet, but for work and identity proofs instead of payment cards.
95
00:04:23,720 --> 00:04:27,920
You can open the credential and see who issued it, what it says about you, when it expires,
96
00:04:27,920 --> 00:04:29,160
and where you've used it.
97
00:04:29,160 --> 00:04:32,520
The credential belongs to you in your wallet, but that doesn't mean you can edit it.
98
00:04:32,520 --> 00:04:36,120
You can't change training completed to training completed with distinction anymore than
99
00:04:36,120 --> 00:04:38,560
you can rewrite a badge printed by your employer.
100
00:04:38,560 --> 00:04:42,920
The issuing organization signs the credential, and that signature protects the information
101
00:04:42,920 --> 00:04:47,040
inside if someone changes the data, the check fails.
102
00:04:47,040 --> 00:04:50,120
This is where the word decentralized often confuses people.
103
00:04:50,120 --> 00:04:52,360
It doesn't mean there's no organization in charge.
104
00:04:52,360 --> 00:04:56,000
It means the proof doesn't have to live in one central system that every other organization
105
00:04:56,000 --> 00:04:57,000
must call.
106
00:04:57,000 --> 00:05:01,200
One organization issues the proof you hold it, and another organization can check it.
107
00:05:01,200 --> 00:05:04,720
The issue could be your employer, a school, a training provider, a professional body,
108
00:05:04,720 --> 00:05:06,680
or an identity verification partner.
109
00:05:06,680 --> 00:05:11,120
The holder is you, and the verifier is the organization asking whether a claim is valid.
110
00:05:11,120 --> 00:05:15,600
The approved Entra Verified ID manages the technology around that exchange, so organizations
111
00:05:15,600 --> 00:05:20,520
can issue and request these signed credentials without building the whole system from scratch.
112
00:05:20,520 --> 00:05:23,120
How does the verifier know the card is real?
113
00:05:23,120 --> 00:05:25,200
It checks several things behind the scenes.
114
00:05:25,200 --> 00:05:29,280
The issuer identity and the organization's verified domain, the digital signature to make
115
00:05:29,280 --> 00:05:33,520
sure it came from that issuer and hasn't changed, whether the credential is still within
116
00:05:33,520 --> 00:05:37,040
its valid date range and whether the issuer has revoked it.
117
00:05:37,040 --> 00:05:40,840
So if a contractor leaves a supplier, the supplier can revoke the credential and a verifier
118
00:05:40,840 --> 00:05:43,920
checking it later will see that it should no longer be accepted.
119
00:05:43,920 --> 00:05:47,960
That's why a verifier often doesn't need to phone the issuer or send an email asking,
120
00:05:47,960 --> 00:05:49,760
is this certificate still good?
121
00:05:49,760 --> 00:05:53,560
The proof carries a signed record, and the verification process checks whether that record
122
00:05:53,560 --> 00:05:55,160
still holds up.
123
00:05:55,160 --> 00:05:57,360
Notice what Verified ID does not replace.
124
00:05:57,360 --> 00:06:00,640
It doesn't replace your password, pass key, or MFA method.
125
00:06:00,640 --> 00:06:04,320
It doesn't replace single sign-on, and it's not a live employee directory that updates
126
00:06:04,320 --> 00:06:06,480
every second with HR changes.
127
00:06:06,480 --> 00:06:10,760
Microsoft Entra ID still handles sign-in, creating the account-based control around apps,
128
00:06:10,760 --> 00:06:13,400
teams, SharePoint, and Microsoft 365.
129
00:06:13,400 --> 00:06:15,320
Verified ID adds a different kind of proof.
130
00:06:15,320 --> 00:06:19,120
It says that a trusted organization confirmed a specific fact about a person at a specific
131
00:06:19,120 --> 00:06:23,960
time with an expiry date and a way to withdraw that proof if circumstances change.
132
00:06:23,960 --> 00:06:27,040
That gives you a much clearer question to ask, who issued the proof?
133
00:06:27,040 --> 00:06:29,960
What exactly does it confirm and should we trust it for this decision?
134
00:06:29,960 --> 00:06:32,760
Once you see that, the whole model becomes easier.
135
00:06:32,760 --> 00:06:36,920
Every verified ID journey has three people, or roles, involved.
136
00:06:36,920 --> 00:06:40,160
The three roles, issuer, holder, and verifier.
137
00:06:40,160 --> 00:06:42,720
Every verified ID exchange has three roles.
138
00:06:42,720 --> 00:06:47,600
The issuer creates the credential, the holder keeps it, and the verifier asks to see it.
139
00:06:47,600 --> 00:06:50,720
That's the whole pattern, and once you know those three roles, the technical term stop
140
00:06:50,720 --> 00:06:51,800
getting in the way.
141
00:06:51,800 --> 00:06:55,320
The issuer is the organization that can honestly confirm a fact.
142
00:06:55,320 --> 00:06:58,280
Your employer can issue a credential, confirming you work there.
143
00:06:58,280 --> 00:07:02,720
A university can confirm you're a student, a training provider can confirm you completed
144
00:07:02,720 --> 00:07:03,720
a course.
145
00:07:03,720 --> 00:07:08,400
A professional body can confirm your license is current, and in some cases, an identity
146
00:07:08,400 --> 00:07:13,960
verification partner can check a government ID and issue a credential based on that.
147
00:07:13,960 --> 00:07:17,200
The issuer doesn't just fill in a card with whatever someone asks for.
148
00:07:17,200 --> 00:07:22,320
It first checks the source it trusts, like an HR record, a course result, a student system,
149
00:07:22,320 --> 00:07:26,160
or an identity check, and then creates the credential with the claims that match that
150
00:07:26,160 --> 00:07:27,160
decision.
151
00:07:27,160 --> 00:07:30,200
The issuer also decides how long the credential should remain valid.
152
00:07:30,200 --> 00:07:33,840
A course certificate might last a year, and employee credential might end when employment
153
00:07:33,840 --> 00:07:34,840
ends.
154
00:07:34,840 --> 00:07:36,680
A visitor pass might last only one day.
155
00:07:36,680 --> 00:07:39,400
That time limit matters because the fact can change.
156
00:07:39,400 --> 00:07:44,160
Someone may leave the company, a qualification may expire, or a course may need renewal.
157
00:07:44,160 --> 00:07:45,920
The holder is the person named in the credential.
158
00:07:45,920 --> 00:07:50,040
They accept it into Microsoft Authenticator where they can see who issued it, what information
159
00:07:50,040 --> 00:07:52,440
it contains, and the issue and expiry dates.
160
00:07:52,440 --> 00:07:54,840
The holder has control at the point of sharing.
161
00:07:54,840 --> 00:07:58,520
If an organization requests a credential, the person can review the request and choose
162
00:07:58,520 --> 00:08:00,040
to approve or decline.
163
00:08:00,040 --> 00:08:01,880
That consent step is worth posing on.
164
00:08:01,880 --> 00:08:05,480
A credential doesn't give every organization automatic access to your information.
165
00:08:05,480 --> 00:08:11,240
A verifier must ask for the proof, and the holder sees that request before anything is shared.
166
00:08:11,240 --> 00:08:15,360
Authenticator also keeps a record of credential activity, so the holder can look back at where
167
00:08:15,360 --> 00:08:16,600
it was presented.
168
00:08:16,600 --> 00:08:20,240
The verifier is the organization that needs proof for a particular decision.
169
00:08:20,240 --> 00:08:24,360
An employer deciding whether to grant access to a sensitive project, a help desk, checking
170
00:08:24,360 --> 00:08:28,400
someone before starting an account recovery, a hiring company confirming an applicant's
171
00:08:28,400 --> 00:08:32,680
qualification, or a partner organization needing proof that a contractor belongs to an
172
00:08:32,680 --> 00:08:33,880
approved supplier.
173
00:08:33,880 --> 00:08:37,920
To use a simple workplace example, Alex needs access to a project that handles customer
174
00:08:37,920 --> 00:08:38,920
data.
175
00:08:38,920 --> 00:08:42,040
Before joining, the company requires approved data handling training.
176
00:08:42,040 --> 00:08:45,520
Alex completes the course through an outside training provider, which checks the result
177
00:08:45,520 --> 00:08:47,040
and issues a training credential.
178
00:08:47,040 --> 00:08:49,280
Alex accepts it into Microsoft Authenticator.
179
00:08:49,280 --> 00:08:54,160
Later, Alex opens the company's access request page and asks to join the project.
180
00:08:54,160 --> 00:08:55,920
The page shows a QR code.
181
00:08:55,920 --> 00:08:59,960
Alex scans it with Authenticator and sees a request to present the training credential.
182
00:08:59,960 --> 00:09:03,840
The app shows which organization is asking and what information it wants.
183
00:09:03,840 --> 00:09:05,600
Alex reviews the request and approves it.
184
00:09:05,600 --> 00:09:09,240
The training credential stays in Alex's wallet and the company receives the approved claim
185
00:09:09,240 --> 00:09:14,240
data needed for its decision rather than an emailed PDF that could be copied, forwarded,
186
00:09:14,240 --> 00:09:15,800
or stored forever.
187
00:09:15,800 --> 00:09:17,760
That gives the verifier a cleaner process.
188
00:09:17,760 --> 00:09:21,800
It checks that the credential came from the expected issuer, verifies the signature, and
189
00:09:21,800 --> 00:09:24,160
checks whether it has expired or been revoked.
190
00:09:24,160 --> 00:09:27,800
If all those checks pass, the company can move Alex's access request forward.
191
00:09:27,800 --> 00:09:31,440
No one needs to search an inbox for a certificate, call the training provider and wait for
192
00:09:31,440 --> 00:09:35,160
a reply or decide whether a screenshot looks believable.
193
00:09:35,160 --> 00:09:37,920
The verifier still needs to make a sensible policy decision.
194
00:09:37,920 --> 00:09:42,280
It must decide which training provider it trusts, which credential type it accepts, and
195
00:09:42,280 --> 00:09:44,360
how recent the training must be.
196
00:09:44,360 --> 00:09:46,200
Verified ID checks whether the proof is genuine.
197
00:09:46,200 --> 00:09:50,160
It does not replace the organization's judgment about what proof it should require.
198
00:09:50,160 --> 00:09:51,440
There is one more question though.
199
00:09:51,440 --> 00:09:55,520
Assigned credential can prove that the training record is real, but a phone can be lost, borrowed,
200
00:09:55,520 --> 00:09:56,520
or stolen.
201
00:09:56,520 --> 00:10:00,160
How do you check that the person presenting the credential is the person shown in it?
202
00:10:00,160 --> 00:10:02,520
That is where face check enters the picture.
203
00:10:02,520 --> 00:10:03,520
Face check.
204
00:10:03,520 --> 00:10:05,080
When the proof must match the person.
205
00:10:05,080 --> 00:10:07,000
So you've got a training credential.
206
00:10:07,000 --> 00:10:09,720
It's genuine, current, and issued by a provider you trust.
207
00:10:09,720 --> 00:10:11,240
But that still leaves one question.
208
00:10:11,240 --> 00:10:12,840
Is Alex the person holding the phone?
209
00:10:12,840 --> 00:10:15,880
For many everyday checks, the credential alone might be enough.
210
00:10:15,880 --> 00:10:20,120
A low risk request doesn't always need another layer, but some moments carry more risk,
211
00:10:20,120 --> 00:10:24,640
like recovering a locked account, approving access to customer data, or granting a privileged
212
00:10:24,640 --> 00:10:25,640
admin role.
213
00:10:25,640 --> 00:10:30,040
A lost phone creates risk, so does a borrowed phone, and a attacker could try to use a photo,
214
00:10:30,040 --> 00:10:33,320
a recorded video, or a convincing deepfake during a remote check.
215
00:10:33,320 --> 00:10:34,920
The credential proof the record is real.
216
00:10:34,920 --> 00:10:38,800
It does not automatically prove the presenter is the person named on that record.
217
00:10:38,800 --> 00:10:42,760
That's where Microsoft Entra verified ID can add face check for those higher risk moments.
218
00:10:42,760 --> 00:10:45,280
Face check asks the person to take a live selfie.
219
00:10:45,280 --> 00:10:49,000
Then it compares that selfie with the photo stored inside the verified ID credential.
220
00:10:49,000 --> 00:10:50,800
Think of the two checks as separate jobs.
221
00:10:50,800 --> 00:10:52,720
Credential verification checks the proof.
222
00:10:52,720 --> 00:10:55,120
Face check checks the person presenting the proof.
223
00:10:55,120 --> 00:10:59,200
When both checks pass, the organization has stronger confidence that the person making
224
00:10:59,200 --> 00:11:02,160
the request matches the person connected to the credential.
225
00:11:02,160 --> 00:11:05,680
This fits naturally into remote onboarding, a new employee may need access before they
226
00:11:05,680 --> 00:11:07,160
ever enter an office.
227
00:11:07,160 --> 00:11:10,960
Instead of relying only on a video call and an emailed document, the organization can
228
00:11:10,960 --> 00:11:15,200
request a credential, and, where the risk calls for it, ask for a face check.
229
00:11:15,200 --> 00:11:17,280
The same ID applies to account recovery.
230
00:11:17,280 --> 00:11:20,720
If someone loses their phone and all their usual sign-in methods, the organization should
231
00:11:20,720 --> 00:11:24,640
not simply accept a support request because the caller knows a few personal details.
232
00:11:24,640 --> 00:11:28,120
A higher assurance check can happen before the organization creates a temporary path
233
00:11:28,120 --> 00:11:29,360
back into the account.
234
00:11:29,360 --> 00:11:31,720
Help desk staff gain a more consistent process.
235
00:11:31,720 --> 00:11:35,640
The person requesting help follows the same guided check rather than asking an agent to
236
00:11:35,640 --> 00:11:39,560
judge a voice, a screenshot, or a story under pressure.
237
00:11:39,560 --> 00:11:42,200
Face check can also fit requests for sensitive access.
238
00:11:42,200 --> 00:11:46,280
If someone asks to manage a system, view protected records, or take on a powerful role, the
239
00:11:46,280 --> 00:11:49,720
added check helps confirm that the request comes from the intended person.
240
00:11:49,720 --> 00:11:51,000
But you shouldn't use it everywhere.
241
00:11:51,000 --> 00:11:54,520
You probably don't need a live selfie just to open a routine document or join an ordinary
242
00:11:54,520 --> 00:11:55,520
team.
243
00:11:55,520 --> 00:11:59,360
The check set effort and people notice that effort, use face check when the cost of impersonation
244
00:11:59,360 --> 00:12:01,240
justifies the extra step.
245
00:12:01,240 --> 00:12:03,280
There are a few practical details behind this.
246
00:12:03,280 --> 00:12:06,840
The credential needs a photo claim that can act as the reference image.
247
00:12:06,840 --> 00:12:09,560
That photo needs to be clear enough for the comparison to work.
248
00:12:09,560 --> 00:12:13,960
The verification flow must support face check, and your organization may need extra setup
249
00:12:13,960 --> 00:12:17,520
and Azure subscription and the right licensing for the scenario.
250
00:12:17,520 --> 00:12:20,040
Privacy also needs a clear place in the design.
251
00:12:20,040 --> 00:12:22,680
Face check exists to support a decision at a higher risk moment.
252
00:12:22,680 --> 00:12:25,800
It's not a reason to collect face data for every normal task.
253
00:12:25,800 --> 00:12:29,720
Tell people why the check is happening, what it checks, and what happens if it can't be
254
00:12:29,720 --> 00:12:30,720
completed.
255
00:12:30,720 --> 00:12:33,480
That keeps the process fair and easier to trust.
256
00:12:33,480 --> 00:12:37,360
Once you combine signed credentials with a person check only where needed, you can use
257
00:12:37,360 --> 00:12:45,120
verified ID in familiar work situations, without turning every task into an identity test.
258
00:12:45,120 --> 00:12:46,120
Where it fits?
259
00:12:46,120 --> 00:12:48,560
Four practical Microsoft 365 scenarios.
260
00:12:48,560 --> 00:12:51,360
So where does this fit into normal Microsoft 365 work?
261
00:12:51,360 --> 00:12:53,160
Let's look at four practical scenarios.
262
00:12:53,160 --> 00:12:54,160
First, remote onboarding.
263
00:12:54,160 --> 00:12:58,320
A new employee may need a laptop, a work account, and access to a few systems before their
264
00:12:58,320 --> 00:12:59,320
first day.
265
00:12:59,320 --> 00:13:04,040
If the company uses a trusted identity verification partner, that person can complete an identity
266
00:13:04,040 --> 00:13:07,560
check and receive a credential before the normal account setup begins.
267
00:13:07,560 --> 00:13:11,000
The hiring team gets a stronger check than an emailed photo of an ID card.
268
00:13:11,000 --> 00:13:15,320
The new employee also avoids sending the same documents through several mailboxes.
269
00:13:15,320 --> 00:13:19,320
Once the company confirms the person and creates the right account, the usual EntraID
270
00:13:19,320 --> 00:13:24,400
sign-in, MFA, Intune device setup, and Microsoft 365 access still take over.
271
00:13:24,400 --> 00:13:25,920
Second, account recovery.
272
00:13:25,920 --> 00:13:28,040
Imagine someone loses their phone while traveling.
273
00:13:28,040 --> 00:13:32,320
Their passkey, authenticator approvals, and backup methods are all unavailable.
274
00:13:32,320 --> 00:13:36,320
They need a safe way back into their account, but the help desk should not reset access based
275
00:13:36,320 --> 00:13:38,800
on a few answers that an attacker may already know.
276
00:13:38,800 --> 00:13:42,680
A verified identity check can sit before that recovery step.
277
00:13:42,680 --> 00:13:46,160
After the person proves who they are through an approved identity flow, the organization
278
00:13:46,160 --> 00:13:50,520
can issue a temporary access path or guide them through registering new sign-in methods.
279
00:13:50,520 --> 00:13:54,000
That removes some pressure from the help desk while keeping the recovery decision tied to
280
00:13:54,000 --> 00:13:55,000
better evidence.
281
00:13:55,000 --> 00:13:57,240
Third, secure access to work resources.
282
00:13:57,240 --> 00:14:00,160
Many people assume access depends only on whether you are an employee.
283
00:14:00,160 --> 00:14:02,560
Often, that's only part of the decision.
284
00:14:02,560 --> 00:14:05,600
Someone may work for the company, but still need current training before they can join
285
00:14:05,600 --> 00:14:08,040
a team that handles customer data.
286
00:14:08,040 --> 00:14:11,720
Microsoft Entra access packages can bring this into a clear request process.
287
00:14:11,720 --> 00:14:16,120
An access package can contain a Microsoft Teams team, a SharePoint site, an enterprise app,
288
00:14:16,120 --> 00:14:17,720
or even an Entra role.
289
00:14:17,720 --> 00:14:21,480
Before someone receives that package, the policy can ask for a specific credential from
290
00:14:21,480 --> 00:14:23,600
an issuer, the organization trusts.
291
00:14:23,600 --> 00:14:27,000
So the person signs in as normal, then they present proof that they completed the required
292
00:14:27,000 --> 00:14:28,000
training.
293
00:14:28,000 --> 00:14:31,720
If the access package needs higher assurance, it can also require face check.
294
00:14:31,720 --> 00:14:35,600
The request can move forward automatically when the policy checks pass, or it can go
295
00:14:35,600 --> 00:14:38,320
to an approver with the proof attached to the request.
296
00:14:38,320 --> 00:14:41,640
That turns a messy approval process into a defined rule.
297
00:14:41,640 --> 00:14:43,520
Both, people outside your organization.
298
00:14:43,520 --> 00:14:46,160
A contractor may need access to a supplier portal.
299
00:14:46,160 --> 00:14:50,200
A student may need to prove enrollment, and applicant may need to prove a qualification
300
00:14:50,200 --> 00:14:52,360
before an interview process continues.
301
00:14:52,360 --> 00:14:56,000
None of those people need a full internal account just to establish one fact.
302
00:14:56,000 --> 00:14:58,800
They can present a credential from an organization you trust.
303
00:14:58,800 --> 00:15:02,800
That matters because creating guest accounts for every early stage interaction adds work,
304
00:15:02,800 --> 00:15:04,920
and leaves more accounts to manage later.
305
00:15:04,920 --> 00:15:07,600
Sometimes you need an account for ongoing collaboration.
306
00:15:07,600 --> 00:15:10,240
Sometimes you only need a verified fact for one decision.
307
00:15:10,240 --> 00:15:12,120
Accounting certificates are a good example.
308
00:15:12,120 --> 00:15:14,280
Alex needs access to a restricted project.
309
00:15:14,280 --> 00:15:18,200
The project requires current data handling training from an approved provider.
310
00:15:18,200 --> 00:15:22,040
Alex completes the course, receives the course credential, and starts the access request.
311
00:15:22,040 --> 00:15:24,080
The system requests that credential.
312
00:15:24,080 --> 00:15:26,120
Alex approves the request in authentication.
313
00:15:26,120 --> 00:15:30,520
If the project handles highly sensitive information, face check can confirm that Alex is presenting
314
00:15:30,520 --> 00:15:31,520
the credential.
315
00:15:31,520 --> 00:15:35,200
The access package then checks the issuer, the course claim, and the expiry date before
316
00:15:35,200 --> 00:15:36,360
the request moves on.
317
00:15:36,360 --> 00:15:39,520
No PDF chasing, no manual comparison of course records.
318
00:15:39,520 --> 00:15:43,920
The company receives the proof it asked for, while Alex stays in control of presenting it.
319
00:15:43,920 --> 00:15:47,680
These situations work best when the credential solves a real decision problem rather than
320
00:15:47,680 --> 00:15:51,720
becoming another check people must complete for no clear reason.
321
00:15:51,720 --> 00:15:53,520
What to plan before you turn it on?
322
00:15:53,520 --> 00:15:56,400
Start with a problem that already costs you time or creates risk.
323
00:15:56,400 --> 00:15:59,560
Maybe your help desk gets buried in password recovery requests.
324
00:15:59,560 --> 00:16:03,000
Maybe contractors, email certificates that manages have to review manually.
325
00:16:03,000 --> 00:16:06,800
Maybe a sensitive sharepoint site needs proof of current training before anyone can join.
326
00:16:06,800 --> 00:16:11,080
Take one of those scenarios, don't kick off a broad project called digital identity, because
327
00:16:11,080 --> 00:16:14,480
that makes it nearly impossible to define what success looks like.
328
00:16:14,480 --> 00:16:17,280
Next, decide who has the authority to issue the proof.
329
00:16:17,280 --> 00:16:21,440
Your own organization might issue an employee credential straight from EntraID data.
330
00:16:21,440 --> 00:16:23,680
A training provider might issue a course credential.
331
00:16:23,680 --> 00:16:27,600
For identity proofing, you could use an approved partner that checks government ID documents.
332
00:16:27,600 --> 00:16:31,120
The verifier has to trust that issuer before the flow can work.
333
00:16:31,120 --> 00:16:35,240
Then define the credentials life, which claims should it contain, how long should it stay
334
00:16:35,240 --> 00:16:39,400
valid, who can receive it, who can ask for it, what happens when the training expires
335
00:16:39,400 --> 00:16:42,120
the person changes jobs or a contractor leaves.
336
00:16:42,120 --> 00:16:46,840
A credential that never expires becomes a problem when the fact it confirms no longer applies.
337
00:16:46,840 --> 00:16:48,600
The user journey needs planning too.
338
00:16:48,600 --> 00:16:52,000
People need Microsoft Authenticator on a supported phone, clear instructions for receiving
339
00:16:52,000 --> 00:16:55,680
and presenting a credential in a support path when they switch or lose a device.
340
00:16:55,680 --> 00:16:59,520
Don't assume everyone has the same phone access or feels confident with QR codes.
341
00:16:59,520 --> 00:17:01,720
The verification flow itself needs protection.
342
00:17:01,720 --> 00:17:04,680
Each request should connect to one user session.
343
00:17:04,680 --> 00:17:09,280
Keep requests short-lived and single use, so an old request can't be reused later.
344
00:17:09,280 --> 00:17:12,920
Your app should treat the successful result as part of that one transaction, not as a general
345
00:17:12,920 --> 00:17:14,760
path someone can replay elsewhere.
346
00:17:14,760 --> 00:17:18,640
For setup, your organization needs a verified custom domain in EntraID.
347
00:17:18,640 --> 00:17:23,120
That confirms you control the organization name behind the credential and its requests.
348
00:17:23,120 --> 00:17:27,160
Microsoft's quick setup can create a ready-made, verified employee credential, which gives
349
00:17:27,160 --> 00:17:29,720
many organizations a practical starting point.
350
00:17:29,720 --> 00:17:33,320
You can then control which users can receive it and adjust the experience to match your
351
00:17:33,320 --> 00:17:34,320
needs.
352
00:17:34,320 --> 00:17:36,520
Keep the governance question in view.
353
00:17:36,520 --> 00:17:39,880
When the relationship changes, who removes or withdraws the proof?
354
00:17:39,880 --> 00:17:44,640
That question often decides whether a verified ID design remains useful after the first demo.
355
00:17:44,640 --> 00:17:50,200
Microsoft Entra, Verified ID, gives trusted organizations a way to issue digital proof that people
356
00:17:50,200 --> 00:17:52,280
keep and share from their own wallet.
357
00:17:52,280 --> 00:17:55,200
Use Entra ID, MFA and pass keys for sign-in.
358
00:17:55,200 --> 00:17:59,120
Add verified ID when a decision depends on a trusted fact about the person, like current
359
00:17:59,120 --> 00:18:03,040
employment, completed training or confirmed identity during recovery.
360
00:18:03,040 --> 00:18:07,000
Try one practical exercise this week, find one manual identity check in your business.
361
00:18:07,000 --> 00:18:10,680
Write down the claim you need, name the organization that should issue it, and decide whether
362
00:18:10,680 --> 00:18:12,640
face check belongs in that moment.
363
00:18:12,640 --> 00:18:17,280
The next knowledge nugget will cover "access packages", where that proof can control access
364
00:18:17,280 --> 00:18:19,920
to Teams, SharePoint, Applications and Entra roles.
00:00:00,000 --> 00:00:04,080
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365.
2
00:00:04,080 --> 00:00:06,000
FM, I'm your host, Mirko Peters.
3
00:00:06,000 --> 00:00:10,760
Today's topic is one that almost everyone has heard of, but few people truly understand.
4
00:00:10,760 --> 00:00:12,560
Proving who you are beyond just signing in.
5
00:00:12,560 --> 00:00:16,320
You can have strong sign in security, you can use MFA, you can use a pass key instead of
6
00:00:16,320 --> 00:00:17,320
a pass word.
7
00:00:17,320 --> 00:00:20,240
But here's the thing, none of that automatically proves who sits behind the screen.
8
00:00:20,240 --> 00:00:22,360
It doesn't prove whether they still work for a company.
9
00:00:22,360 --> 00:00:25,720
It doesn't prove whether they completed the training needed for a sensitive project.
10
00:00:25,720 --> 00:00:26,960
Think about these situations.
11
00:00:26,960 --> 00:00:29,440
A help desk agent gets a call from someone locked out.
12
00:00:29,440 --> 00:00:33,760
A remote new hire needs equipment, a contractor needs access, an applicant has no company
13
00:00:33,760 --> 00:00:34,760
account yet.
14
00:00:34,760 --> 00:00:37,320
Those situations need more than a successful sign in.
15
00:00:37,320 --> 00:00:39,400
They need proof of a real world fact.
16
00:00:39,400 --> 00:00:44,280
By the end of this episode, you'll understand Microsoft Entra verified ID in plain English.
17
00:00:44,280 --> 00:00:47,080
You'll see how a digital wallet fits into the process.
18
00:00:47,080 --> 00:00:51,680
And you'll learn why an organization can often check a credential without calling the organization
19
00:00:51,680 --> 00:00:52,680
that issued it.
20
00:00:52,680 --> 00:00:54,240
Grab your coffee and let's dive in.
21
00:00:54,240 --> 00:00:55,480
Let's start with the problem.
22
00:00:55,480 --> 00:00:59,040
The old way of checking identity still creates a lot of risk.
23
00:00:59,040 --> 00:01:02,160
The problem identity checks still depend on manual trust.
24
00:01:02,160 --> 00:01:05,480
Imagine you need to prove that you completed data handling training before you can join
25
00:01:05,480 --> 00:01:06,480
a project team.
26
00:01:06,480 --> 00:01:07,800
Here's how it usually works.
27
00:01:07,800 --> 00:01:11,800
You download a certificate as a PDF, you attach it to an email, someone opens it, checks
28
00:01:11,800 --> 00:01:15,280
the name, checks the date, and decides whether it looks right.
29
00:01:15,280 --> 00:01:17,640
Sometimes that proof arrives as a screenshot.
30
00:01:17,640 --> 00:01:20,280
Sometimes it arrives through a shared spreadsheet.
31
00:01:20,280 --> 00:01:24,520
Sometimes a manager gets a message in team saying, yes, this person finished the course.
32
00:01:24,520 --> 00:01:25,520
The work gets done.
33
00:01:25,520 --> 00:01:28,600
But the proof travels around as loose files and informal messages.
34
00:01:28,600 --> 00:01:31,800
People must decide what to trust, often while they're busy with other work.
35
00:01:31,800 --> 00:01:33,520
That creates two problems at once.
36
00:01:33,520 --> 00:01:35,440
First, documents are easy to copy and change.
37
00:01:35,440 --> 00:01:39,360
A PDF can look convincing even when the course expired, the person never took it, or the
38
00:01:39,360 --> 00:01:41,320
certificate belongs to someone else.
39
00:01:41,320 --> 00:01:45,480
Second, the organization collecting that proof may receive far more personal data than it
40
00:01:45,480 --> 00:01:46,480
needs.
41
00:01:46,480 --> 00:01:50,280
A copy of a passport, a driver's license, or a student record often contains details
42
00:01:50,280 --> 00:01:52,560
that have nothing to do with the decision being made.
43
00:01:52,560 --> 00:01:54,880
You might only need to know that someone completed a course.
44
00:01:54,880 --> 00:01:58,520
Instead, you receive a full document and now need to store it, protect it, and decide
45
00:01:58,520 --> 00:01:59,680
how long to keep it.
46
00:01:59,680 --> 00:02:01,760
The pressure gets even worse at the help desk.
47
00:02:01,760 --> 00:02:05,760
Picture someone calling because they lost their phone, can't use their MFA method, and
48
00:02:05,760 --> 00:02:07,280
can't get into their work account.
49
00:02:07,280 --> 00:02:10,000
The caller might know their name, job title, and employee number.
50
00:02:10,000 --> 00:02:12,520
They might even sound like the person they claim to be.
51
00:02:12,520 --> 00:02:15,200
But a skilled attacker can know those details too.
52
00:02:15,200 --> 00:02:19,480
With AI voice tools and deepfake video, a calm voice on a call or a familiar face in
53
00:02:19,480 --> 00:02:23,080
a video meeting no longer gives staff enough confidence on its own.
54
00:02:23,080 --> 00:02:26,560
The help desk agent ends up making a high-risk decision under time pressure.
55
00:02:26,560 --> 00:02:28,920
If they refuse a genuine employee, work stops.
56
00:02:28,920 --> 00:02:33,840
If they approve the wrong person, an attacker may gain access to email files, teams, chats,
57
00:02:33,840 --> 00:02:35,400
or customer data.
58
00:02:35,400 --> 00:02:38,160
Many organizations also hold proof in separate places.
59
00:02:38,160 --> 00:02:42,320
HR knows whether someone works there, a training provider knows whether they pass the course.
60
00:02:42,320 --> 00:02:44,160
A university knows whether they study there.
61
00:02:44,160 --> 00:02:47,640
A licensing body knows whether a qualification remains current.
62
00:02:47,640 --> 00:02:51,240
When another organization needs one of those facts, it often asks for a document sends
63
00:02:51,240 --> 00:02:52,800
an email or makes a phone call.
64
00:02:52,800 --> 00:02:55,240
It's slow, hard to scale, easy to get wrong.
65
00:02:55,240 --> 00:02:56,680
Now let's clear up a common myth.
66
00:02:56,680 --> 00:02:58,680
MFA doesn't solve this specific problem.
67
00:02:58,680 --> 00:03:03,000
MFA proves that someone controls a sign-in method, such as an authenticate or prompt, phone
68
00:03:03,000 --> 00:03:04,000
or pasky.
69
00:03:04,000 --> 00:03:05,880
That is still a strong and useful check.
70
00:03:05,880 --> 00:03:09,160
But it doesn't prove that the person completed safety training yesterday, it doesn't
71
00:03:09,160 --> 00:03:11,760
prove that a contractor still works for an approved supplier.
72
00:03:11,760 --> 00:03:15,360
And it doesn't prove that an applicant without an intro account is qualified for the role.
73
00:03:15,360 --> 00:03:18,880
The check needs to move away from a person's account and to what a signed claim about that
74
00:03:18,880 --> 00:03:19,880
person.
75
00:03:19,880 --> 00:03:23,040
A verified ID comes in, but we'll cover that in the next nugget.
76
00:03:23,040 --> 00:03:25,600
What Microsoft Entra Verified ID actually is.
77
00:03:25,600 --> 00:03:27,720
So what is Microsoft Entra Verified ID?
78
00:03:27,720 --> 00:03:31,800
In plain English, it's Microsoft service for issuing and verifying digital credentials.
79
00:03:31,800 --> 00:03:35,200
A credential is like a signed digital card that proves a specific fact about you.
80
00:03:35,200 --> 00:03:38,480
Think of Microsoft Entra ID as the reception desk in an office building.
81
00:03:38,480 --> 00:03:41,680
It checks your sign-in and decides whether you can enter the building.
82
00:03:41,680 --> 00:03:44,480
Verified ID is more like a signed card you carry after your inside.
83
00:03:44,480 --> 00:03:48,760
That card might show you an employee, or that you completed a course, hold a license,
84
00:03:48,760 --> 00:03:51,480
yet a university, or work for an approved supplier.
85
00:03:51,480 --> 00:03:53,880
The card includes details called claims.
86
00:03:53,880 --> 00:03:58,120
Those are just the facts written on it, like your name, employee number, job title, course
87
00:03:58,120 --> 00:04:02,040
name, student status, a photo, and the issue and expiry dates.
88
00:04:02,040 --> 00:04:04,760
The organization decides which claims go on the credential.
89
00:04:04,760 --> 00:04:08,920
A training company might issue a credential saying you completed a data handling course,
90
00:04:08,920 --> 00:04:12,720
valid until a certain date, and it doesn't need your home address or phone number, just
91
00:04:12,720 --> 00:04:14,040
the essential facts.
92
00:04:14,040 --> 00:04:16,440
That small amount of shared data is the whole point.
93
00:04:16,440 --> 00:04:19,600
Your Microsoft Authenticator app can hold these credentials on your phone.
94
00:04:19,600 --> 00:04:23,720
Think of it as a digital wallet, but for work and identity proofs instead of payment cards.
95
00:04:23,720 --> 00:04:27,920
You can open the credential and see who issued it, what it says about you, when it expires,
96
00:04:27,920 --> 00:04:29,160
and where you've used it.
97
00:04:29,160 --> 00:04:32,520
The credential belongs to you in your wallet, but that doesn't mean you can edit it.
98
00:04:32,520 --> 00:04:36,120
You can't change training completed to training completed with distinction anymore than
99
00:04:36,120 --> 00:04:38,560
you can rewrite a badge printed by your employer.
100
00:04:38,560 --> 00:04:42,920
The issuing organization signs the credential, and that signature protects the information
101
00:04:42,920 --> 00:04:47,040
inside if someone changes the data, the check fails.
102
00:04:47,040 --> 00:04:50,120
This is where the word decentralized often confuses people.
103
00:04:50,120 --> 00:04:52,360
It doesn't mean there's no organization in charge.
104
00:04:52,360 --> 00:04:56,000
It means the proof doesn't have to live in one central system that every other organization
105
00:04:56,000 --> 00:04:57,000
must call.
106
00:04:57,000 --> 00:05:01,200
One organization issues the proof you hold it, and another organization can check it.
107
00:05:01,200 --> 00:05:04,720
The issue could be your employer, a school, a training provider, a professional body,
108
00:05:04,720 --> 00:05:06,680
or an identity verification partner.
109
00:05:06,680 --> 00:05:11,120
The holder is you, and the verifier is the organization asking whether a claim is valid.
110
00:05:11,120 --> 00:05:15,600
The approved Entra Verified ID manages the technology around that exchange, so organizations
111
00:05:15,600 --> 00:05:20,520
can issue and request these signed credentials without building the whole system from scratch.
112
00:05:20,520 --> 00:05:23,120
How does the verifier know the card is real?
113
00:05:23,120 --> 00:05:25,200
It checks several things behind the scenes.
114
00:05:25,200 --> 00:05:29,280
The issuer identity and the organization's verified domain, the digital signature to make
115
00:05:29,280 --> 00:05:33,520
sure it came from that issuer and hasn't changed, whether the credential is still within
116
00:05:33,520 --> 00:05:37,040
its valid date range and whether the issuer has revoked it.
117
00:05:37,040 --> 00:05:40,840
So if a contractor leaves a supplier, the supplier can revoke the credential and a verifier
118
00:05:40,840 --> 00:05:43,920
checking it later will see that it should no longer be accepted.
119
00:05:43,920 --> 00:05:47,960
That's why a verifier often doesn't need to phone the issuer or send an email asking,
120
00:05:47,960 --> 00:05:49,760
is this certificate still good?
121
00:05:49,760 --> 00:05:53,560
The proof carries a signed record, and the verification process checks whether that record
122
00:05:53,560 --> 00:05:55,160
still holds up.
123
00:05:55,160 --> 00:05:57,360
Notice what Verified ID does not replace.
124
00:05:57,360 --> 00:06:00,640
It doesn't replace your password, pass key, or MFA method.
125
00:06:00,640 --> 00:06:04,320
It doesn't replace single sign-on, and it's not a live employee directory that updates
126
00:06:04,320 --> 00:06:06,480
every second with HR changes.
127
00:06:06,480 --> 00:06:10,760
Microsoft Entra ID still handles sign-in, creating the account-based control around apps,
128
00:06:10,760 --> 00:06:13,400
teams, SharePoint, and Microsoft 365.
129
00:06:13,400 --> 00:06:15,320
Verified ID adds a different kind of proof.
130
00:06:15,320 --> 00:06:19,120
It says that a trusted organization confirmed a specific fact about a person at a specific
131
00:06:19,120 --> 00:06:23,960
time with an expiry date and a way to withdraw that proof if circumstances change.
132
00:06:23,960 --> 00:06:27,040
That gives you a much clearer question to ask, who issued the proof?
133
00:06:27,040 --> 00:06:29,960
What exactly does it confirm and should we trust it for this decision?
134
00:06:29,960 --> 00:06:32,760
Once you see that, the whole model becomes easier.
135
00:06:32,760 --> 00:06:36,920
Every verified ID journey has three people, or roles, involved.
136
00:06:36,920 --> 00:06:40,160
The three roles, issuer, holder, and verifier.
137
00:06:40,160 --> 00:06:42,720
Every verified ID exchange has three roles.
138
00:06:42,720 --> 00:06:47,600
The issuer creates the credential, the holder keeps it, and the verifier asks to see it.
139
00:06:47,600 --> 00:06:50,720
That's the whole pattern, and once you know those three roles, the technical term stop
140
00:06:50,720 --> 00:06:51,800
getting in the way.
141
00:06:51,800 --> 00:06:55,320
The issuer is the organization that can honestly confirm a fact.
142
00:06:55,320 --> 00:06:58,280
Your employer can issue a credential, confirming you work there.
143
00:06:58,280 --> 00:07:02,720
A university can confirm you're a student, a training provider can confirm you completed
144
00:07:02,720 --> 00:07:03,720
a course.
145
00:07:03,720 --> 00:07:08,400
A professional body can confirm your license is current, and in some cases, an identity
146
00:07:08,400 --> 00:07:13,960
verification partner can check a government ID and issue a credential based on that.
147
00:07:13,960 --> 00:07:17,200
The issuer doesn't just fill in a card with whatever someone asks for.
148
00:07:17,200 --> 00:07:22,320
It first checks the source it trusts, like an HR record, a course result, a student system,
149
00:07:22,320 --> 00:07:26,160
or an identity check, and then creates the credential with the claims that match that
150
00:07:26,160 --> 00:07:27,160
decision.
151
00:07:27,160 --> 00:07:30,200
The issuer also decides how long the credential should remain valid.
152
00:07:30,200 --> 00:07:33,840
A course certificate might last a year, and employee credential might end when employment
153
00:07:33,840 --> 00:07:34,840
ends.
154
00:07:34,840 --> 00:07:36,680
A visitor pass might last only one day.
155
00:07:36,680 --> 00:07:39,400
That time limit matters because the fact can change.
156
00:07:39,400 --> 00:07:44,160
Someone may leave the company, a qualification may expire, or a course may need renewal.
157
00:07:44,160 --> 00:07:45,920
The holder is the person named in the credential.
158
00:07:45,920 --> 00:07:50,040
They accept it into Microsoft Authenticator where they can see who issued it, what information
159
00:07:50,040 --> 00:07:52,440
it contains, and the issue and expiry dates.
160
00:07:52,440 --> 00:07:54,840
The holder has control at the point of sharing.
161
00:07:54,840 --> 00:07:58,520
If an organization requests a credential, the person can review the request and choose
162
00:07:58,520 --> 00:08:00,040
to approve or decline.
163
00:08:00,040 --> 00:08:01,880
That consent step is worth posing on.
164
00:08:01,880 --> 00:08:05,480
A credential doesn't give every organization automatic access to your information.
165
00:08:05,480 --> 00:08:11,240
A verifier must ask for the proof, and the holder sees that request before anything is shared.
166
00:08:11,240 --> 00:08:15,360
Authenticator also keeps a record of credential activity, so the holder can look back at where
167
00:08:15,360 --> 00:08:16,600
it was presented.
168
00:08:16,600 --> 00:08:20,240
The verifier is the organization that needs proof for a particular decision.
169
00:08:20,240 --> 00:08:24,360
An employer deciding whether to grant access to a sensitive project, a help desk, checking
170
00:08:24,360 --> 00:08:28,400
someone before starting an account recovery, a hiring company confirming an applicant's
171
00:08:28,400 --> 00:08:32,680
qualification, or a partner organization needing proof that a contractor belongs to an
172
00:08:32,680 --> 00:08:33,880
approved supplier.
173
00:08:33,880 --> 00:08:37,920
To use a simple workplace example, Alex needs access to a project that handles customer
174
00:08:37,920 --> 00:08:38,920
data.
175
00:08:38,920 --> 00:08:42,040
Before joining, the company requires approved data handling training.
176
00:08:42,040 --> 00:08:45,520
Alex completes the course through an outside training provider, which checks the result
177
00:08:45,520 --> 00:08:47,040
and issues a training credential.
178
00:08:47,040 --> 00:08:49,280
Alex accepts it into Microsoft Authenticator.
179
00:08:49,280 --> 00:08:54,160
Later, Alex opens the company's access request page and asks to join the project.
180
00:08:54,160 --> 00:08:55,920
The page shows a QR code.
181
00:08:55,920 --> 00:08:59,960
Alex scans it with Authenticator and sees a request to present the training credential.
182
00:08:59,960 --> 00:09:03,840
The app shows which organization is asking and what information it wants.
183
00:09:03,840 --> 00:09:05,600
Alex reviews the request and approves it.
184
00:09:05,600 --> 00:09:09,240
The training credential stays in Alex's wallet and the company receives the approved claim
185
00:09:09,240 --> 00:09:14,240
data needed for its decision rather than an emailed PDF that could be copied, forwarded,
186
00:09:14,240 --> 00:09:15,800
or stored forever.
187
00:09:15,800 --> 00:09:17,760
That gives the verifier a cleaner process.
188
00:09:17,760 --> 00:09:21,800
It checks that the credential came from the expected issuer, verifies the signature, and
189
00:09:21,800 --> 00:09:24,160
checks whether it has expired or been revoked.
190
00:09:24,160 --> 00:09:27,800
If all those checks pass, the company can move Alex's access request forward.
191
00:09:27,800 --> 00:09:31,440
No one needs to search an inbox for a certificate, call the training provider and wait for
192
00:09:31,440 --> 00:09:35,160
a reply or decide whether a screenshot looks believable.
193
00:09:35,160 --> 00:09:37,920
The verifier still needs to make a sensible policy decision.
194
00:09:37,920 --> 00:09:42,280
It must decide which training provider it trusts, which credential type it accepts, and
195
00:09:42,280 --> 00:09:44,360
how recent the training must be.
196
00:09:44,360 --> 00:09:46,200
Verified ID checks whether the proof is genuine.
197
00:09:46,200 --> 00:09:50,160
It does not replace the organization's judgment about what proof it should require.
198
00:09:50,160 --> 00:09:51,440
There is one more question though.
199
00:09:51,440 --> 00:09:55,520
Assigned credential can prove that the training record is real, but a phone can be lost, borrowed,
200
00:09:55,520 --> 00:09:56,520
or stolen.
201
00:09:56,520 --> 00:10:00,160
How do you check that the person presenting the credential is the person shown in it?
202
00:10:00,160 --> 00:10:02,520
That is where face check enters the picture.
203
00:10:02,520 --> 00:10:03,520
Face check.
204
00:10:03,520 --> 00:10:05,080
When the proof must match the person.
205
00:10:05,080 --> 00:10:07,000
So you've got a training credential.
206
00:10:07,000 --> 00:10:09,720
It's genuine, current, and issued by a provider you trust.
207
00:10:09,720 --> 00:10:11,240
But that still leaves one question.
208
00:10:11,240 --> 00:10:12,840
Is Alex the person holding the phone?
209
00:10:12,840 --> 00:10:15,880
For many everyday checks, the credential alone might be enough.
210
00:10:15,880 --> 00:10:20,120
A low risk request doesn't always need another layer, but some moments carry more risk,
211
00:10:20,120 --> 00:10:24,640
like recovering a locked account, approving access to customer data, or granting a privileged
212
00:10:24,640 --> 00:10:25,640
admin role.
213
00:10:25,640 --> 00:10:30,040
A lost phone creates risk, so does a borrowed phone, and a attacker could try to use a photo,
214
00:10:30,040 --> 00:10:33,320
a recorded video, or a convincing deepfake during a remote check.
215
00:10:33,320 --> 00:10:34,920
The credential proof the record is real.
216
00:10:34,920 --> 00:10:38,800
It does not automatically prove the presenter is the person named on that record.
217
00:10:38,800 --> 00:10:42,760
That's where Microsoft Entra verified ID can add face check for those higher risk moments.
218
00:10:42,760 --> 00:10:45,280
Face check asks the person to take a live selfie.
219
00:10:45,280 --> 00:10:49,000
Then it compares that selfie with the photo stored inside the verified ID credential.
220
00:10:49,000 --> 00:10:50,800
Think of the two checks as separate jobs.
221
00:10:50,800 --> 00:10:52,720
Credential verification checks the proof.
222
00:10:52,720 --> 00:10:55,120
Face check checks the person presenting the proof.
223
00:10:55,120 --> 00:10:59,200
When both checks pass, the organization has stronger confidence that the person making
224
00:10:59,200 --> 00:11:02,160
the request matches the person connected to the credential.
225
00:11:02,160 --> 00:11:05,680
This fits naturally into remote onboarding, a new employee may need access before they
226
00:11:05,680 --> 00:11:07,160
ever enter an office.
227
00:11:07,160 --> 00:11:10,960
Instead of relying only on a video call and an emailed document, the organization can
228
00:11:10,960 --> 00:11:15,200
request a credential, and, where the risk calls for it, ask for a face check.
229
00:11:15,200 --> 00:11:17,280
The same ID applies to account recovery.
230
00:11:17,280 --> 00:11:20,720
If someone loses their phone and all their usual sign-in methods, the organization should
231
00:11:20,720 --> 00:11:24,640
not simply accept a support request because the caller knows a few personal details.
232
00:11:24,640 --> 00:11:28,120
A higher assurance check can happen before the organization creates a temporary path
233
00:11:28,120 --> 00:11:29,360
back into the account.
234
00:11:29,360 --> 00:11:31,720
Help desk staff gain a more consistent process.
235
00:11:31,720 --> 00:11:35,640
The person requesting help follows the same guided check rather than asking an agent to
236
00:11:35,640 --> 00:11:39,560
judge a voice, a screenshot, or a story under pressure.
237
00:11:39,560 --> 00:11:42,200
Face check can also fit requests for sensitive access.
238
00:11:42,200 --> 00:11:46,280
If someone asks to manage a system, view protected records, or take on a powerful role, the
239
00:11:46,280 --> 00:11:49,720
added check helps confirm that the request comes from the intended person.
240
00:11:49,720 --> 00:11:51,000
But you shouldn't use it everywhere.
241
00:11:51,000 --> 00:11:54,520
You probably don't need a live selfie just to open a routine document or join an ordinary
242
00:11:54,520 --> 00:11:55,520
team.
243
00:11:55,520 --> 00:11:59,360
The check set effort and people notice that effort, use face check when the cost of impersonation
244
00:11:59,360 --> 00:12:01,240
justifies the extra step.
245
00:12:01,240 --> 00:12:03,280
There are a few practical details behind this.
246
00:12:03,280 --> 00:12:06,840
The credential needs a photo claim that can act as the reference image.
247
00:12:06,840 --> 00:12:09,560
That photo needs to be clear enough for the comparison to work.
248
00:12:09,560 --> 00:12:13,960
The verification flow must support face check, and your organization may need extra setup
249
00:12:13,960 --> 00:12:17,520
and Azure subscription and the right licensing for the scenario.
250
00:12:17,520 --> 00:12:20,040
Privacy also needs a clear place in the design.
251
00:12:20,040 --> 00:12:22,680
Face check exists to support a decision at a higher risk moment.
252
00:12:22,680 --> 00:12:25,800
It's not a reason to collect face data for every normal task.
253
00:12:25,800 --> 00:12:29,720
Tell people why the check is happening, what it checks, and what happens if it can't be
254
00:12:29,720 --> 00:12:30,720
completed.
255
00:12:30,720 --> 00:12:33,480
That keeps the process fair and easier to trust.
256
00:12:33,480 --> 00:12:37,360
Once you combine signed credentials with a person check only where needed, you can use
257
00:12:37,360 --> 00:12:45,120
verified ID in familiar work situations, without turning every task into an identity test.
258
00:12:45,120 --> 00:12:46,120
Where it fits?
259
00:12:46,120 --> 00:12:48,560
Four practical Microsoft 365 scenarios.
260
00:12:48,560 --> 00:12:51,360
So where does this fit into normal Microsoft 365 work?
261
00:12:51,360 --> 00:12:53,160
Let's look at four practical scenarios.
262
00:12:53,160 --> 00:12:54,160
First, remote onboarding.
263
00:12:54,160 --> 00:12:58,320
A new employee may need a laptop, a work account, and access to a few systems before their
264
00:12:58,320 --> 00:12:59,320
first day.
265
00:12:59,320 --> 00:13:04,040
If the company uses a trusted identity verification partner, that person can complete an identity
266
00:13:04,040 --> 00:13:07,560
check and receive a credential before the normal account setup begins.
267
00:13:07,560 --> 00:13:11,000
The hiring team gets a stronger check than an emailed photo of an ID card.
268
00:13:11,000 --> 00:13:15,320
The new employee also avoids sending the same documents through several mailboxes.
269
00:13:15,320 --> 00:13:19,320
Once the company confirms the person and creates the right account, the usual EntraID
270
00:13:19,320 --> 00:13:24,400
sign-in, MFA, Intune device setup, and Microsoft 365 access still take over.
271
00:13:24,400 --> 00:13:25,920
Second, account recovery.
272
00:13:25,920 --> 00:13:28,040
Imagine someone loses their phone while traveling.
273
00:13:28,040 --> 00:13:32,320
Their passkey, authenticator approvals, and backup methods are all unavailable.
274
00:13:32,320 --> 00:13:36,320
They need a safe way back into their account, but the help desk should not reset access based
275
00:13:36,320 --> 00:13:38,800
on a few answers that an attacker may already know.
276
00:13:38,800 --> 00:13:42,680
A verified identity check can sit before that recovery step.
277
00:13:42,680 --> 00:13:46,160
After the person proves who they are through an approved identity flow, the organization
278
00:13:46,160 --> 00:13:50,520
can issue a temporary access path or guide them through registering new sign-in methods.
279
00:13:50,520 --> 00:13:54,000
That removes some pressure from the help desk while keeping the recovery decision tied to
280
00:13:54,000 --> 00:13:55,000
better evidence.
281
00:13:55,000 --> 00:13:57,240
Third, secure access to work resources.
282
00:13:57,240 --> 00:14:00,160
Many people assume access depends only on whether you are an employee.
283
00:14:00,160 --> 00:14:02,560
Often, that's only part of the decision.
284
00:14:02,560 --> 00:14:05,600
Someone may work for the company, but still need current training before they can join
285
00:14:05,600 --> 00:14:08,040
a team that handles customer data.
286
00:14:08,040 --> 00:14:11,720
Microsoft Entra access packages can bring this into a clear request process.
287
00:14:11,720 --> 00:14:16,120
An access package can contain a Microsoft Teams team, a SharePoint site, an enterprise app,
288
00:14:16,120 --> 00:14:17,720
or even an Entra role.
289
00:14:17,720 --> 00:14:21,480
Before someone receives that package, the policy can ask for a specific credential from
290
00:14:21,480 --> 00:14:23,600
an issuer, the organization trusts.
291
00:14:23,600 --> 00:14:27,000
So the person signs in as normal, then they present proof that they completed the required
292
00:14:27,000 --> 00:14:28,000
training.
293
00:14:28,000 --> 00:14:31,720
If the access package needs higher assurance, it can also require face check.
294
00:14:31,720 --> 00:14:35,600
The request can move forward automatically when the policy checks pass, or it can go
295
00:14:35,600 --> 00:14:38,320
to an approver with the proof attached to the request.
296
00:14:38,320 --> 00:14:41,640
That turns a messy approval process into a defined rule.
297
00:14:41,640 --> 00:14:43,520
Both, people outside your organization.
298
00:14:43,520 --> 00:14:46,160
A contractor may need access to a supplier portal.
299
00:14:46,160 --> 00:14:50,200
A student may need to prove enrollment, and applicant may need to prove a qualification
300
00:14:50,200 --> 00:14:52,360
before an interview process continues.
301
00:14:52,360 --> 00:14:56,000
None of those people need a full internal account just to establish one fact.
302
00:14:56,000 --> 00:14:58,800
They can present a credential from an organization you trust.
303
00:14:58,800 --> 00:15:02,800
That matters because creating guest accounts for every early stage interaction adds work,
304
00:15:02,800 --> 00:15:04,920
and leaves more accounts to manage later.
305
00:15:04,920 --> 00:15:07,600
Sometimes you need an account for ongoing collaboration.
306
00:15:07,600 --> 00:15:10,240
Sometimes you only need a verified fact for one decision.
307
00:15:10,240 --> 00:15:12,120
Accounting certificates are a good example.
308
00:15:12,120 --> 00:15:14,280
Alex needs access to a restricted project.
309
00:15:14,280 --> 00:15:18,200
The project requires current data handling training from an approved provider.
310
00:15:18,200 --> 00:15:22,040
Alex completes the course, receives the course credential, and starts the access request.
311
00:15:22,040 --> 00:15:24,080
The system requests that credential.
312
00:15:24,080 --> 00:15:26,120
Alex approves the request in authentication.
313
00:15:26,120 --> 00:15:30,520
If the project handles highly sensitive information, face check can confirm that Alex is presenting
314
00:15:30,520 --> 00:15:31,520
the credential.
315
00:15:31,520 --> 00:15:35,200
The access package then checks the issuer, the course claim, and the expiry date before
316
00:15:35,200 --> 00:15:36,360
the request moves on.
317
00:15:36,360 --> 00:15:39,520
No PDF chasing, no manual comparison of course records.
318
00:15:39,520 --> 00:15:43,920
The company receives the proof it asked for, while Alex stays in control of presenting it.
319
00:15:43,920 --> 00:15:47,680
These situations work best when the credential solves a real decision problem rather than
320
00:15:47,680 --> 00:15:51,720
becoming another check people must complete for no clear reason.
321
00:15:51,720 --> 00:15:53,520
What to plan before you turn it on?
322
00:15:53,520 --> 00:15:56,400
Start with a problem that already costs you time or creates risk.
323
00:15:56,400 --> 00:15:59,560
Maybe your help desk gets buried in password recovery requests.
324
00:15:59,560 --> 00:16:03,000
Maybe contractors, email certificates that manages have to review manually.
325
00:16:03,000 --> 00:16:06,800
Maybe a sensitive sharepoint site needs proof of current training before anyone can join.
326
00:16:06,800 --> 00:16:11,080
Take one of those scenarios, don't kick off a broad project called digital identity, because
327
00:16:11,080 --> 00:16:14,480
that makes it nearly impossible to define what success looks like.
328
00:16:14,480 --> 00:16:17,280
Next, decide who has the authority to issue the proof.
329
00:16:17,280 --> 00:16:21,440
Your own organization might issue an employee credential straight from EntraID data.
330
00:16:21,440 --> 00:16:23,680
A training provider might issue a course credential.
331
00:16:23,680 --> 00:16:27,600
For identity proofing, you could use an approved partner that checks government ID documents.
332
00:16:27,600 --> 00:16:31,120
The verifier has to trust that issuer before the flow can work.
333
00:16:31,120 --> 00:16:35,240
Then define the credentials life, which claims should it contain, how long should it stay
334
00:16:35,240 --> 00:16:39,400
valid, who can receive it, who can ask for it, what happens when the training expires
335
00:16:39,400 --> 00:16:42,120
the person changes jobs or a contractor leaves.
336
00:16:42,120 --> 00:16:46,840
A credential that never expires becomes a problem when the fact it confirms no longer applies.
337
00:16:46,840 --> 00:16:48,600
The user journey needs planning too.
338
00:16:48,600 --> 00:16:52,000
People need Microsoft Authenticator on a supported phone, clear instructions for receiving
339
00:16:52,000 --> 00:16:55,680
and presenting a credential in a support path when they switch or lose a device.
340
00:16:55,680 --> 00:16:59,520
Don't assume everyone has the same phone access or feels confident with QR codes.
341
00:16:59,520 --> 00:17:01,720
The verification flow itself needs protection.
342
00:17:01,720 --> 00:17:04,680
Each request should connect to one user session.
343
00:17:04,680 --> 00:17:09,280
Keep requests short-lived and single use, so an old request can't be reused later.
344
00:17:09,280 --> 00:17:12,920
Your app should treat the successful result as part of that one transaction, not as a general
345
00:17:12,920 --> 00:17:14,760
path someone can replay elsewhere.
346
00:17:14,760 --> 00:17:18,640
For setup, your organization needs a verified custom domain in EntraID.
347
00:17:18,640 --> 00:17:23,120
That confirms you control the organization name behind the credential and its requests.
348
00:17:23,120 --> 00:17:27,160
Microsoft's quick setup can create a ready-made, verified employee credential, which gives
349
00:17:27,160 --> 00:17:29,720
many organizations a practical starting point.
350
00:17:29,720 --> 00:17:33,320
You can then control which users can receive it and adjust the experience to match your
351
00:17:33,320 --> 00:17:34,320
needs.
352
00:17:34,320 --> 00:17:36,520
Keep the governance question in view.
353
00:17:36,520 --> 00:17:39,880
When the relationship changes, who removes or withdraws the proof?
354
00:17:39,880 --> 00:17:44,640
That question often decides whether a verified ID design remains useful after the first demo.
355
00:17:44,640 --> 00:17:50,200
Microsoft Entra, Verified ID, gives trusted organizations a way to issue digital proof that people
356
00:17:50,200 --> 00:17:52,280
keep and share from their own wallet.
357
00:17:52,280 --> 00:17:55,200
Use Entra ID, MFA and pass keys for sign-in.
358
00:17:55,200 --> 00:17:59,120
Add verified ID when a decision depends on a trusted fact about the person, like current
359
00:17:59,120 --> 00:18:03,040
employment, completed training or confirmed identity during recovery.
360
00:18:03,040 --> 00:18:07,000
Try one practical exercise this week, find one manual identity check in your business.
361
00:18:07,000 --> 00:18:10,680
Write down the claim you need, name the organization that should issue it, and decide whether
362
00:18:10,680 --> 00:18:12,640
face check belongs in that moment.
363
00:18:12,640 --> 00:18:17,280
The next knowledge nugget will cover "access packages", where that proof can control access
364
00:18:17,280 --> 00:18:19,920
to Teams, SharePoint, Applications and Entra roles.
