Phishing-Resistant MFA: Rolling Out Passkeys in Microsoft Entra

M365 FM - Phishing-Resistant MFA - Rolling Out Passkeys in Microsoft Entra 00:00:00 Speaker: Most MFA is built on one assumption that the user will make the right call. It's seven forty two a m A prompt lands on your phone, you're half awake, and you tap approve because you're expecting it. Now compare that with the credential you can't hand over even if you wanted to. That's the difference. Passkeys don't work because they're a stronger factor. They work because they remove the judgment call. If you want more on passkeys and phishing resistant MFA, subscribe. But first, the model that got us here. Sponsor segment stellar Migrator for exchange. Quick note before we go on, this episode is supported by stellar Migrator for exchange. And there's a reason it fits this topic. Think about what happens when a tenant moves a merger, a divestiture, a consolidation of two. Microsoft three. Sixty five environments into one. The mailboxes move, the calendars move the data moves, but identity state doesn't come along for free. Registered methods are tied to the tenant. They were registered in the authenticator app, the phone number, the security key in the new tenant. Those registrations start empty. The user shows up on day one with a mailbox that works and no registered way to prove who they are. Most teams treat that as a problem to patch a pile of tickets. A rush of temporary passes. But look at it another way. A migration is the one moment when everyone expects change. Users already know something is happening. They've been told to expect new sign in steps, their guard is down and their attention is up. That makes it a natural trigger point for a reregistration campaign. If you're going to ask people to register something anyway, ask them to register something better. Pass keys instead of the old phone number. Security keys for the admins instead of another authenticator app. You don't need a separate awareness project. You attach the ask to an event people already understand. So when you plan a tenant move, plan the identity site at the same time as the mailbox side. Know which methods exist today. Decide which ones you'll carry over and which ones you'll let go. That's the educational point here. Stella Migrator for exchange handles the mailbox side of that move. What you do with identity during the move is up to you, and it's worth deciding on purpose. Now back to why the old model fails. Section one the old model MFA. As a second question, in most tenants, MFA means a prompt a text message with six digits. A phone call that says press pound. A push notification that says approve sign in. Over the years, these became the whole definition. When someone said, we have MFA turned on, this is what they meant, and it made sense at the time. Passwords were failing. They got reused, guessed, leaked, and sold. So the industry added a second step, something you know, plus something you have. That was a real improvement. And for a long time it stopped a lot of damage. But look at the assumption underneath it. A second factor means a second barrier. That's the idea. The attacker gets past the password and then they hit a wall. They don't have the phone. They can't read the text. They're stuck. That's the model. And in a narrow sense, it's true. If an attacker only has a stolen password, the second factor does stop them. That's the scenario it was designed for. But in reality, attackers stopped working that way. What the attacker does now is simpler. They don't try to get past the second factor. They ask the user to complete it for them. Here's how that works. The user clicks a link and lands on a page that looks like Microsoft. They type their password. The page forwards it to the real Microsoft sign in, which responds with an MFA request. The user sees the prompt on their phone expecting it because they just typed their password. They approve it. The attacker's page relays all of it every step in real time. So the factor did its job. It verified a real person with a real phone. The code was correct, the approval was genuine. Nothing was broken, nothing was bypassed, and the attacker still got in. That's the part most tenants never absorb. The factor was never the weak point. A text message code is as strong as it ever was. A push approval is as real as it ever was. The weak point was the person holding it. Think about what every one of these prompts has in common. They all ask a question do you approve? Is this you? Enter the code you received and a question can be answered by anyone. The user believes it can be answered under pressure. It can be answered half awake, in a hurry or on autopilot. We built a security control that depends on a human making a correct decision every time, in a moment, designed to trick them. And then we called it strong because it had two steps. Adding more steps doesn't fix that. A third prompt is still a prompt. A longer code is still a code the user can type into the wrong page. The model itself is the problem. It treats the user as the last line of defense, and then it's surprised when the line gives way. That's why the numbers look the way they do. Organizations turn on MFA, check the box, and still get compromised. Not because the control was off, because the control was a question and attackers got good at asking it better than defenders did. So the real issue isn't strength. It's where the decision lives. As long as the decision sits with the user, the attacker has something to work with. Their whole job becomes persuasion. Make the page convincing. Make the timing right, make the request look routine. And that's exactly what happens in a real tenant. Not a theory, a pattern, a page, a proxy, a prompt, and a session that doesn't belong to the person it was issued for. So let's look at what that attack actually looks like step by step and what the attacker is holding when it's over. Section two anatomy of adversary in the middle. Phishing. Start with the user. They get an email, a shared document, an invoice, a voicemail transcript. It looks routine, so they click the link doesn't open a copy of the Microsoft sign in page. That's the old trick and it only ever captured a password. This one opens something different. A server that sits between the user and Microsoft and passes everything through that server is a reverse proxy. The page the user sees is real the logo, the tenant branding, the company background image because the attacker's server is fetching it live from Microsoft and handing it over. The only thing that's wrong is the address bar, and most people don't read the address bar. So the user types their email, the proxy forwards it. Microsoft responds with the password field, the proxy forwards that back, the user types the password. The proxy sends it to Microsoft. Now Microsoft does what it's supposed to do. It asks for MFA. That prompt reaches the user through the proxy, looking exactly as expected. A text with six digits, a push with a number to match. The user completes it because they just typed a password, and they've seen this screen a hundred times and the proxy forwards the answer, Microsoft checks it. The password is right. The second factor is right. The sign in is valid. So Microsoft does what it does. After any successful sign in, it issues a session, a session cookie, a token that says this browser already proved who it is and that token comes back through the proxy. The user gets redirected to a real page. Maybe the document they were promised, maybe an error. They move on with their day. They never know the attacker's server is holding the cookie. Here's what that means. And it's the part that surprises people. The MFA wasn't skipped. It wasn't weak. It wasn't misconfigured. Every check past the sign in log shows a successful authentication with multifactor satisfied because it was the factor proved that a real person with a real phone was present. It just couldn't prove that the person was talking to Microsoft. That's the gap. MFA verifies the user to the service. Nothing in a code or a push verifies the service to the user. The user is left to do that themselves by reading a URL in a moment when nothing feels wrong. Now look at what the attacker holds afterward because it changes the whole response. With a stolen password, the attacker has a secret something you can rotate, reset the password, and the secret is dead. That's the model most incident playbooks were written for with a stolen session token. The attacker has something else. Proof that authentication already happened. They don't need the password anymore. They don't need to pass MFA again because MFA is already in the token. They import the cookie into their own browser, and Microsoft sees a signed in session. Resetting the password doesn't automatically end. The session keeps working until it expires or gets revoked, and a lot of teams don't know to revoke it. So the attacker isn't fighting the security controls. They're walking in the front door with a badge the defender issued. And what do they do once they're in? Most of the time they go for the mailbox quietly. They read the threads, they learn who approves payments, who talks to which vendor, what the invoices look like. Then they create inbox rules that hide replies so the real user never sees the conversation. And then they send one email from a trusted account in an existing thread asking a finance contact to update bank details. That's business email compromise. It's the common ending for this attack because it turns a stolen session into money without needing malware exploits or anything that trips a traditional alert. Everything in that chain was legitimate a real user, a real sign in a real mailbox, a real thread. But phishing through a proxy is only one way the prompt gets abused. There's a quieter version, one where the attacker doesn't need a convincing page at all. They just need the user to get tired. Section three. MFA fatigue and the human cost of prompts. This version needs no proxy and no fake page. The attacker already has the password. Maybe it came from a breach dump, or a reused login or an earlier Phish. And now they do the simplest thing available. They try to sign in. Every attempt fires a push notification to the user's phone one at eleven p m, another at eleven oh two, another at midnight. Approve, approve, approve. It's called push bombing and it works on a plain observation. People want the buzzing to stop. Some tap approved just to make it quiet. Some assume it's a glitch. Some figure it's it doing something. Microsoft's answer was number matching. The sign in screen shows a two digit number, and the user has to type it into the authenticator app. No more blind approvals. You can't tap through a prompt you're not looking at. That fixed a real thing. It killed the reflex tap. But look at what it didn't touch. The attacker can still call the user pose as the help desk and say, read me the number on your screen. And the proxy attack from the last section is untouched because in that case, the user is looking at a real number from a real sign in. They type it in on purpose. So number matching raised the effort. It didn't change the model. The user is still being asked a question and the attacker is still the one framing it. Then there's a separate older failure SMS. A text message isn't tied to a device, it's tied to a phone number. And a phone number is a thing a carrier can be talked into moving. That's a SIM swap the attacker calls the carrier, pretends to be the customer, and the number is now theirs. Every code goes to their phone. Instead, nobody in the tenant sees anything unusual because the message was delivered to the number on file. Text messages also cross networks that nobody in your organization controls. They can be intercepted, forwarded, or read off a lock screen. SMS was never built to carry authentication. It was just already in everyone's pocket. Now zoom out because the bigger cost isn't any single attack. It's what the volume of prompts does to people over time. Think about how many times a day someone in your tenant sees an authentication request, signing in on a new device, opening a different app token refresh a conditional access rule that fires more than it should. Each one is a small interruption, and each one has the same shape. A screen appears, a decision is needed. The fastest way back to work is yes. So people learn not on purpose and not out of carelessness. They learn the way anyone learns from repetition. The prompt is noise and approving it is how noise ends. That's the human cost. We trained a workforce thousands of times a year to approve without reading. Then we ask them to catch the one request in ten thousand. That's an attack. You've probably seen the result from the other side. The help desk call that starts the same way. I keep getting these prompts. Sometimes it's a user who ignored fifteen and wants to know why they won't stop. Sometimes it's a user who approved one an hour ago and now feels uneasy. Sometimes the call comes a day late after the mailbox rules have already been created. Either way, the help desk is cleaning up a failure. The design made likely. The user didn't misbehave. They did what the system taught them to do. So the fix can't be better training, or a longer code or a more insistent prompt. Every one of those still leaves the decision with a tired human. The fix is structural. Take the decision away and let the credential check where it is being used. Bind it to the origin section for what phishing resistant actually means let's define the term in a way you can test. A credential is phishing resistant if it cannot be replayed to a different site. That's it. Not harder to fool, not fewer ways to trick the user. The credential itself refuses to work anywhere except the place it was created for, even if the user wants to hand it over, even if the user is fooled completely. Compare that with everything we've covered so far. A password can be typed into any page. A six digit code can be typed into any page. A push approval answers whatever sign in happens to be waiting. In each case, the credential has no idea where it's being used. It works the same for the real service and for the proxy sitting in front of it. Phishing resistant credentials know where they are. The mechanism is called origin binding, and it changes who does the checking. When you sign in with a passkey, the browser is part of the exchange. It knows the domain of the page it's on. Not the logo, not the layout, not what the page claims to be. The actual domain, the way the browser sees it. And when the site asks the authenticator to sign in, the browser passes that domain along. So the check about the address bar, the one we hoped the user would make now happens in software. every time, without fatigue, without hurry, without anyone being persuaded. The user can't skip it. The user doesn't even see it. Now, how does that work without a shared secret? This is the part that makes the whole design click. Passwords are shared secrets. You know it, the server knows it, and anyone who captures it can use it. Codes are the same, just with a shorter life. A passkey uses public key cryptography instead. When you register, your device creates a pair of keys. The private key stays on the device and never leaves. The public key goes to the service, and the public key is safe to store. Because it can only check a signature, it can't create one. When you sign in, the server sends a random challenge. Your device signs that challenge with the private key. The service checks the signature with the public key if it matches, you're in nothing secret crossed the network. There's no password to steal in transit and no database of secrets to leak. A breach of the service gets the attacker a pile of public keys, which are worthless on their own. But here's the detail that matters most for phishing. The key pair isn't just tied to your device, it's tied to a specific service when the pair is created, the authenticator records the identity of the relying party, meaning the site that asked for it, and later the authenticator only uses that private key when the requesting domain matches. So walk back through the attack from earlier. The user lands on a lookalike page. Same logo, same branding. A domain that's one character off the page asks for a passkey sign in the browser reports the domain it's actually on. The authenticator. Looks for a key pair registered to that domain. There isn't one, so nothing happens. No prompt to approve, no code to read, no signature to relay. The authenticator has nothing to offer because the key pair belongs to the real Microsoft. Sign in. And this page, isn't it. The proxy can't fix that either. It can pass messages along, but the signature is bound to the domain the browser saw, which is the attacker's domain. Microsoft would reject it because the signature was made for a different origin. That's the structural fix. The user isn't asked to notice the fake page. The fake page simply gets nothing. And notice what this doesn't depend on. It doesn't depend on training or on number matching or on a user's mood at seven forty two in the morning. It depends on math and on a browser that reports an address. Honestly, which raises the obvious question. This sounds like one technology, but if you've read anything about it, you've seen a pile of acronyms Fido2, Webauthn, Ctap, passkeys. They get used as if they mean the same thing and they don't. So before we get into intra, let's untangle the standards behind all of this. Section five Fido2, Webauthn, Ctap and passkeys untangled for names. One system. Most people get confused because they treat them like four separate products. They're really four layers of the same thing. Start at the top. Fido2 is the umbrella. It's the name for the whole set of standards built by the Fido Alliance and the W3C that lets a device prove who you are without a password. When someone says we're rolling out Fido2, they mean the overall approach. It's not a single piece of software you install underneath it. Set two specifications. They do different jobs. Webauthn is the first one. It's the API that lives in the browser and in apps. When a website wants a passkey sign in, it calls Webauthn. This is the layer that hands the browser's view of the domain to the authenticator, which is the origin binding we just talked about. So Webauthn is the conversation between the website and the browser. Ctap is the second one client to authenticator protocol. This is the conversation between the browser or the operating system and the thing holding the private key, a USB security key, a phone over Bluetooth, the chip in your laptop. GitHub is how they talk. So a sign in has a chain. The site speaks webauthn to the browser. The browser speaks ctap to the authenticator. The authenticator signs and the answer travels back up the same way. Now where do passkeys fit? A passkey is a name, not a new layer. It's the friendly word for a Fido credential that's discoverable. That means the credential is stored on the authenticator along with the account it belongs to. So the device can offer it without the user typing a username first. You show up at the sign in page. The device says, I've got a credential for this site and you pick it. Before that word existed, the same technology was explained with phrases like resident key and passwordless fido2 accurate and unusable for anyone outside the standards. Body passkey is what users can actually remember. Under the hood, it's still webauthn and ctap, But here's the distinction that matters to a tenant admin. Not all passkeys live in the same place. A device bound passkey stays on one authenticator. The private key is created there and never leaves. A hardware security key is the classic example. Lose the key and that credential is gone, which sounds like a downside. And it is for recovery. But it's also the reason the credential is easy to reason about. There's one object, you know where it is, you can count it. A single passkey is different. The private key is backed up through a cloud account, like the ones tied to a phone or a browser, and it shows up on every device signed into that account. That's wonderful. For convenience, replace your phone and your passkeys are already there. But think about what that means for an organization. The credential now lives inside a personal ecosystem. Your security depends on how well that account is protected, how recovery works for it, and who else can get into it. Those are things the tenant doesn't control and often can't see. Neither type is wrong. They answer different questions. Device bound gives you control, and a clear inventory sync gives you reach and an easier user story. And the choice isn't about which is better. In general, it's about which fits the population you're enrolling. That brings up a practical question. How does an organization know what kind of authenticator it's actually trusting? This is where attestation comes in. When a passkey is registered, the authenticator can include a signed statement about itself, what model it is, who made it, what protections it claims. The service checks that statement against known information and decides whether it's willing to accept this particular authenticator. And the identifier at the center of it is the AA guide. It's a unique ID that points to a make and model of authenticator. Every key from the same product line shares one. So if your policy says only allow these three models of hardware key. The AA is how you say it. And if a certain model turns out to have a flaw, it's how you block it. Without that, you're trusting anything that calls itself a passkey. With it, you're trusting a list you chose. That list is the control and administrator actually holds and entra gives you specific places to set it for specific kinds of passkeys. So let's go through the passkey types entra actually supports and what each one is good for. 00:17:29 Speaker: Section six. The passkey menu in entry ID enter gives you more than one kind of passkey. Each one answers a different question, so let's go through them in order. Start with the oldest and most concrete the Fido2 security key. It's a small piece of hardware USB, NFC, sometimes both. The private key is created inside it and never leaves. You plug it in or tap it, touch the button or scan a finger and it signs the challenge. That's the whole experience. It's device bound in the strictest sense. One object, one credential. You can count them, hand them out and write down who holds which one for admins and for anyone who works on a shared machine, that clarity is the point. The trade off is just as plain. Keys get lost and they cost money to buy and ship. Next, the one most users already carry Microsoft Authenticator. Most people know the app as the thing that shows a number to match. It can also hold a passkey on iOS and Android. The app creates a device bound passkey tied to that phone and protected by the phone's own biometric, or PIN. The user signs in the phone asks for a face or a fingerprint, and the app signs the challenge. Same app, same icon, completely different mechanism. That helps with rollout because you aren't asking people to install something new. You're asking them to use something they already have in a way that can't be fished. Then there are platform passkeys. These live in the operating system itself windows hello on a windows machine, touch ID, or face ID on a Mac. The credential sits in the chip inside the device, and the unlock gesture is the PIN or the biometric the user already uses every morning in entra. These get set up through the passkey profile model. A profile is a bundle of settings that says which kinds of passkeys a group of users may register and under what rules. So instead of one global switch, you can say this group gets hardware keys. Only that group can use platform passkeys. We'll come back to profiles when we get to the policy itself. For now, just know that platform passkeys are the lowest friction option because the device is already in the user's hands. Now the awkward one. Synced passkeys. These are the ones backed up through a cloud account tied to a phone or a browser. For consumers, they're the reason passkeys finally caught on. Replace your phone and your passkeys come with you. But earlier we saw what that means. For an organization. The credential lives in an ecosystem the tenant doesn't run. So where does entra stand? Support here has been moving, and it's worth checking the current documentation rather than trusting a memory of last year's. The direction is clear, though. Entra has been adding ways to work with passkeys from the major ecosystems, and the passkey profile settings are where an admin decides whether to allow them at all. For most organizations, the sensible default is to start with device bound options and treat synced passkeys as a deliberate decision for specific groups, not an accident. One more path and it isn't a passkey at all. Certificate based authentication. If your organization already issues certificates to people, maybe on smartcards, maybe through a public key infrastructure you've run for years. Entra can accept those for sign in. The certificate does the same structural job a private key that never leaves the card or the device, and a signature that can't be replayed to a different site. That's why entra counts it as phishing resistant for some teams, especially regulated ones or those with an existing smart card program. This is the shortest road. You're not introducing new hardware. You're connecting something that already exists. So now you've seen the whole menu hardware keys, authenticator, passkeys, platform, passkeys, synced passkeys with a question mark and certificates. But a menu isn't a policy. Having these options available doesn't mean a user can pick any of them, or that your sign in rules accept all of them. Something has to decide which methods are turned on, for whom and which of them count. When you say phishing resistant, that something is the authentication methods policy and it's where an admin actually gets control. Section seven authentication methods policy as the control surface. Open the admin center. Go to protection, then authentication methods. You land on one page. That page is the authentication methods policy. Every sign in method in the tenant lives on it. Passkeys. Microsoft Authenticator, SMS voice temporary access pass certificates, email OTP. Each one has a switch and each one has a target. The target is where the real control sits. For every method, you decide two things. Is it enabled and for whom? For whom means groups. You can turn a method on for all users, or you can point it at a specific group and leave everyone else out. That sounds like a small detail. It isn't. It's the mechanism that makes a staged rollout possible at all, because you can't run waves if every setting is tenant wide. So think of the target group as the backbone of the rollout. Wave zero is a group. Wave one is a group. When a wave starts, you add people to the group and the method appears for them. When something goes wrong, you pull them back out. No scripting, no per user work, just membership. Now open the passkey Fido2 method. This is where the settings that matter most are hiding. The first one is key restrictions. It's a single toggle and it decides whether your tenant accepts any passkey or only a list you chose. Leave it off and a user can register any compliant authenticator. Turn it on and you're choosing which makers and models are allowed. That list works through the A grid, as we saw earlier, it's the identifier that points to a make and model, and you can use it two ways. An allow list says only these models are accepted. A block list says anything except these. Pick one because they work as opposed. Approaches for a high trust population like admins, the allow list is the stronger choice. You name the exact hardware you bought and nothing else gets in. For a broader group, a block list is easier to live with. You allow most things and shut out a specific model. If a flaw turns up later, then there's attestation enforcement. Remember, attestation is the signed statement an authenticator makes about itself during registration. When you enforce it, enter checks that statement and refuses authenticators that can't prove what they are, and that pairs naturally with the allow list. And a agreed is only a claim until attestation backs it up. Enforce both and the list means something. Skip the enforcement and you're trusting an authenticators word. There's a trade off worth naming, though strict attestation can block perfectly good authenticators that simply don't provide it. Some platform passkeys fall into that group, so the setting isn't something you flip on everywhere. It depends on who you're enrolling and what they'll carry. Which brings us to passkey profiles. A profile is a set of passkey rules attached to a set of users. Instead of one tenant wide configuration. You build several and each one gets its own target group, its own key restrictions, and its own attestation setting. Why does that matter? Because your populations are not the same. Think about it. Your admins need hardware keys from a named list with attestation enforced. Your office workers might be fine with authenticator, passkeys and Windows Hello. Your frontline staff might need something else again. Put all of that into one policy and you end up with the loosest rule that covers everyone. The admins get the same settings as the people with the least risk. Separate profiles fix that. The strict profile stays strict because only the people who need it are in it. The broader profile can stay flexible without dragging the strict one down, and it fits the rollout. Each wave gets a profile that matches what that wave actually holds in their hands. You don't redesign anything between waves, you add a group and a profile follows it. But here's the limit of everything on this page. The authentication methods policy decides what a user is allowed to register and use. It doesn't decide what a user is required to use. A user can have a passkey enabled and still sign in with a password and a text message, because nothing in this policy says they can't. Turning a method on only makes it possible. It doesn't make it mandatory. For that, you need a different layer, one that sits inside conditional access Section eight. Authentication strengths. The enforcement layer authentication strengths are the layer that turns possible into required. A strength is a named list of allowed sign in combinations. That's all it is. Instead of saying require MFA, you say require one of these specific ways of proving who you are, and anything not on the list doesn't count. Entry ships with three built in strengths multi-factor authentication, passwordless multi-factor authentication, and phishing resistant multi-factor authentication. Start with the first one because it's the loosest. The MFA strength accepts a long list passwords combined with a text message, a voice call, or an authenticator push. It also accepts every passwordless method and every phishing resistant one, so it's a wide door. The proxy attack from earlier walk straight through it because a password plus a number matched push satisfies it. The second passwordless MFA narrows things no password in the chain. It accepts authenticator in passwordless mode. Passkeys, Windows Hello for business certificates and temporary access pass that removes the type secret, which is a real gain. But look at what's still inside authenticator and passwordless mode still relies on a number the user matches. So it takes the password out and it doesn't take the question out. The third is the one this whole episode is about. Phishing resistant. MFA accepts only a short list passkeys, Windows Hello for business and certificate based authentication. Nothing a user can read aloud, and nothing a user can approve under pressure. Every entry on it is a credential bound to the origin. And that's the point about the names. Don't trust them. Passwordless sounds like the safe one. Multifactor sounds like it covers everything, but the label tells you very little. What protects you is what's inside the box. Two strengths with similar names can accept very different things, and the strength can quietly change as Microsoft adds new methods to a list. So read the contents, open each built in strength in the admin center and look at the combinations it permits. If you've never done that, do it this week. Most admins are surprised by what the MFA strength lets through. Now the built ins won't fit everyone, so entry lets you build your own. A custom strength is a list you assemble. You pick from the combinations entry supports and group them into one named policy. Maybe you want hardware keys only for the admin wave. Maybe you want passkeys plus Windows Hello, but not certificates. Because your certificate program is still half built. You can even narrow a custom strength to specific passkey models using the same arg width idea we saw in the methods policy. So the strength can say phishing resistant and only this hardware custom strengths are also how you step through a transition. You don't have to jump from everything to phishing resistant only in one move. You can build an intermediate list that drops SMS and voice first and tighten it again later. Here's the mechanical detail that trips people up. Though a strength doesn't act on its own, it isn't a switch that turns anything on or off. It attaches to a conditional access policy as a grant control where you used to pick require multifactor authentication, you now pick require authentication strength and choose one from the list. So the structure has three separate pieces and each does one job. The methods policy decides what's available. The strength decides what counts. Conditional access decides who has to meet it and where. That separation is useful, because it means you can reuse a strength build admin hardware keys once and attach it to as many policies as you need. Change the list in one place and every policy that points to it changes with it. But it also means a strength. Sitting unattached does nothing. You can build the most careful list in the world, and until a conditional access policy references it, every user is still free to sign in the old way. So the next question is practical. You have the enforcement layer. Where do you point it first? Not at everyone. Not yet. The answer starts with the accounts that can do the most damage if they are lost. Section nine conditional access design for phishing resistance strength. Start small, not with a tenant wide policy with a list of the accounts that can do the most damage if they fall. Global administrator. Privileged role administrator. Security administrator. Exchange administrator these are the roles that can change policy. Read every mailbox or hand out more access. If one of those sessions gets stolen, the attacker doesn't need to be clever anymore. They own the tenant and that group is small. Maybe a few dozen people, maybe fewer a cohort. You can actually name, reach and support by hand. So that's where the strength goes first. Then comes the second layer. Privileged workflows. Even for a normal user, some actions carry more weight than others. Opening the Azure portal. Touching Microsoft Graph with write access. Approving a role activation in privileged identity management. You can require the strength for those targets alone and leave everyday sign ins where they are for now. Now look at how the policy is built. It has three parts and each one answers a plain question. Users, who does this apply to for the first policy? That's the directory roles themselves. You can target roles directly. Instead of maintaining a group of admins by hand, someone gets the role. The requirement follows them. Someone loses it, the requirement drops away. Target resources. Where does it apply? Pick all cloud apps or narrow it for admins. The broad choice is usually right because the attacker doesn't care which door you protected. Grant control what must be true. This is where you leave. Require multifactor authentication alone and choose require authentication strength instead. Then pick your list phishing resistant MFA, or a custom one you built for hardware keys. That's the whole shape who, where, and which strength, but don't switch it on yet. Conditional access has a mode called report only. The policy evaluates every sign in as if it were enforced, writes down what would have happened, and blocks nothing. It's the closest thing you get to a rehearsal. Run it for a couple of weeks, then open the sign in logs and look at the conditional access tab on individual entries. Each policy shows up with a result, success, failure or not applied for report only policies. You'll see report only failure next to any sign in that would have been stopped. That one line tells you more than any plan on paper. Filter by that result and you get your real exposure. Which admins would have been blocked? Which apps were they signing into? Which method did they actually use? Maybe it's a text message, maybe it's a legacy client that can't do a modern flow at all. Maybe it's a service account somebody forgot was a human treat. Every failure as a name, not a statistic. A person with a reason and a fix to find before the policy ever goes live. Now, exclusions. And this is where good policies quietly rot. Every enforcement policy needs at least two excluded accounts break loss accounts, emergency access identities that sit outside normal sign in rules so that a bad policy, an outage or a misconfigured strength can't lock you out of your own tenant. Those accounts should be cloud only with long random passwords stored offline, and they should be protected a different way, ideally with their own hardware. Keys kept in separate physical places. Exclude them from the policy, then watch them closely. Any sign in from one of them should raise an alert because it should almost never happen. That's the exclusion that's justified. The other kind is the one that never gets removed. A director can't register a key this week, so they go on the exclusion list. A vendor account breaks in testing. So it goes on the list. A script fails, so the service account goes on the list. Each one is temporary. Each one comes with a promise to fix it later and later doesn't come. Six months on, the group holds forty accounts. Nobody remembers why. And the strongest policy in the tenant has a hole shaped like your organization's best excuses. So write down every exclusion the day you create it a name, a reason, an owner, and a date to revisit. If you can't fill in all four, it's not an exception. It's a gap. But here's where the design gets tested and where most teams find out they started in the wrong place. You can build this policy perfectly. Right roles. Right strength. Clean report only data and the moment you enforce it, anyone who hasn't registered a pass key gets stopped at the door, not blocked from an attacker blocked from their own job. The policy can only ask for something the user already holds. And that's a sequencing problem, not a policy problem. Section ten the registration gap and why most rollouts stall. Here's what happens when a team skips this part. They build the policy. They test it and report only. They switch it to enforced on a Monday morning, and by nine o'clock, the help desk queue is full of people who can't get into their own mailbox. Nobody attacked anything. The policy did exactly what it was told. It asked for a credential, and the user didn't have one. That's a lockout. It looks like security on the dashboard because sign ins are being blocked, but the people being blocked are your own staff, and the attacker was never in that queue. Meanwhile, the pressure to fix it fast is enormous. So someone adds an exclusion, then another, and the strongest policy in the tenant starts to leak. The problem isn't the policy, it's the order of work. Most teams treat enforcement as the project. Registration feels like a small step before it, something a reminder email can handle, but in reality, it's the other way around. Registration is the real project. Getting a passkey into every person's hands, working, tested with a spare behind it. That's where the months go. Enforcement is the last step, and it should feel almost boring when it arrives. If flipping the switch is exciting, you flipped it too early. So the question becomes how do people get registered? And that's where it gets awkward. To register a passkey, a user has to sign in to sign in security. They need a strong method, but the strong method is the passkey they don't have yet. Chicken. Meat egg. Think about the two bad answers. One is to let people register with whatever they have today a password and a text message that works, but it means the most sensitive moment in the credentials life. The moment it's created, is protected by the weakest method in the tenant. An attacker who fishes that session can register their own passkey on your user's account. And now the phishing resistant credential belongs to the wrong person. The other bad answer is to tell everyone to come to the help desk. That doesn't scale, and it pushes the verification burden onto whoever picks up the phone. The answer intra gives you is a temporary access pass. A tap is a time limited passcode that an admin generates for a specific user. It counts as a strong credential strong enough to satisfy MFA requirements, and it's built for exactly this job. Bootstrapping the user signs in with the tap, goes to their security info page and registers a passkey. Then the tap expires and the passkey carries on from there. Notice what this changes. The registration moment is now protected by something short lived, issued deliberately, and handed to a known person, not by a text message that anyone with a SIM swap could receive. It also fits the shape of a rollout for new hires. A tap is how day one works for a wave of existing users. You can issue them in batches and deliver them through a channel you trust, and for a lost device, it's the same tool again, but a tap is only as safe as the process that hands it out. If anyone can request one by sending an email, then the attacker just asks for one. So who may issue them and how you verify the person asking matters a great deal. We'll get to that when we reach recovery. For now, the point is simpler. Before any wave begins, you need to know how many people are already registered, which methods they use today, and who will need a tap to get started. In other words, you need to measure where you really are. 00:34:16 Speaker: From section eleven Baselining the tenant before any wave, start with what the tenant already knows about itself. Open the entire admin center. Go to protection, then authentication methods. Find the activity. Section two reports matter here. Registration details and usage registration details shows you per user which methods are registered right now. Authenticator phone passkey tap nothing at all. You can filter it, you can export it. And the first thing it gives you is a count. Nobody has ever written down how many people have a passkey today and how many are registered for nothing stronger than a phone number. That's your starting line, not a guess. A number next to it. The usage report registration tells you what a user could do. Usage tells you what they actually do, and those two lists almost never match. A user can have authenticator registered and still complete every sign in with a text message, because that's the default they clicked once in twenty twenty one. If you plan ways from the registration report alone, you'll plan for a tenant that doesn't exist. So go one level deeper. The sign in logs every interactive sign in records how the user satisfied authentication filter on the Authentication Details tab and you can see which method completed the step. Push SMS voice password only passkey. Then slice it by application. By user, group by location if you need to. That slicing is where the baseline becomes useful because the average hides everything. Say sixty percent of sign ins use authenticator fine, but which sixty percent may be. Your office staff are almost all on push, while your warehouse staff are almost all on text messages. Same tenant, two completely different populations and two completely different rollouts grouped by app two some applications get used from managed laptops, others get hit from phones, from kiosks, from a browser at a customer's site. The method a person uses often depends more on the app than on the person. Now, the uncomfortable list who depends on SMS and voice pull every user whose registered methods include phone and then cross it with the sign ins where phone was the method that actually worked. That intersection is your dependence list, and it's rarely evenly spread. Some of those people are just habitual. They never moved off the text message because nobody asked. Those are easy. A registration campaign handles them, but some have a real reason. A field technician who works in a basement with no data signal where a text arrives and an app can't. A user with a work phone that's too old to run the current authenticator. A person on a shared line. A contractor who isn't allowed to install anything on a personal device. Write those down as cases, not as a bulk number. Each reason points to a different fix, and a few of them will point to a hardware key. You'd rather learn that now in a spreadsheet than during a wave. One more category hides in the same logs. Legacy authentication. These are protocols that were never built for modern sign. In older iMap and Pop clients. Smtp relay some scripts that connect with a username and password in the request. They can't show a passkey prompt because they can't show any prompt at all. There's no browser in the chain filter the sign in logs by client app, and look for anything that isn't a browser or a modern client. Every line you find is a path where a strength requirement either can't apply or will simply break the process, and the owners of those paths are often invisible. A scanner that emails PDFs. A line of business app a vendor installed years ago. A service account running a nightly job. Nobody on the identity team chose them, and nobody on the business side remembers them until they stop working. So each one needs an answer before enforcement. Move it to a modern flow, replace it or isolate it on purpose. What it can't do is stay as a quiet exception that an attacker finds first. Put it all together and you have something specific. A count of who's registered. A map of how people really sign in. A list of the ones leading on SMS with reasons, and a list of the paths that can't speak modern authentication at all. That's not paperwork. That's the raw material for the rollout itself. Because once you know who is ready, who needs help, and who needs something different, you can stop treating the workforce as one block and start dividing it into waves. Section twelve designing the rollout waves. Most teams draw their waves from the org chart. Finance goes first, then sales, then operations. It feels tidy because it matches how the company already thinks about itself, and it hands every department head a date. But that's the wrong axis. A department has no single risk level and no single readiness level. Inside finance, you'll find the controller who approves wire transfers and the intern who has never touched a payment. Inside operations, you'll find laptop users and people who share one workstation across three shifts. So build waves on two questions how much damage can this person's session do if it's stolen, and how ready are they to carry a passkey today? Risk tells you who goes early. Readiness tells you who needs help first. Where those two lines cross, you get your sequence. Wave zero is the identity team and the security staff. These are the people who will build the policies, run the runbooks and answer the questions later. So they should be the first to feel what the user feels. They register, they sign in, they lose a key on purpose and go through recovery. Because it's far better to find a broken step with your own team than with a vice president. Wave zero is small, maybe a dozen people. The entry criteria are simple. The target group exists, the passkey profile is built, and temporary access pass is ready to issue. The exit criteria matter more. Every member has registered two credentials. Every member has signed in with a passkey on every device they use, and someone has written down each place. The process was confusing because those notes become your user guidance. Don't skip this wave to save time. It's the cheapest place you'll ever find a mistake. Wave one is privileged roles and cloud admins. This is the cohort we've been circling and it carries the most risk per person. Directory roles. Azure subscription owners. Anyone who can change a policy or read every mailbox. The group is small, which makes it the best return on effort in the whole program. To enter, each admin needs a hardware key from your approved list. A tap to get started, and a named person responsible for helping them to exit. Every admin holds two registered keys. The phishing resistance strength has run in report only with no unexplained failures, and the policy has been switched to enforced. Wave one is the first wave where enforcement actually happens, and that's on purpose. Wave two is executives and high risk assistants. Think about who is actually targeted. Attackers don't pick the CEO because of the title. They pick the people whose mailboxes reveal who approves payments. That includes the executive assistant, who manages a calendar and an inbox for someone senior, and the finance leads who sit one step from the bank. These users are not admins, so nothing about their role forces them early. Their exposure does, and their readiness is a different problem because they're busy, they travel and they use several devices. So this wave needs white glove help. A person who sits with them registers the credentials and makes sure the first sign in on each device works. Entry means their devices have been checked against the support floors. Exit means every device they use has been tested and they hold a backup. Then the later waves. And here the work changes shape. The general workforce comes next. Large numbers, mostly managed laptops, mostly Windows Hello or Authenticator. This is where the registration campaign and the communication plan carry the weight and where you move in batches sized to what your help desk can absorb. Cut each batch by what people hold, not by department. Frontline and shared device workers come last not because they matter less, but because they are the hardest. A shared workstation, no personal phone or hardware key in a drawer. Those need their own design, and they'd be rushed if forced into an early wave. Across every wave, the pattern holds. A wave doesn't start until the one before has met its exit criteria. Not a date on the slide. An actual check registered, tested, backed up and quiet in the helpdesk queue and you can see why the order runs the way it does. The cost of a mistake grows as the group gets larger. The damage from a stolen session grows as the role gets more powerful. Put those together and the starting point is obvious. You begin with the people who can do the most damage and the smallest group to protect. Section thirteen privileged accounts. First admins go first. One reason their sessions are the ones an attacker wants most. A normal user stolen session gets you one mailbox and admins stolen session gets you the policies, the mailboxes and the power to create more access. Same fish, completely different outcome. And the cohort is small. Maybe thirty people, maybe fewer. That's the odd part of this whole program. The group that carries the most risk is also the easiest to reach, train and support by hand. You can call each of them. You can sit with each of them. Nowhere else in the rollout does the effort pay back this fast. But before you hand them keys, look at how they sign in today. In most tenants, the admin role sits on the same account the person uses for email. The same identity, reads newsletters, opens attachments, clicks links from vendors, and holds global administrator every fish aimed at that person's inbox is a fish aimed at the role, so split them. Give each admin a dedicated account used only for Administration cloud only, not synced from on premises. So a compromise of the local directory can't reach it. No mailbox, or at least no one reading it. No daily browsing. The daily identity does the daily work, and the admin identity only shows up when something needs to change. That separation does something the passkey can't. It shrinks the places where the credential ever gets exposed. A phishing page can only trick the account. The person types into it, and the admin account never visits those pages. Now the credential itself. For admins, the default is a hardware security key, not because platform passkeys are weak. Because a key is an object you can count. You buy a specific model. You put that model on the allow list, you enforce attestation, and you know exactly what each admin holds. There's no cloud account behind it and no personal ecosystem to worry about. And every admin gets two one in daily use, one stored somewhere else in a safe, in a drawer at a different site, anywhere that isn't the same bag as the first key. Write it down. The serial number, who holds it where the spare lives because the day an admin loses a key is the day you find out whether your documentation is real. A single key admin isn't a protected admin, it's a lockout waiting for a bad flight. Then comes enforcement. And this is where the earlier design finally gets used. You build the conditional access policy that targets directory roles directly, not a group you maintain by hand the roles themselves. Someone activates global administrator and the requirement is already attached. The grant control is the phishing resistant authentication strength, or the custom one that names your approved hardware cover. Azure management as a second target, the Azure Portal, the command line, the management API's. A subscription owner can delete a production environment without ever touching the entire console, so the strength has to follow them there. Run it in report only. First, read the failures by name. Fix the ones that are real. Then switch it on with your break glass accounts excluded and watched. When this wave is done, something specific has changed. The accounts that can rewrite your tenant can no longer be signed into by anyone holding a password and a phone, but admins are a few dozen people carrying keys you bought for them. Everyone else is a different problem because the broader workforce won't be carrying anything you chose. They'll carry whatever is already in their pockets and on their desks. Section fourteen device reality what users hold in their hands. Every plan assumes a device, so look at the device. A passkey is only as available as the thing that holds it, and the workforce doesn't carry one standard machine. It carries a mix. Whatever it bought three years ago, whatever someone's phone happens to be, whatever browser got installed on it Tuesday, start with windows because that's where most tenants live. The main credential here is Windows Hello for business. It's a key pair stored in the machine's secure chip, unlocked by a pin or a face or a fingerprint. The user doesn't see a passkey. They see the same gesture they use to unlock the laptop, and it's phishing resistant because the private key is tied to the device and to the entry identity. But there's a catch that matters. The device has to be in the right state. A device that's intra joined or hybrid joined is part of the organization Windows Hello for Business Provisions. Clearly, they're a device that's only registered a personal laptop with a work account added is a different story. It can hold a work credential, but you control far less about it. So before you plan a wave, split the windows fleet into joined and registered. Those two groups need different promises. Platform passkeys on windows work alongside that, the same Windows Hello can hold a passkey for a site, and the settings we covered in the passkey profile decide whether users may create one. Now. Apple, macOS and iOS both support passkeys at the platform level, touch ID on a Mac, face ID on an iPhone, and the credential sits in the secure hardware for entry. The common path on iPhone is Microsoft Authenticator holding a device bound passkey. And here's where browser behavior gets in the way. Safari, Chrome, and Edge don't all handle the passkey prompt the same way on a Mac, and a user who signs in through a third party apps embedded WebView may not get the prompt at all, so don't test with one browser. Test with the one your people actually open and test with the apps that wrap sign in inside their own window, because those are the ones that break quietly. Android follows a similar pattern with its own twist. Authenticator can hold a passkey on Android two, but it depends on the version of the operating system and on the version of the app. An older phone that can't run the current authenticator can't hold the credential, and no setting in the admin center changes that. This is the user from the baseline list. With the work phone that's too old. They show up again here. Then there's the part team. Skip the version flaws. Every one of these paths has a minimum a minimum windows build, a minimum, Mac OS, a minimum iOS, a minimum Android release, a minimum browser version, a minimum authenticator release. And those numbers move. So don't trust any list you read on a slide, including this one. Before you promise anyone anything, do three checks. Read the current Microsoft documentation for each platform you support. Pull the actual operating system and browser versions from your device management data so you know how many machines fall below the floor, and pick a handful of real devices from each group, and register a passkey on every one? That last test matters most documentation tells you what should work. A tested device tells you what does. Then sort the result. Devices that clear the floor go into the standard waves. Devices that don't need an upgrade first, or a different credential like a hardware key. Don't enroll them anyway, and hope a user who registers on a half supported device finds out that sign in, which is the worst moment, and you'll notice something once you've sorted the standard cases, the managed laptop and the current phone cover most of the workforce. They're not where the effort goes. The effort goes to the people who don't fit the shared workstation with no personal phone. The kiosk, the worker who can't carry a device at all. Section fifteen shared devices, kiosks and frontline workers. Every assumption we've made so far has a person attached to a device one user, one laptop, one phone in a pocket. The passkey lives on one of those, and the unlock gesture belongs to that one person. It's a clean picture, and on a shared workstation, it falls apart. Think about a distribution centre, one terminal on the floor and three shifts rotate through it in a day. Nobody owns the machine. Windows hello for business. Once a user tied to a device so it has nowhere to land, a platform passkey would sit in a chip that twenty people touch and the phone. Many of these workers can't bring one onto the floor or won't use a personal phone for a work app. Some sites ban them outright for safety or for security. So the authenticator route is closed too. This is the user from the baseline list again. The one leaning on a text message. Not because they like it. Because it was the only thing that worked for this group. The hardware key is usually the answer, not a key bolted to a machine. A key each worker carries on a lanyard or on a keyring. Usb-a to Usb-c for terminals with ports, NFC for tablets, and phones that can tap. Some models do both. The worker walks up, touches or taps, enters a short pin and signs in. Then they walk away and the credential goes with them. That's the part that makes it work on shared hardware. The identity lives in the object in the worker's hand, and the machine is just a place to present it. Nobody has to trust the terminal with anything. Now look at the sign in itself, because shared devices change what a good session looks like on a personal laptop. You want a long session. The user signs in once and stays signed in on a shared terminal. That's the opposite of what you want. The next person in line shouldn't inherit the last person's mailbox. So the questions are about lifetime and cleanup. How long does a session last before it ends? Does it end when the worker walks off? Does the browser wipe itself between users and has features aimed at this, including settings built for shared device mode and for frontline scenarios. Check the current documentation for what your platform supports because it differs by operating system, and pair it with sign in frequency in conditional access. So a session on a shared device expires in hours, not weeks. Short sessions cost a little convenience, with a key signing in again takes a few seconds, which is why this combination works at all. A password and a code would make short sessions miserable. A tap makes them tolerable. Then there's the part that decides whether the plan survives contact with finance, cost and logistics. A key isn't free at a few dozen admins. Nobody notices. At several thousand frontline workers, it's a purchase order, a shipping plan, and a line in somebody's budget. And every one of those workers needs a spare, or at least a way back in when the first one disappears. So plan for loss because keys get lost, left in a jacket, run through a wash, dropped in a parking lot. You won't know your real loss rate until you've run a wave, but assume it's not zero. Build the replacement path before you hand out the first key. Who holds the stock? How does a worker request a new one? How does the old one get deactivated? So a found key can't be used by a stranger, and the key should always need a pin. So a lost one is only half a credential. Think about handout. Two. Does each key get registered before it ships, or does the worker do it at their first shift with a supervisor and a temporary access pass? Both work. The first is cleaner for security. The second is easier on logistics. Pick one on purpose and write it down. None of this is glamorous. It's inventory work, but it's the difference between a plan for frontline staff and a slide that says frontline staff with an arrow. And notice what these workers share. The organization owns the key, the terminal and the environment. So you control all three. The next group is the reverse. The device belongs to the user or to another company entirely, and your organization controls almost none of it. Section sixteen Byod contractors and external users. Start with the personal phone. A lot of tenants let people register work credentials on devices they own. Authenticator on a personal iPhone. A passkey on a home laptop. It's convenient and it saves you buying hardware. But look at what you actually know about that device. Nothing. You don't know the patch level, whether it's jailbroken or who else in the house can unlock it. So what can you require? Less than you'd like on a personal device. You can usually ask for the app, a screen lock and a pass key bound to the secure hardware. Through app protection policies, you can wrap the work data without managing the whole phone. What you can't do is inspect the device or demand a specific build of a personal operating system. Without a fight. That's an acceptable trade for most people, and the passkey itself helps here. The private key never leaves the chip, so even a device you can't see can't hand it to a phishing page. The risk isn't the credential, it's the registration moment and the device that stays behind after someone leaves. Which is why leavers and lost phones need a removal step you can trigger from your side. Now the harder question people who don't work for you guests, partners, contractors, they sign into your resources with an identity from somewhere else. And the first thing to understand is that two tenants are involved, and they each have an opinion about authentication. By default, when a guest opens your app, your conditional access policy applies if it requires the phishing resistant strength the guest has to satisfy it, but the guest credentials live in their home tenant or in a personal account. They may hold a passkey there, they may not, and they registered it against their own organization, not yours. That's where cross tenant access settings come in. Under External Identities, you can configure how your tenant treats inbound users from another organization. One option matters more than the rest trusting multi-factor authentication claims from the partner tenant when you turn it on. A guest who already completed MFA at home isn't asked again in yours. Their home tenant vouches for them, and your policy accepts the claim. Be careful with that. A claim is only as good as the tenant that issued it. If the partner's tenant still accepts text messages, then the claim you're trusting was earned with a text message. You've imported their weakest path into your strongest policy and a detail that catches teams out. Trusting an MFA claim and trusting a specific strength are not the same thing. Check what the claim actually proves before you build an access rule on top of it. Read the current documentation for how authentication strength treat guests. Because this area has changed more than once. So where do you actually require phishing resistance? Sign in for outsiders. Practical cases first. A managed service provider with administrative rights in your tenant. A long term contractor with a mailbox and access to financial systems. A partner whose tenant you've already reviewed and trust. For these, the requirement makes sense and you can ask the other organization to meet it in writing as part of the contract. In practical cases, come next. A one time guest who opens a shared document once a customer reading a single file. A small vendor with no identity team and no budget requiring hardware keys from them won't improve security. It'll push them to email attachments, and you'll lose visibility altogether. So tier IT strict for outsiders with real power, reasonable for those with moderate access and for the rest, shrink what they can reach, shorten their sessions and review them on a schedule. Notice what all of this has in common. Whether the user is internal or external, on a managed laptop or a personal phone, the same question follows them. What happens on the day the credential disappears? Because it will. And that moment, not the sign in, is what decides whether the program survives. 00:53:45 Speaker: He hit a section seventeen recovery is the real security boundary. An attacker doesn't test your strongest door. They test all of them, and then they use the weakest one that opens. That's not a clever insight. It's just how the work gets done because nobody gets paid for the hard path when an easy one exists. So the strength of your tenant isn't the strength of your best sign in. It's the strength of your worst way back in. And the way back in has a name recovery. Look at what a recovery path actually is. It's a second front door built for the moment. The first one fails. A user who can't sign in needs some way to prove who they are without the credential they just lost. That path has to be easier than the main one. If it were just as hard, it wouldn't be a recovery path because the user couldn't use it either, which means it's weaker by design and an attacker knows that. Here's the picture you've rolled out. Passkeys admins hold hardware keys. The conditional access policy demands the phishing resistance strength, and the sign in logs look beautiful. Then the attacker stops trying to phish anyone. They go looking for the reset. A password reset by text message. A help desk agent who will issue a code for a convincing voice on the phone. A self-service page that accepts a personal email address if that path ends in a working session or in a freshly registered credential, then the phishing resistant sign in was decoration. A phone call can undo it. Say that plainly because it's the part teams resist a phishing resistant sign in with a phone call reset behind. It is not phishing resistant. It's phishing resistant right up until someone asks nicely. So recovery isn't a support topic that sits after the security work. It is the security work. Every decision you make here either keeps the strength you built or quietly hands it back. Start by naming what actually goes wrong, not in theory. In practice, three things happen again and again. First, the loss device. A phone left in a taxi. A laptop taken from a car. A key that fell out of a bag. The credential is gone and the person is locked out. But there's a second risk hiding in that scenario. Someone else might now be holding a piece of the credential. That's why the unlock pin matters, and why you need a way to remove the lost item from the account. Second, the broken phone. Nothing was stolen. The screen cracked, the battery died, or the device just stopped. Here the user is genuine, urgent and often travelling. This is the scenario where pressure is highest and someone is most tempted to bend the process. Third, the replaced laptop. It's the quietest of the three and the most common. A refresh cycle hands someone a new machine, and the old Windows Hello credentials stays behind on hardware that's being wiped. Nothing is wrong. The user just needs a credential on a device that never had one. And if you run refreshes in bulk, you'll face this hundreds of times in a single quarter. Three scenarios. Each one needs an answer written down before the first wave starts. Not improvised at a desk. And the first answer is the cheapest. Don't let anyone be down to one credential. Every user registers more than one, a passkey on the laptop and a passkey on the phone, a hardware key in the bag, and a second one at home. Then a broken phone is an inconvenience because the laptop still works, and a replaced laptop is a non-event because the phone still holds the other credential, the user recovers themselves without calling anyone and without any identity check at all. That's the best recovery process there is. The one that never runs. Make it a rule, not a suggestion. Registration campaigns should track people with exactly one credential and treat them as unfinished work for admins. Two keys is the exit criterion we set earlier. Not a nice extra, but it won't cover everyone. Some people will lose everything at once. The bag that held the laptop, the phone and the key, a house fire, a long flight with no spare for them. There has to be a path that starts from nothing and ends with a person you can trust holding a working credential. So the real question gets sharper. How do you prove someone is who they say they are when they have nothing left to prove it? With section eighteen temporary access pass and identity verification. Let's start with the tool. The tool is simple. A temporary access pass is a passcode and admin creates for one user. It counts as strong authentication so it satisfies the same requirements. A pass key would, but only for a short window, and you pick the shape when you create it. One time use means the pass works once the user signs in registers a pass key and it's spent. Multi use lets the same pass work more than once inside its lifetime, which helps when a user needs to set up a laptop, then a phone, then a hardware key in one sitting. The lifetime itself can run from minutes up to a few days. The exact limits are set in the authentication methods policy, so check what your tenant allows. Now scope it narrowly on purpose. A pass that lasts a week is a week long window where anyone who intercepts it can act as that user. So the default should be short and one time an hour or two used once. Reach for multi use only when the registration work really needs it, and even then keep the clock tight. A tap isn't a convenience, it's a strong credential you're handing out by hand. Which raises the real question who gets to hand it out? Because the ability to issue a tap is the ability to become any user you can reach. If an attacker holds that permission, nothing else in the policy matters. They pick a target, generate a pass, and sign in as the person. No fishing, no token theft, just a button. So protect the permission like you'd protect a global administrator in entra. Issuing a tap depends on the role and the authentication administrator and privileged authentication administrator roles. Carry it. Keep that group small. Require the phishing resistance strength to use those roles. Activate them through privileged identity management just in time with an approval or a reason on record, and scope the help desk with administrative units. So a tier one agent can issue a pass for ordinary users, but never for admins. Admins should be reset by someone senior through a slower path than log it. Every tap creation is an audit event. Someone should look at that list weekly and ask a plain question. Does each one match a ticket? Now, the part no setting can do for you. Before anyone issues a pass, they have to know who they're talking to. That's identity verification. And there's a ladder of options. Start at the bottom. Manager approval. The agent contacts the users manager through a channel already on record, and the manager confirms it's cheap and it scales, but it only works if the manager is reachable and the channel can't be faked. A call to a number the caller supplied proves nothing in person. The user walks to a desk, shows a badge or a government ID, and gets the pass handed over on the spot. It's the strongest low tech option, and it's perfect for new hires and for people at a site with staff, it just doesn't help a user stranded in another country. Video A live call where the agent compares the face to a photo on file and asks the user to show an ID better than a voice. Because a voice is easy to fake and a live face is harder, but it leans on the agent's judgment. And judgment is exactly what we're trying to take out of the system. Which brings us to the newer controls. Microsoft enter a verified ID, lets a person present a verifiable credential, something issued and signed by a trusted source instead of just talking and face check goes one step further. It matches a live selfie against a trusted photo, usually from a government ID that was verified earlier. The user proves they're the person on the record, and the agent never has to decide whether a voice sounds right. These are still emerging and availability, licensing and supported flows change, so read the current documentation before you build on them. But the direction is clear. Verification moves from a person's hunch to a check. The system performs, so the order for a lost everything case looks like this. Verify through the strongest method you can reach. Issue a short one time pass. Have the user register a new passkey while someone is still on the line. Then confirm they have two credentials before the call ends. That closes one door, but there's another one and it's been opened the whole time. A user who forgets a password doesn't need a person at all. They go to a page and reset it themselves. And that page has its own rules about what counts as proof. Section nineteen SPR legacy methods and closing the back door. Self-Service password reset was built to keep people out of the help desk queue. It does that job well. A user forgets a password, opens a page, proves who they are, and picks a new one. No ticket, no wait. But look at what proves who they are. Means in a default tenant, a text message to a phone number. A call to the same number. A code sent to an email address. Security questions. If someone turned them on years ago and never looked again. Those are the weakest methods in your tenant. And they sit on a path that ends in a working account. So here's how the bypass works. An attacker doesn't need to defeat your passkey. They go to the reset page, name the target, and ask for a text if they've swapped the SIM or phished the code, or simply guess the answer to a security question, they set a new password. Then the account is theirs to explore. Depending on how your policies are built, that password may or may not get them far, but in plenty of tenants it gets them a registration page and from there they add their own credential. The passkey was never touched. It just didn't matter. This is the same failure we saw in recovery running through a different door. SPR is a parallel path, and it follows its own rules set in its own policy. The number of methods required, which methods count, who's in scope? Nothing about a passkey requirement in conditional access changes, any of that. So the fix is to shrink the path as passkey adoption grows. Start by looking at what Sspr accepts today. Then ask a plain question for each method. Is anyone still relying on this? As more people hold two registered passkeys, more of them can recover themselves without ever touching a text message. Once a group reaches that point, remove the weak methods for that group require the stronger ones, cut the number of allowed methods down and drop the ones that can be intercepted. The same logic reaches past SPR. Text messages and voice calls aren't only a reset problem, they're a sign in problem too. And as long as they stay registered, they stay available to an attacker who's forcing a downgrade. So plan their retirement on purpose with a date. And that plan is mostly a communication plan. Think about the user on the receiving end. For years the text message was security. It was the thing they did to prove they were real. Now you're taking it away and they'll reasonably ask why. So tell them in plain terms, the old method can be stolen without their knowing. The new one can't be handed over. Give them the date. Tell them exactly what to do before it and say where to get help. Then send it again closer to the day because nobody reads the first one. Now, the part that decides whether this goes well or badly. Sequencing you disable a weak method only after the strong one is registered never before. Not in the same week. Not as a push to speed things up. If you remove SMS from a group while half of them still depend on it, you haven't raised security. You've created a queue of people with no way in, and every one of them is calling someone, so the order is fixed. Register confirm two credentials per person. Watch the usage report until the weak methods go quiet. Then narrow the SPR policy for that group and only then remove the old registrations. Each step waits for the one before it. Get that right and the back door closes without anyone noticing. Get it wrong and the people who notice first are the ones who answer the phone, which is the next problem. Because when something breaks, they're the ones who hear about it or help desk impact and the call volume curve. Every identity project ends up as a phone call. Not a dashboard, not a policy, not a log entry. Someone picks up a handset or opens a chat window and says, I can't get in. And whoever answers that call is now running your security model, whether anyone trained them for it or not. So let's look at what those calls actually sound like the first type is the lost or broken device. I left my phone in a taxi. My laptop was replaced and now nothing works. We covered the recovery logic already for the help desk. It's the highest stakes call because it's the one that ends with a credential being issued. The second is my key doesn't work, and that sentence hides at least four different problems. The key isn't registered, the pin is wrong, or it's locked. After too many tries. The key model isn't on your allow list, so registration quietly failed or the key is fine, but the app opened a sign in window that never shows the passkey prompt. Same sentence from the user. Four different fixes. Third registration confusion. Users start the setup, hit a screen they don't understand, and stop halfway. They end up with a passkey on one device, nothing on the other, and a belief that they finished. These calls usually come a week later on the day they need the second device and fourth browser quirks. An old browser build a profile that blocks the prompt, a password manager that grabs the passkey request and offers to save it somewhere it shouldn't go. None of these are your fault, and none of them are the user's. They're just the friction of a new credential meeting an old environment. Now, the shape of the curve, because this part helps you plan staffing volume doesn't rise and stay high. It spikes with each wave. The weaker group gets its registration deadline, called jump. People who ignored every email suddenly care. Then over the next few weeks, the volume falls, usually below where it started. Why? Because the group that used to call about password resets and lost codes now has nothing to reset and nothing to lose. That's the part that surprises finance. The spike is real, but it's a spike per wave, not a new baseline. So don't hire for the peak schedule waves so they don't overlap and put extra hands on the calendar for the two weeks after each deadline. Then let the line go quiet, but a help desk gets a second kind of call. And that one isn't from a user at all. Think about what an attacker does. Once the sign in is hard to fish, they stop fishing. They pick up the phone and call your help desk, and they play the part of someone with a bad day. I'm traveling. My phone broke. I have a meeting in ten minutes. My boss is waiting. They know the name of the manager. They know a project. They've read it all on LinkedIn and the person who answers is trained to be helpful. Because helpful is the job. Every tool in the process. Every temporary access pass, every key restriction is only as strong as the agent's willingness to say no. Pressure is the attack. Urgency is the whole technique, so the rule has to be absolute. The helpdesk never bypasses the process under pressure. Not for an executive, not for a user who sounds upset, not for someone who says the CEO is on the line. In fact, a rising level of pressure should be treated as a signal because a real user with a real problem will wait ten extra minutes and a caller who won't is telling you something to make that rule workable. Give agents words. To say a script isn't a leash, it's cover. I understand this is urgent. I'm required to verify you through the approved process before I can issue access, and that takes a few minutes. An agent who can say that without apologising is protected from the one caller who needs them to fold, and then the verification steps themselves. The same ladder from earlier manager confirmation through a channel already on record, a callback to a number on file, an in-person check video, or a verified credential the agent doesn't pick based on mood. They follow the step that matches the request, and they record what they did right. All of this down before the first wave and hand it over before the first call. Because a rule without tools is just a wish. What the help desk needs now is the right permissions, the right runbooks, and the right view into the logs. Equipping the help desk. Start with permissions because that's where most designs go wrong. A tier one agent should be able to do a small set of things. Reset a password for an ordinary user. Issue a short one time temporary access pass. Remove a lost credential from an account. Read the sign in logs for that user. That's it. Nothing on that list can rewrite policy and nothing on it touches an admin. Everything else escalates. Anyone holding a directory role, anyone on the executive list, any request to change an authentication method policy, or to add someone to an exclusion group. Those go to tier two or to the identity team through a slower path with a second person involved. Make the boundary physical, not just a rule in a document. Use administrative units to scope what each agent can touch, so a tier one account literally can't issue a pass for a global administrator. The tool says no, so the agent doesn't have to. Now the runbooks five of them cover most of what you'll see. One the lost or stolen device. two, the broken phone where nothing was stolen. Three the replaced laptop with no credential on it yet. Four my key doesn't work with a short decision tree inside it. Registered pin, Allowlist browser and five. The user who started registration and stopped halfway. Keep each runbook to one page. Who to verify how, which step to take, what to confirm before hanging up, and every one of them should end the same way. The user holds two credentials before the call closes. A runbook that ends with one is just scheduling the next call. Then there's the skill that saves the most time reading the sign in log when someone says it won't let me in, the log already knows why. Open the sign in event for that user. Look at the conditional access tab. Find the policy that applied, and read the result. If the authentication strength wasn't satisfied, the log says so and it shows which methods the user actually completed. Maybe they signed in with a password and a push and the policy wanted a passkey. Maybe they never registered one at all. Maybe the sign in came from a legacy app that can't present a passkey, which is a very different fix. That one view sorts the call in about 30s not registered means a registration problem registered, but failing means a device or browser problem satisfied but blocked means a different policy entirely. Teach every agent to open that tab before they ask the user a single question. Then measure the desk because you can't improve what nobody counts. Three numbers do most of the work. First, contact resolution. How often the first agent fixes the problem without passing it on time to reregister. From the moment a user calls to the moment they hold a working credential again, an escalation rate. How many calls leave tier one read them together. A high escalation rate usually means the runbooks are thin or the permissions are too tight. A long reregister time usually points at slow identity checks, and that's where a better verification method pays off. And watch the trend by wave, not the average. The numbers should spike after each deadline, then settle lower than before. If they don't settle. The problem isn't the desk. It's upstream because the cheapest call to handle is the one that never arrives. And most of these calls start the same way. Someone received a message they didn't read or read and didn't understand. The help desk can't fix that after the fact. Communication has to fix it before the first wave starts user communication that actually gets read. Most rollout messages die in the inbox. Think about the subject line action required enables stronger security. Users have seen that line for years. It came before a password expiry before a training deadline, before a mandatory update that broke their printer. So they've learned what it means. It means someone else's problem dressed up as theirs, and the message itself usually makes it worse. It talks about the organization to protect company assets. We're strengthening authentication controls. The reader has no company assets. They have a Monday morning, a full calendar, and a laptop that mostly works. Nothing in that sentence touches their day, so it slides right off the floor. Isn't the wording. It's the assumption that people will stop what they're doing because security asked. So change what the message says. Start with what the user gets. No more codes to read off a phone. No more prompts. That buzz at the wrong moment. No more typing a six digit number before a meeting starts. Sign in with a fingerprint or a face, the same gesture they already use to unlock the device, and it takes about two seconds. That's the pitch, not more secure. Faster the security comes along for free, and you can mention it in one line near the end. It's true too, which helps. Nobody has to be talked into something that's better for them. Now, the order of messages. Because one email is never enough for steps and they each do a different job. First awareness, a short note weeks ahead that says what's coming and why it's good for them. No action yet. Second instruction. Exactly what to do in numbered steps with a screenshot of the real screen. They'll see. Third, the deadline. A date written plainly with what happens if they miss it. Fourth, support. Where to go, who to call, and when the desk is staffed, space them out. Send the first before anyone is under pressure, send the second. When the registration window opens, send the third a week from the date. Then again two days before people act on the second reminder, not the first plan for it. And don't read a quiet first week as success. Then put the nudge where the user already is. Enter. I can run a registration campaign. When someone signs in, it prompts them to set up the stronger method right there in the flow with a button. Instead of a link to a document, you scope it to a group which fits the wave model, and you control how many times a user can snooze it. That matters because a prompt in the moment beats an email they'll read tomorrow and forget by lunch. Use both. The campaign catches people mid sign in. The email gives them context and a deadline alone. Each one leaves gaps. Together they cover most of the workforce. Now who sends it a message from a no reply address carries no weight. Nobody replies to it. Nobody trusts it. And it looks a lot like the phishing mail they've been warned about. Ironic, since you're asking them to adopt a credential built to stop exactly that. So send it from a person, a real name, a real mailbox that gets read. Better still, a leader. The group respects the head of a department telling their own people, I've done this. It took four minutes, and here's the date. One note like that moves more users than three security bulletins. Executives who register first and say so give everyone below them permission to follow reply to matters here as well. Put the support path in the message and make sure someone watches the thread that covers what lands in the inbox, but a message is only half the experience. The other half is the moment a user sits down, follows the steps and sees something unfamiliar on their screen. What they see in that moment decides whether they finish. 01:12:47 Speaker: The training uses to recognize the new normal. A user can only spot something wrong if they know what right looks like. So show them a passkey sign in has a very small shape. The user types their name or picks it from a list. The device asks for a fingerprint, a face, or a pin. They give it there in. No code to read, no number to match, no second screen on a phone. If a page ever asks them to do more than that, something is off. That's the training, not a lecture on cryptography, just a clear picture of a short, boring sign in. And one rule if it gets longer or stranger stop and report it. And this means retiring advice you've given for years. Check the URL, look for the padlock. Approve the prompt only if it was you. That was the guidance for the old model, and it put the whole burden on the person at the keyboard. It asked them to outthink a page built by someone who does this for a living. Some of them did, many didn't, and you can't blame them for it. With a passkey, the browser checks the domain, the user doesn't. A lookalike page gets nothing because the key won't answer a site it doesn't recognize. So tell people that plainly they're no longer the last line of defense on every sign in and take the old advice out of your training decks, your posters, and your phishing quizzes because mixed signals teach nobody anything. But some rules don't retire. They get sharper. Never share a temporary access pass. Not with a colleague, not with someone from it who calls out of the blue. A real help desk agent issues it to the user directly, and the user types it in themselves. Never read a code back to a caller either. No legitimate process ends with someone reading numbers aloud, and if a message pushes them to set up a new credential they didn't ask for, that's a report, not a task. Think about why these rules matter more now. When the sign in is hard to fish, the attacker's next move is to talk the user into handing something over a pass, a code, a reset. So the human judgment call doesn't vanish. It moves. It shifts from is this page real to? Is this person asking for something they shouldn't? That's a smaller question and an easier one to teach. Now, how long should all this take? Minutes. A one page guide or a ninety second video shown at registration when the user is already paying attention? Three points. Here's what a normal signing looks like. Here's what you never hand over. Here's who to call anything longer, and you'll lose them and you won't get them back. A forty minute course gets clicked through with the sound off. Reinforce it where they work. A short note in the registration flow. A line in the help desk confirmation email. A reminder when the next wave starts. Small. Repeated. Specific. Get that right and users know the new normal well enough to notice when it breaks. But systems break, too, and a rollout rarely fails because of one dramatic mistake. It fails through a handful of small ones, each of them predictable and most of them avoidable if you know where to look. Failure modes and pitfalls. Rollouts don't fail in one big moment. They fail in small, boring ways. Five of them show up again and again, and every one of them is visible in advance if you know where to look. The first is the lockout. A team builds the conditional access policy, sets the ground control to the phishing resistance strength, and turns it on for a group Monday morning. Half that group can't sign in. Nobody registered a passkey because the registration campaign was scheduled for next month. The policy was correct. The order was wrong. Enforcement went in front of registration. Now the people who can't satisfy the rule are the same people who need a temporary access pass to fix it all. Calling at once. Report only mode exists to catch this read the logs. Count how many users would fail, and don't flip the switch until that number is close to zero. Second, the single key admin picture an administrator with one hardware key on a keyring goes through the wash or stays in a hotel room or snaps in a bag. Now, the account that can reset everyone else's credentials can't sign in itself. If that admin was the only one holding a role, the tenant has a real problem. This is why two keys per admin was an exit criterion, and why the second one lives somewhere different from the first break. Glass accounts are the safety net, but a net you use every time a key goes missing isn't a net, it's a habit. Third, silent failures some apps and browsers can't present a pass key at all. An old embedded browser inside a desktop app. A legacy client using basic authentication. A mobile app that opens a WebView with no passkey support. What does the user see? Often nothing useful. The prompt doesn't appear. The sign in spins and then it errors with a message that says nothing about passkeys. They report the app is broken. You spent an hour on the app before someone opens the sign in log and sees that the strength requirement wasn't met. Find these paths during the baseline before enforcement by looking at which apps and clients appear in the sign in data and fix or exclude them on purpose. Fourth, exclusions that only grow. Someone needs an exception for a project. Someone's executive assistant can't use a key yet a vendor integration breaks. Each one is reasonable. Each one gets added to an exclusion group, and nobody writes down when it should leave. A year later, that group has two hundred members, half of whom nobody remembers adding, and those are the accounts an attacker will find because they're the ones the strong policy never reaches. Every exclusion needs an owner, a reason and an expiry date. If it can't have all three, it shouldn't exist. Fifth, the mixed stack your policy for the Microsoft three. Sixty five apps demands the phishing resistance strength, but a second policy written two years ago for a different app only asks for regular MFA, and a third covers all cloud apps with a looser rule. Conditional access applies every policy that matches, and the user has to satisfy all of them. That sounds safe until you see the gap, a resource that none of your strict policies target, or one that a broader exclusion skips falls back to the weaker rule. The attacker picks that app, signs in with a phished session and then move sideways using tokens. The stronger apps will accept strength on the front door means little if a side window is open. So audit the whole stack, not just the new policy. List every policy, who it covers, which resources it targets, and what it demands. Look for the app with the weakest requirement because that's where the real tenant strength sits. Five failures. And notice that none of them is a flaw in passkeys. They're all gaps in sequencing, ownership or coverage, which leaves a harder question once you've avoided most of them, how do you actually know the program is working? Measuring outcomes and proving risk reduction. Most programs measure what's easy to count. Policies created, users enrolled, keys shipped. Those numbers go up so they look like progress, but none of them tells you whether an attacker has a harder day than before. So split the measurement into three groups and read them together. Start with adoption because nothing else moves until this does. The first number is registration rate by wave, not one tenant wide percentage, which hides everything for each wave. How many people hold a phishing resistant credential and how many hold two? That second figure is the one that predicts your help desk load, so track it separately. A wave at ninety percent with one credential each. Is a wave still waiting for a bad week. The second number matters more. What share of actual sign ins use a phishing resistant method. Registration is a promise. A sign in is behavior. A user can register a passkey in March and still type a password and approve a push every morning. Because the old path is still open and still familiar. The authentication methods activity report and the sign in logs show which method completed each sign in, so you can see that gap directly. When registration is high and usage is low, the weak methods are still doing the work, and that's your signal to start narrowing them. Now the security side, this is where you prove the point of the whole effort. Look at token theft detections. Entry ID protection raises risk detections for anomalous tokens, and for sign ins that look like adversary in the middle activity. Watch the count for the populations you've moved. It should fall. If it doesn't, the attacker is finding another route and you need to know which one. Watch the risky sign in trend the same way. Split by wave. A group on passkeys should show fewer risky sign ins than a group still on prompts, and the contrast between them is your best evidence. It's a controlled comparison you built by accident, and it's more convincing than any vendor claim. Then the blunt one compromised account counts how many accounts were confirmed compromised per quarter, before and after. Be careful here, though. A low number can mean good defense, or it can mean nobody is looking. Pair it with detection coverage so a drop reflects fewer incidents and not fewer eyes. One caution on all of this passkeys. Remove one attack class. They don't remove consent, phishing or a stolen session from a compromised endpoint, or an attacker who calls your help desk. If your numbers improve less than you expected, check which attack types remain before you question the program. Third group operations, the cost side and the part finance will ask about help desk volume by wave as a curve. Expect the spike at each deadline and the fall afterward. Then compare the settled level to where you started. Password reset calls and lost code calls should shrink for migrated groups, and that reduction is a real saving. Pair it with recovery time. From the moment a user calls to the moment they hold a working credential. If that number creeps up, your verification process is the bottleneck. Now the conversion problem. Everything above is accurate and almost none of it reaches an executive in a form they can use. Ninety two percent registration. Four thousand passkey sign ins. Nobody on a leadership team can act on those. Their feature counts. What an executive wants to know is simpler. Are we less likely to get breached and what did it cost? So translate instead of registration rates. Say the accounts with the most power. The ones that could move money or change the tenant can no longer be taken over by a fake login page. Instead of risky sign in trends, say attempts against our people that used to succeed now fail. And here's the count instead of helpdesk volume. Say we spend less time resetting passwords than we did a year ago, and we can put hours on that one. Slide three or four numbers, each tied to a business outcome and one sentence about what remains exposed. That last sentence builds more trust than the rest because it shows you're measuring honestly. Do that every quarter and a pattern appears. The early waves produce dramatic movement. Later ones produce small, steady gains, and the work changes character. It stops being a project with a finish line. It becomes something you have to keep running. Governance. After the rollout, the last wave ends, the dashboard goes green and the team moves on to the next project. That's the moment the drift starts. Not from anyone's mistake, from the slow pull of a tenant that keeps changing while nobody's watching the policy. Start with people because people never stop moving, a joiner arrives and the first thing they should do is register a passkey. So build that into onboarding. A new hire gets a temporary access pass on day one, handed over in person or through a verified step, and registers two credentials before they touch anything else. If you leave it to chance, they'll sign in with a password and a text message, because those still work and they'll stay that way for months. Movers are quieter, someone changes roles, and now they hold a directory permission or a finance approval they didn't have before. They belong in a stricter group, but the group membership follows the old job unless someone updates it. So tie it to the role. Change itself. Dynamic groups help here since the membership moves when the attribute does leavers need a removal step with teeth, disable the account, revoke the sessions, and clear the registered credentials, especially on personal phones. You'll never touch a passkey on a device you don't manage is still a door. Close it from your side, then the device replacement, which we saw in recovery, make it part of the refresh runbook. New laptop goes out, the user registers a credential on it, and only then does the old machine get wiped. The old credential comes off the account after that small order. Big difference. Now the authenticators themselves. They change faster than most policies do. When you set key restrictions and an A agueweed allow list, you made a decision about which hardware to trust based on what existed that quarter. New models, ship vendors retire old ones. A firmware flaw turns up in the key you approved, so put a review on the calendar twice a year at least. Look at which guides are actually registered in your tenant. Compare them against the list and ask a plain question about each. Do we still trust this? Then check whether new platform and synced passkey options. Now meet your bar and whether your attestation rules still match your risk. A list nobody reads turns into a list nobody trusts. The same discipline applies to exceptions. We said every exclusion needs an owner, a reason, and an expiry. Governance is where you enforce it. Run an access review on the exclusion groups quarterly. Ask each owner to confirm every member still needs to be there. If an owner doesn't answer, the members come out. That sounds harsh, but silence is data. Break glass accounts, get their own review, confirm they exist, that the credentials are stored where they should be, that the sign in alerts still fire and that nobody has quietly used one for convenience. Then test one, sign in, confirm it works, and write down the date. An emergency account you haven't tested is an assumption, and watch the thing that erodes everything else. The baseline sliding back to what SMS. It happens through small doors. A new SBR group that gets the default methods. A fresh application policy that asks only for regular MFA. A user who reregisters a phone number because it's easier. None of it looks like a decision, so measure it. Track the share of sign ins that complete with a weak method and set a line you won't cross when the number rises. Treat it as an incident, not a trend. Do this work and the program holds its shape. But holding the shape isn't the goal. Over a few years, the question changes. It stops being how do we protect the sign in and becomes what do we want the sign in to be? It says section twenty seven. The new model context over challenge. Every sign in you've ever built asks the same thing a question. Enter this. Approve that. Read the number. Prove your. You and the user answers because answering is the job. The whole old model rests on a person standing at the gate, deciding over and over whether to open it. A passkey changes who does the work. The user doesn't answer a challenge anymore. The device proves something. It holds a private key that never leaves. It checks that the site is the real one, and it signs the person. Adds one thing a fingerprint, a face, a pin. That's presence, not judgment. They aren't deciding whether a page is genuine. They are confirming they're there. That's the shift from a challenge. The user answers to a credential the device proves, and that matters because of what the device can also tell you. A passkey sign in doesn't arrive as a bear. Yes, it arrives with context which device, whether it's managed, whether it's healthy, where it's coming from. The old prompt carried none of that. It was a person pressing a button in the dark. Now, a passkey doesn't protect everything on its own, and it's worth being exact about where it stops. The sign in is one moment after it, the user holds a session token, and that token is a credential too. If malware on the endpoint steals it, the attacker skips the sign in entirely. That's the gap token protection is built for. It binds the session to the device it was issued on, so a stolen token fails somewhere else. Passkeys protect the door token protection protects what you carry out of it. Then device compliance conditional access can ask whether the machine is enrolled, patched, and encrypted before it grants anything. A phishing resistant credential on a compromised laptop is still a compromised laptop, so the policy should ask about both who is signing in and what they're signing in from. And continuous access evaluation covers time. A session shouldn't stay valid for hours after something changes. When an account is disabled, a password is reset or a risk signal. Fires supported apps can cut the session near immediately instead of waiting for the token to expire, the sign in stops being a single event. It becomes a condition that has to keep holding. Stack these and you can see the structure. Passkeys prove the person and the origin. Device compliance proves the machine token protection holds the session in place. Continuous access evaluation keeps checking after the door closes. Each one covers what the others can't. So passkeys are the foundation, not the finish line. That distinction matters for how you report progress. A team that says we did passkeys and stops has fixed the credential and left the session, the device and the recovery path as they were. The credential was the loudest weakness, so fixing it feels like winning, but a tenant is only as strong as the next weakest layer. And with passkeys in place, you can finally see which layer that is, which gives an executive a short list of questions for this quarter. Ask which of our admin accounts can still sign in without a phishing resistant method? And by when does that number reach zero? Ask how many people hold only one credential. Ask what's our recovery path? Who can issue a temporary access pass and how do they verify the person? First ask which policy gives us the weakest requirement on any app and why does it exist? And ask, are we binding sessions to devices yet, or are we still hoping tokens stay where we put them? Five questions. None needs a technical answer. All of them need a number and a date. An identity team that can answer them cleanly has a program, one that hesitates, has a project that's stopped halfway and that's the picture. So let's close it out. Conclusion. What changes when the prompt disappears? Here's what holds this whole thing together. Passkeys don't work because they add a stronger factor. They work because they take the judgment call away from the person at the keyboard, and the sign in is only as strong as the recovery behind it. Fix the way back in, or you've built a lock with a spare key under the mat. So here's one thing to do this week. Pick the privileged wave. Take every admin account and register two keys for each one. Store the second somewhere different from the first. That's it. That single step closes the most dangerous gap in most tenants. If this episode helped leave a review of the podcast mentioned passkeys and phishing resistant MFA. So the next admin searching for this finds it. And connect with me on LinkedIn. Tell me which topic you want next. Now think about what an attacker sees after all of this. No page to fake, no prompt to wear down, no code to relay. What's left is a phone number and a person who's been trained to say no. The attacker now has to call the help desk. Sponsor segment closing. Stellar Migrator for exchange. One last thing before you go. And it connects back to everything we just covered. Identity state doesn't sit still. It moves with the tenant and it moves with the mailbox. When a company merges, splits or consolidates, the accounts come along. But the registered passkeys. The authentication methods, the temporary access pass history. Those are tied to the old tenant and they don't follow anyone across. So a migration quietly resets your progress. Users land in the new environment with a working mailbox and no strong credential, which means a rollout you spent months finishing has to start again for exactly the people who just went through a disruptive change. That's why reregistration belongs in the migration runbook, not in the cleanup list. Plan it the way you planned. The waves decide who registers first when the temporary access pass gets issued and how the help desk verifies someone before handing it over. Schedule the communication, write the instructions and confirm two credentials per person before the old tenant is switched off. Tools like stellar Migrator for exchange handle the mailbox side of a move the mail, the calendars, the contacts. The identity side is a separate piece of work, and it's worth putting a name next to it before cutover day, not after, that's all. If a migration is anywhere on your calendar this year, add one line to the plan. Registration happens before the first sign in, not after the first complaint. Thanks for listening to the M365 show. If this episode was useful, a review helps more admins find it. I'm Michael Peters and I'll see you in the next one.