Microsoft Entra Verified ID - Simply Explained

Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365. FM, I'm your host, Mirko Peters. Today's topic is one that almost everyone has heard of, but few people truly understand. Proving who you are beyond just signing in. You can have strong sign in security, you can use MFA, you can use a pass key instead of a pass word. But here's the thing, none of that automatically proves who sits behind the screen. It doesn't prove whether they still work for a company. It doesn't prove whether they completed the training needed for a sensitive project. Think about these situations. A help desk agent gets a call from someone locked out. A remote new hire needs equipment, a contractor needs access, an applicant has no company account yet. Those situations need more than a successful sign in. They need proof of a real world fact. By the end of this episode, you'll understand Microsoft Entra verified ID in plain English. You'll see how a digital wallet fits into the process. And you'll learn why an organization can often check a credential without calling the organization that issued it. Grab your coffee and let's dive in. Let's start with the problem. The old way of checking identity still creates a lot of risk. The problem identity checks still depend on manual trust. Imagine you need to prove that you completed data handling training before you can join a project team. Here's how it usually works. You download a certificate as a PDF, you attach it to an email, someone opens it, checks the name, checks the date, and decides whether it looks right. Sometimes that proof arrives as a screenshot. Sometimes it arrives through a shared spreadsheet. Sometimes a manager gets a message in team saying, yes, this person finished the course. The work gets done. But the proof travels around as loose files and informal messages. People must decide what to trust, often while they're busy with other work. That creates two problems at once. First, documents are easy to copy and change. A PDF can look convincing even when the course expired, the person never took it, or the certificate belongs to someone else. Second, the organization collecting that proof may receive far more personal data than it needs. A copy of a passport, a driver's license, or a student record often contains details that have nothing to do with the decision being made. You might only need to know that someone completed a course. Instead, you receive a full document and now need to store it, protect it, and decide how long to keep it. The pressure gets even worse at the help desk. Picture someone calling because they lost their phone, can't use their MFA method, and can't get into their work account. The caller might know their name, job title, and employee number. They might even sound like the person they claim to be. But a skilled attacker can know those details too. With AI voice tools and deepfake video, a calm voice on a call or a familiar face in a video meeting no longer gives staff enough confidence on its own. The help desk agent ends up making a high-risk decision under time pressure. If they refuse a genuine employee, work stops. If they approve the wrong person, an attacker may gain access to email files, teams, chats, or customer data. Many organizations also hold proof in separate places. HR knows whether someone works there, a training provider knows whether they pass the course. A university knows whether they study there. A licensing body knows whether a qualification remains current. When another organization needs one of those facts, it often asks for a document sends an email or makes a phone call. It's slow, hard to scale, easy to get wrong. Now let's clear up a common myth. MFA doesn't solve this specific problem. MFA proves that someone controls a sign-in method, such as an authenticate or prompt, phone or pasky. That is still a strong and useful check. But it doesn't prove that the person completed safety training yesterday, it doesn't prove that a contractor still works for an approved supplier. And it doesn't prove that an applicant without an intro account is qualified for the role. The check needs to move away from a person's account and to what a signed claim about that person. A verified ID comes in, but we'll cover that in the next nugget. What Microsoft Entra Verified ID actually is. So what is Microsoft Entra Verified ID? In plain English, it's Microsoft service for issuing and verifying digital credentials. A credential is like a signed digital card that proves a specific fact about you. Think of Microsoft Entra ID as the reception desk in an office building. It checks your sign-in and decides whether you can enter the building. Verified ID is more like a signed card you carry after your inside. That card might show you an employee, or that you completed a course, hold a license, yet a university, or work for an approved supplier. The card includes details called claims. Those are just the facts written on it, like your name, employee number, job title, course name, student status, a photo, and the issue and expiry dates. The organization decides which claims go on the credential. A training company might issue a credential saying you completed a data handling course, valid until a certain date, and it doesn't need your home address or phone number, just the essential facts. That small amount of shared data is the whole point. Your Microsoft Authenticator app can hold these credentials on your phone. Think of it as a digital wallet, but for work and identity proofs instead of payment cards. You can open the credential and see who issued it, what it says about you, when it expires, and where you've used it. The credential belongs to you in your wallet, but that doesn't mean you can edit it. You can't change training completed to training completed with distinction anymore than you can rewrite a badge printed by your employer. The issuing organization signs the credential, and that signature protects the information inside if someone changes the data, the check fails. This is where the word decentralized often confuses people. It doesn't mean there's no organization in charge. It means the proof doesn't have to live in one central system that every other organization must call. One organization issues the proof you hold it, and another organization can check it. The issue could be your employer, a school, a training provider, a professional body, or an identity verification partner. The holder is you, and the verifier is the organization asking whether a claim is valid. The approved Entra Verified ID manages the technology around that exchange, so organizations can issue and request these signed credentials without building the whole system from scratch. How does the verifier know the card is real? It checks several things behind the scenes. The issuer identity and the organization's verified domain, the digital signature to make sure it came from that issuer and hasn't changed, whether the credential is still within its valid date range and whether the issuer has revoked it. So if a contractor leaves a supplier, the supplier can revoke the credential and a verifier checking it later will see that it should no longer be accepted. That's why a verifier often doesn't need to phone the issuer or send an email asking, is this certificate still good? The proof carries a signed record, and the verification process checks whether that record still holds up. Notice what Verified ID does not replace. It doesn't replace your password, pass key, or MFA method. It doesn't replace single sign-on, and it's not a live employee directory that updates every second with HR changes. Microsoft Entra ID still handles sign-in, creating the account-based control around apps, teams, SharePoint, and Microsoft 365. Verified ID adds a different kind of proof. It says that a trusted organization confirmed a specific fact about a person at a specific time with an expiry date and a way to withdraw that proof if circumstances change. That gives you a much clearer question to ask, who issued the proof? What exactly does it confirm and should we trust it for this decision? Once you see that, the whole model becomes easier. Every verified ID journey has three people, or roles, involved. The three roles, issuer, holder, and verifier. Every verified ID exchange has three roles. The issuer creates the credential, the holder keeps it, and the verifier asks to see it. That's the whole pattern, and once you know those three roles, the technical term stop getting in the way. The issuer is the organization that can honestly confirm a fact. Your employer can issue a credential, confirming you work there. A university can confirm you're a student, a training provider can confirm you completed a course. A professional body can confirm your license is current, and in some cases, an identity verification partner can check a government ID and issue a credential based on that. The issuer doesn't just fill in a card with whatever someone asks for. It first checks the source it trusts, like an HR record, a course result, a student system, or an identity check, and then creates the credential with the claims that match that decision. The issuer also decides how long the credential should remain valid. A course certificate might last a year, and employee credential might end when employment ends. A visitor pass might last only one day. That time limit matters because the fact can change. Someone may leave the company, a qualification may expire, or a course may need renewal. The holder is the person named in the credential. They accept it into Microsoft Authenticator where they can see who issued it, what information it contains, and the issue and expiry dates. The holder has control at the point of sharing. If an organization requests a credential, the person can review the request and choose to approve or decline. That consent step is worth posing on. A credential doesn't give every organization automatic access to your information. A verifier must ask for the proof, and the holder sees that request before anything is shared. Authenticator also keeps a record of credential activity, so the holder can look back at where it was presented. The verifier is the organization that needs proof for a particular decision. An employer deciding whether to grant access to a sensitive project, a help desk, checking someone before starting an account recovery, a hiring company confirming an applicant's qualification, or a partner organization needing proof that a contractor belongs to an approved supplier. To use a simple workplace example, Alex needs access to a project that handles customer data. Before joining, the company requires approved data handling training. Alex completes the course through an outside training provider, which checks the result and issues a training credential. Alex accepts it into Microsoft Authenticator. Later, Alex opens the company's access request page and asks to join the project. The page shows a QR code. Alex scans it with Authenticator and sees a request to present the training credential. The app shows which organization is asking and what information it wants. Alex reviews the request and approves it. The training credential stays in Alex's wallet and the company receives the approved claim data needed for its decision rather than an emailed PDF that could be copied, forwarded, or stored forever. That gives the verifier a cleaner process. It checks that the credential came from the expected issuer, verifies the signature, and checks whether it has expired or been revoked. If all those checks pass, the company can move Alex's access request forward. No one needs to search an inbox for a certificate, call the training provider and wait for a reply or decide whether a screenshot looks believable. The verifier still needs to make a sensible policy decision. It must decide which training provider it trusts, which credential type it accepts, and how recent the training must be. Verified ID checks whether the proof is genuine. It does not replace the organization's judgment about what proof it should require. There is one more question though. Assigned credential can prove that the training record is real, but a phone can be lost, borrowed, or stolen. How do you check that the person presenting the credential is the person shown in it? That is where face check enters the picture. Face check. When the proof must match the person. So you've got a training credential. It's genuine, current, and issued by a provider you trust. But that still leaves one question. Is Alex the person holding the phone? For many everyday checks, the credential alone might be enough. A low risk request doesn't always need another layer, but some moments carry more risk, like recovering a locked account, approving access to customer data, or granting a privileged admin role. A lost phone creates risk, so does a borrowed phone, and a attacker could try to use a photo, a recorded video, or a convincing deepfake during a remote check. The credential proof the record is real. It does not automatically prove the presenter is the person named on that record. That's where Microsoft Entra verified ID can add face check for those higher risk moments. Face check asks the person to take a live selfie. Then it compares that selfie with the photo stored inside the verified ID credential. Think of the two checks as separate jobs. Credential verification checks the proof. Face check checks the person presenting the proof. When both checks pass, the organization has stronger confidence that the person making the request matches the person connected to the credential. This fits naturally into remote onboarding, a new employee may need access before they ever enter an office. Instead of relying only on a video call and an emailed document, the organization can request a credential, and, where the risk calls for it, ask for a face check. The same ID applies to account recovery. If someone loses their phone and all their usual sign-in methods, the organization should not simply accept a support request because the caller knows a few personal details. A higher assurance check can happen before the organization creates a temporary path back into the account. Help desk staff gain a more consistent process. The person requesting help follows the same guided check rather than asking an agent to judge a voice, a screenshot, or a story under pressure. Face check can also fit requests for sensitive access. If someone asks to manage a system, view protected records, or take on a powerful role, the added check helps confirm that the request comes from the intended person. But you shouldn't use it everywhere. You probably don't need a live selfie just to open a routine document or join an ordinary team. The check set effort and people notice that effort, use face check when the cost of impersonation justifies the extra step. There are a few practical details behind this. The credential needs a photo claim that can act as the reference image. That photo needs to be clear enough for the comparison to work. The verification flow must support face check, and your organization may need extra setup and Azure subscription and the right licensing for the scenario. Privacy also needs a clear place in the design. Face check exists to support a decision at a higher risk moment. It's not a reason to collect face data for every normal task. Tell people why the check is happening, what it checks, and what happens if it can't be completed. That keeps the process fair and easier to trust. Once you combine signed credentials with a person check only where needed, you can use verified ID in familiar work situations, without turning every task into an identity test. Where it fits? Four practical Microsoft 365 scenarios. So where does this fit into normal Microsoft 365 work? Let's look at four practical scenarios. First, remote onboarding. A new employee may need a laptop, a work account, and access to a few systems before their first day. If the company uses a trusted identity verification partner, that person can complete an identity check and receive a credential before the normal account setup begins. The hiring team gets a stronger check than an emailed photo of an ID card. The new employee also avoids sending the same documents through several mailboxes. Once the company confirms the person and creates the right account, the usual EntraID sign-in, MFA, Intune device setup, and Microsoft 365 access still take over. Second, account recovery. Imagine someone loses their phone while traveling. Their passkey, authenticator approvals, and backup methods are all unavailable. They need a safe way back into their account, but the help desk should not reset access based on a few answers that an attacker may already know. A verified identity check can sit before that recovery step. After the person proves who they are through an approved identity flow, the organization can issue a temporary access path or guide them through registering new sign-in methods. That removes some pressure from the help desk while keeping the recovery decision tied to better evidence. Third, secure access to work resources. Many people assume access depends only on whether you are an employee. Often, that's only part of the decision. Someone may work for the company, but still need current training before they can join a team that handles customer data. Microsoft Entra access packages can bring this into a clear request process. An access package can contain a Microsoft Teams team, a SharePoint site, an enterprise app, or even an Entra role. Before someone receives that package, the policy can ask for a specific credential from an issuer, the organization trusts. So the person signs in as normal, then they present proof that they completed the required training. If the access package needs higher assurance, it can also require face check. The request can move forward automatically when the policy checks pass, or it can go to an approver with the proof attached to the request. That turns a messy approval process into a defined rule. Both, people outside your organization. A contractor may need access to a supplier portal. A student may need to prove enrollment, and applicant may need to prove a qualification before an interview process continues. None of those people need a full internal account just to establish one fact. They can present a credential from an organization you trust. That matters because creating guest accounts for every early stage interaction adds work, and leaves more accounts to manage later. Sometimes you need an account for ongoing collaboration. Sometimes you only need a verified fact for one decision. Accounting certificates are a good example. Alex needs access to a restricted project. The project requires current data handling training from an approved provider. Alex completes the course, receives the course credential, and starts the access request. The system requests that credential. Alex approves the request in authentication. If the project handles highly sensitive information, face check can confirm that Alex is presenting the credential. The access package then checks the issuer, the course claim, and the expiry date before the request moves on. No PDF chasing, no manual comparison of course records. The company receives the proof it asked for, while Alex stays in control of presenting it. These situations work best when the credential solves a real decision problem rather than becoming another check people must complete for no clear reason. What to plan before you turn it on? Start with a problem that already costs you time or creates risk. Maybe your help desk gets buried in password recovery requests. Maybe contractors, email certificates that manages have to review manually. Maybe a sensitive sharepoint site needs proof of current training before anyone can join. Take one of those scenarios, don't kick off a broad project called digital identity, because that makes it nearly impossible to define what success looks like. Next, decide who has the authority to issue the proof. Your own organization might issue an employee credential straight from EntraID data. A training provider might issue a course credential. For identity proofing, you could use an approved partner that checks government ID documents. The verifier has to trust that issuer before the flow can work. Then define the credentials life, which claims should it contain, how long should it stay valid, who can receive it, who can ask for it, what happens when the training expires the person changes jobs or a contractor leaves. A credential that never expires becomes a problem when the fact it confirms no longer applies. The user journey needs planning too. People need Microsoft Authenticator on a supported phone, clear instructions for receiving and presenting a credential in a support path when they switch or lose a device. Don't assume everyone has the same phone access or feels confident with QR codes. The verification flow itself needs protection. Each request should connect to one user session. Keep requests short-lived and single use, so an old request can't be reused later. Your app should treat the successful result as part of that one transaction, not as a general path someone can replay elsewhere. For setup, your organization needs a verified custom domain in EntraID. That confirms you control the organization name behind the credential and its requests. Microsoft's quick setup can create a ready-made, verified employee credential, which gives many organizations a practical starting point. You can then control which users can receive it and adjust the experience to match your needs. Keep the governance question in view. When the relationship changes, who removes or withdraws the proof? That question often decides whether a verified ID design remains useful after the first demo. Microsoft Entra, Verified ID, gives trusted organizations a way to issue digital proof that people keep and share from their own wallet. Use Entra ID, MFA and pass keys for sign-in. Add verified ID when a decision depends on a trusted fact about the person, like current employment, completed training or confirmed identity during recovery. Try one practical exercise this week, find one manual identity check in your business. Write down the claim you need, name the organization that should issue it, and decide whether face check belongs in that moment. The next knowledge nugget will cover "access packages", where that proof can control access to Teams, SharePoint, Applications and Entra roles.