M365 FM - Intune Security Baselines - Hardening Endpoints Without Breaking Users 00:00:00 Speaker: Monday. The security team ships a baseline by Wednesday. The help desk phones are lit up by Friday, the policy is rolled back and nobody wants to talk about it. That pattern isn't about bad settings, it's about the rollout model behind them. If you want endpoint security episodes that explain systems instead of listing features, subscribe today. Baselines. ASR. BitLocker. Laps. Compliance. Rings. Exceptions and monitoring. But first, why the old model collapses. Sponsor segment. Stellar. Migrator for exchange. Quick word from today's sponsor. Stellar Migrator for exchange. Here's why it belongs in an endpoint episode. Most hardening projects don't start on a clean tenant. Underneath them, there's usually an identity cleanup or a mailbox move that nobody finished. Stellar Migrator for exchange moves mailboxes between exchange environments on premises to exchange online tenant to tenant or between servers during a consolidation. It handles the mailbox data, the migration batches, and the cutover steps, so you aren't stitching that together by hand. Now why does that matter for Intune? Because baselines and compliance policies. Assume your users, groups, and devices are in a known state. If half the mailboxes sit in an old forest and the user objects don't match what entry ID thinks exists, your rings won't hold. Your groups will lie to you. A clean tenant makes rollout easier. Fewer surprises, fewer devices that belong to nobody. So if a migration is sitting under your endpoint project, look at stellar Migrator for exchange. The link is in the description. All right, back to the endpoint. The old model security as a switch. Most of us learned hardening through group policy. You open the console. You find the setting, you link it to an OU, and on the next refresh, it applies to everyone at once. That habit made sense on premises domain joined machines, a fast network, and a change window on a Saturday night. One big change. One big day. Then we move to the cloud and we brought the habit with us. Here's the assumption. Inside it, a setting is either on or off for everyone. The policy exists so the control exists. The audit checkbox turns green. What typically happens is this. The security team picks a framework sis, a Microsoft baseline. Whatever the auditor asked about, they build the policy, assign it to all devices, and wait for the compliance score to climb. And it does climb. The audit passes, then the users suffer. A finance analyst opens a spreadsheet with a macro she's used for nine years blocked. A technician plugs in a label printer, blocked a sales rep can't connect to a legacy file share because SMB signing is now required and the old NAS doesn't support it. Each one of those is a ticket, and each ticket is a person who just learned something about security. They learned it gets in the way. Now here's what people miss. Intune changes the mechanics. It doesn't change the mindset. In Intune, you can still assign a profile to all devices. You can still push one hundred settings in one go. The portal doesn't stop you. There's no change window built into the product, and no one asks whether the pilot group looked like your real users. So the cloud gives you a faster switch, faster, not smarter. And that's the core problem. I'm going to call it the model. The model is the belief that hardening is an event, something you do, you plan it, you ship it, you tick the box and you move on. But hardening isn't an event. It's a process because the thing you're hardening keeps moving. New hardware arrives. Applications update Microsoft releases a new baseline version. A department buys a tool that behaves like malware and nobody tells you. An event assumes a fixed target, a process assumes drift, and your fleet drifts every single day. Look at what the event model actually measures. It measures delivery. Did the policy reach the device? Did the setting apply? Green means done, but delivery is not the outcome. The outcome is a device that's harder to attack and still lets someone do their job. Those two goals pull against each other and the switch can't balance them because the switch only has two positions. So what happens when the switch hurts? People reach for the only lever they have. They turn it off. That's the rollback by Friday, and once that happens, you've lost more than the policy. You've lost the argument. The next time security asks for a stronger control, the business remembers the last one. But the real cost of this model doesn't show up in the compliance score. It shows up somewhere. You're not measuring where hardening actually breaks. Let's talk about where the damage lands. It doesn't land in the security console. Nothing there turns red. The policy shows succeeded on ten thousand devices and the dashboard looks fine. but breakage isn't really a security failure. It's a trust failure. A user doesn't think about attack surface. They think about whether their work still works. And when a control blocks something they need, they don't conclude this protects me. They conclude this security team doesn't understand my job. That's the moment trust breaks. And once it breaks, people stop cooperating with the system and start working around it. In most organizations, the workarounds look the same. First the personal device, the corporate laptop won't run the tool, so the user opens the same file on a home PC. Now the data you were protecting sits on a machine you can't see, can't encrypt, and can't wipe. Second shadow tools, a free converter, a browser extension, a file sharing site nobody approved. If the sanctioned path is blocked, the unsanctioned one gets used because deadlines don't care about your policy. Third, the request for local admin. Something stopped working. A vendor told them admin rights would fix it, and now the manager is asking for an exception on the user's behalf. Multiply that by a few hundred people and you've rebuilt the exact problem you were trying to remove. Notice what happened there. The control didn't make the environment safer. It moved the risk somewhere with less visibility. And here's the part that surprises security teams. They often find out last who finds out first. The help desk. The help desk becomes the sensor nobody designed. Nobody sat down and said, our early warning system for bad policy will be the person answering the phone. But that's what it is. Every blocked macro, every printer that stopped, every login prompt that appeared out of nowhere, it all arrives as a ticket first and that sensor is noisy. A ticket says XL is broken. It doesn't say ASR rule. Blocked office from creating child processes on three hundred forty devices in the finance ring, someone has to connect those dots. Usually nobody does. The tickets get closed one by one, each one a small fire and the pattern behind them stays invisible. Meanwhile, the help desk learns something too. They learn that security changes mean bad weeks, so they start to resent the next one before it ships. Now look at the pattern that comes out of all this. The stricter the policy, the louder the exception queue. Think about why a strict control with no design behind it hits every user the same way. Most users have a legitimate reason to need something it blocks, so the requests come in one exception, then five, then a group security. exceptions temporary that somebody created in a hurry and nobody ever reviewed that group is the real signal. It tells you the policy was written for an imaginary user. Someone who doesn't use legacy apps, doesn't run scripts, doesn't plug anything in, and never works offline. That user doesn't exist. Your fleet is full of real people. An engineer with a custom built tool, a finance team with a decade of macros. A warehouse with scanners that predate your IT department. A lab that runs software the vendor stopped supporting years ago. And if the model has no room for them, they don't disappear. They show up as exceptions, as workarounds, or as the person on the phone at eight oh five on a Monday morning. So the stricter you go without a way to absorb real work, the weaker you end up. The exception list grows, the trust shrinks, and the actual protection gets quietly negotiated away one ticket at a time. That's how a strong baseline becomes a weak one without anyone ever changing the policy. Which raises a question we've been using as if everyone agrees on the answer. What is the baseline? Really, what a security baseline actually is. A security baseline in Intune is a profile. That's it. A template of settings packaged by Microsoft based on what their security teams recommend for a given product. You pick the baseline, you create a profile from it, you assign it to a group, and the word that matters there is recommended. It isn't a mandate. It isn't a law. It's Microsoft's opinion about a sensible starting point built for a general environment that looks nothing like yours in the details. People forget that they see baseline and hear requirement. Now there isn't one baseline. There are several. Each one covers a different product. The windows baseline covers the operating system itself, password rules, credential protection, network behavior, remote access, a long list of local policies. The Microsoft Defender for endpoint baseline covers the security stack. Antivirus behavior, cloud protection. Azure rule defaults. How scans run the Microsoft Edge baseline covers the browser smartscreen extension, handling, site isolation, that kind of thing, and the Microsoft three hundred sixty five apps. Baseline covers office macro behavior, file validation, protected view. Add in rules for products, for profiles, for separate decisions about who gets what and when. Most teams treat them as one project. They aren't. The edge baseline might sail through a pilot while the office baseline lights up finance on day two, separate profiles let you separate the risk. Here's something that trips people up. Baselines have versions. Microsoft releases a new version when the recommendations change, new settings appear, old ones get removed, defaults move, and your existing profile does not update itself. It stays on the version you created it from so you don't patch a baseline. You compare. Intune lets you pick a newer version, review what changed, and then update the profile on purpose. That's a good design, actually. Nothing shifts under your users without you choosing it, but it also means something quieter. A baseline you deployed two years ago is still enforcing two year old advice. Nobody told you nothing broke. The profile just sits there. Aging, and the gap between it and current guidance keeps growing. That's drift to just the slow kind. Now, what does a baseline assume about your environment? It assumes you're running modern supported software. It assumes your applications behave themselves. It assumes you don't depend on legacy protocols, old authentication methods, or unsigned scripts that run in the background. Some of those assumptions hold plenty. Don't take legacy authentication, for example. The baseline moves away from it because it's weak, reasonable. But if your warehouse still runs a scanner that only speaks an old protocol, the baseline has no idea. It can't see the scanner. It only sees a setting that should be stricter. The baseline knows what's safe. In general, it has no clue what's true in your tenant. That gap is where every breakage story starts. Not because Microsoft got the recommendation wrong, because the recommendation was written for nobody in particular, and you're somebody in particular. So a baseline isn't a finished design. It's raw material. Think about what that means for how you handle it. You wouldn't take a design you didn't write, apply it to ten thousand machines and hope you'd read it first. You'd ask what each part assumes. You'd test it against what you actually run, and the way the baseline is built tells you how to do that. It isn't one switch. It's hundreds of separate settings grouped into categories, each one individually configurable, which means you can look inside it, decide setting by setting, and leave things alone on purpose. That's the part most teams never use. So before we talk about rolling anything out, let's open one up and read it. Reading a baseline before you deploy it. Open the windows baseline in Intune and look at the settings list. It's long hundreds of settings grouped into categories, each with a value Microsoft picked for a reason. Most people scroll through at once and click next. Don't do that. Every setting in that list carries two things a reason it exists and a cost it can create. The reason is usually obvious. Block this week protocol require that stronger check. The cost is the part nobody writes down, and it's the part that decides whether Friday goes well. So read the list as a design document, not a checklist. A checklist asks, is this on a design document? Asks what does this assume and what happens to the people? It doesn't fit. That's a different kind of reading. Slower. You stop on a setting and ask three things what does this block? Who uses what it blocks? And how would I know if I'm wrong? That third question matters most. If you can't say how you detect a problem, you're not ready to enforce the setting. Now you won't have time to question all of them equally. So go where the risk lives. A few categories carry most of the breakage legacy authentication. Older protocols like NM and some basic auth paths get tightened or blocked. Good for security. Painful if an old application or device still depends on them, and those dependencies hide in odd places. A scanner, a reporting tool, a script somebody wrote in twenty fourteen. SMB signing requirements, version restrictions, guest access. This is the one that hits the old file server. Nobody wants to touch the share worked yesterday. Today it prompts for credentials or just fails credential handling settings around cached logons credential storage, and how the system protects secrets in memory. Valuable protections, but they interact with single sign on VPN clients and some third party tools in ways that are hard to predict from the setting name printing restrictions on driver installation, and print behavior, these look harmless until a technician can't add a label printer, or a branch office loses its default printer after a restart. And office macros The Microsoft three hundred sixty five apps baseline is firm here, and it should be. Macros from the internet are a favorite way in for attackers, but a finance team may run a macro that does real work every month, and the baseline can't tell the difference between that file and a malicious one. Five categories. If you only have an afternoon, spend it there. Here's the method. Take each risky setting and match it to something you actually run. Pull a list of line of business apps. Ask the owners of the odd systems, the ones with scanners, labs, and old shares. Then check each setting against that list. Where there's a conflict, you found a decision, not a problem. And you have an option here that most teams ignore. Not configured. Every setting in a baseline lets you leave it alone. Intune won't touch it. It stays at whatever the device already has. People treat that like a failure, like they skipped homework. It isn't. It's a deliberate decision and a good one when you make it for a reason. If you know the old Nass can't handle SMB signing, you leave that setting Unconfigured you write down why and you set a date to fix the nnas. The risk is still there, but now someone owns it instead of everybody discovering it on a Wednesday. Compare that with the alternative. You enforce the setting, the share breaks, and the pressure to roll back. The whole profile arrives. One setting you could have handled in advance ends up killing the entire baseline. So an unconfigured setting with a name, an owner and a date is stronger than an enforced setting that gets reversed in a panic. That's the shift in how you read these things. You're not asking how many settings you can turn on. You're asking which ones you can hold on to once real people push back. And while you're making those calls, there's something else to watch for. The baseline isn't the only thing writing settings to your devices. Other policy types reach the same places, and when they overlap, the results get confusing fast. Policy types and the conflict problem. Here's a question that sounds simple. Where does a windows setting come from on a device managed by Intune? There are at least five answers security baselines. We just covered those. The settings catalog. That's the big searchable list of every configurable windows setting, the one Microsoft keeps pushing people toward. Endpoint security policies. Focused profiles for specific jobs, antivirus. Firewall, disk encryption. Attack. Surface reduction. Account protection. Each one has its own template device configuration profiles. The older templates still they're still used, still writing settings and group policy. If the device is hybrid, joined, or co-managed, and the old domain is still talking. Five sources and none of them knows what the others are doing. That's the conflict problem. Not that any one source is wrong, but that several can set the same value at the same time with different answers. Picture it. The baseline says one thing about a firewall rule an endpoint security policy, says another. A profile somebody built three years ago, says a third. All three are signed to the same group, and the device has to pick one. Intune does show you this. In the device configuration reports, a setting can come back with a status of conflict. That's the portal telling you two policies reach the same setting and disagreed. It's useful, but look at how it gets used. Most teams only open that report after someone complains, and by then the conflict has been running for weeks now. Here's where people get surprised. Precedence. You'd expect a clean rule, newest wins or strictest wins. Or the baseline always wins because it's the baseline. It doesn't work like that. When two Intune policies set the same setting to different values, you often don't get a winner. You get a conflict. The device may apply neither value or hold on to whatever was there before. The result isn't the stricter setting, it's an unpredictable one. Some settings behave differently, a few merge, some take the most restrictive value. It depends on the setting itself, not on the policy type. So you can't memorize one rule and trust it everywhere. And that's the real danger. You think you enforced something? The dashboard shows a baseline assigned, but on the device, the setting is sitting at a value nobody chose. So the baseline you carefully reviewed may not be what the device is running. Then there's group policy, which brings its own twist. If a device gets settings from both a domain GPO and Intune, you have a second layer of precedence. The rule there often favors the domain side depending on how the device is set up, so an Intune setting can quietly lose to an old GPO that nobody remembers writing that's most visible on co-managed devices. These are machines managed by both Configuration Manager and Intune. At once. The thing that decides who's in charge is the workload slider. The slider moves individual workloads from Configuration Manager over to Intune compliance policies, device configuration, endpoint protection. Move the slider and Intune takes ownership of that area. Leave it and Configuration manager keeps it. Sounds clean. But here's the problem. If you build an Intune endpoint protection policy and the slider for that workload still points at Configuration Manager, your policy may show as assigned and do nothing at all. No error, no read, just a profile that's waiting for permission. I've seen teams spend days chasing a setting that was never going to apply because the workload owner was somewhere else. So before you roll out anything, map the sources for each setting you care about. Ask which policy type writes it, which tools could also write it. Who owns the workload? Because a clean baseline on top of a messy overlap isn't a clean baseline, and conflicts at least announce themselves in a report. If you look, the harder cases are the ones where nothing conflicts at all because the real problem is older than Intune Group policy analytics, and the migration trap. Most environments have a second problem sitting under the first one. It's the group policy. You already have fifteen years of it in some places. Settings added for a project that ended in twenty twelve, settings added to fix an incident nobody can describe anymore. Settings added by someone who left with no note about why and when the move to Intune starts. The first instinct is simple take all of it, carry it across. Intune has a tool that makes that feel reasonable. It's called Group Policy Analytics. You export a GPO as an XML file, upload it and Intune reads it. Then it tells you what it found. 00:16:57 Speaker: For each setting, you get a verdict. Does this map to a known MDM policy? Is it supported in the cloud? Is it deprecated? Some settings come back ready to migrate. Some come back with no equivalent at all and some come back flagged as legacy tied to features. Microsoft has been retiring for years. That report is genuinely useful, but look at how it's usually used. Teams read the Ready to Migrate column and treat it as a to do list. Green means move it, move enough green and you're done. That's the migration trap, because this setting can be recreated and Intune tells you nothing about whether it should be. The tool answers a technical question can it map it? Can't answer the design question. Does anyone still need this? And when you copy every mappable setting across, you don't get a modern environment. You get the old one rebuilt in a new console. Same sprawl, same overlaps, same settings. Nobody can explain now with the added fun of conflicts against your baselines, which we just talked about. So flip how you use the report. Don't use it to decide what to migrate. Use it to decide what to delete. Start with the settings that have no equivalent. Those are often relics, a control for a feature that no longer exists. A workaround for a windows version. You retired long ago. If it can't map, ask whether it ever needed to. Then look at the settings the baseline already covers. If Microsoft's recommended profile sets the same value, the GPO copy adds nothing. It only adds a place for the two to disagree. Then look at what's left for each remaining setting. Ask who asked for it and what breaks if it disappears. If nobody can answer, that's not a reason to keep it. That's a reason to test. Removing it in a pilot ring. What you end up with is much smaller, and every setting in it has a reason. You can say out loud. Here's the comparison that matters. Inherited complexity versus intended design. Inherited complexity is what accumulates when nobody removes anything. Every setting made sense. Once together, they make no sense at all. Intended design is the opposite. You start from what you want the device to do, and you add only what supports it. The first one grows by default. The second only exists if you choose it, and the cloud is the first chance in years to make that choice a new platform, a new policy model, a fresh start. Wasting it on a copy paste is like moving to a new house and packing the trash. So run the analytics, read the output, but treat it as an audit of your past, not a blueprint for your future. Because once the policy sprawl is under control, you can finally look at what the policies are meant to defend against. And the first real control to understand isn't a setting at all. It's a way of watching behavior. Attack. Surface reduction. The idea behind the rules. Attack surface reduction rules don't look at files. They look at what a program does. That sounds like a small difference, but it's the whole idea. An ASR rule doesn't ask, is this file known to be bad? It asks, should this program be doing this thing at all? Take word. Word opens documents. That's its job. But should word start a command shell or launch PowerShell or drop an executable into a temp folder and run it? In almost every environment, no. Nobody legitimate needs that. But a malicious macro needs exactly that. So there's a rule for it. Block office applications from creating child processes. It doesn't care which document. It doesn't care who wrote the macro. It blocks the behavior because the behavior is the attack. And here's why that matters more than it first seems. Signature thinking has a built in delay. Someone has to see the malware, analyze it, and write a detection. Until that happens, the file looks clean. Attackers know this. They repack, obfuscate, and tweak a payload until the signature misses, but they can't easily change what the attacker has to do. A macro that wants to run code has to start a process. A credential stealer has to read memory. It shouldn't touch the disguise changes every week. The behavior barely moves, so blocking behavior is more durable. You're not chasing the file. You're closing the door the file needs. Now, there are a lot of rules around a dozen and a half, depending on the version, and a few categories carry most of the weight offers child processes we just covered. It offers apps launching other programs, script obfuscation. This blocks scripts that look deliberately scrambled to hide what they do. Normal admin scripts are readable. Malicious ones often aren't because the author is trying to slip past scanning credential theft from Lsass. Lsass is the windows process that holds logon secrets in memory. Tools that dump it are a classic step in moving through a network. This rule stops other processes from reading it. Executable content from email programs and scripts arriving through a mail client or web mail get blocked from running because the person who clicked didn't mean to install anything. For examples. Each one protects against a technique, not a specific piece of malware. Where does this sit compared to the tools you already have? Think of antivirus first. It's reactive by nature. It matches what it sees against what it knows. Strong against known threats. Weaker against fresh ones. Application control sits at the other end. It decides what's allowed to run at all. Very strong, also very demanding. You need to know every program in your environment and keep that list current. Asser lives between them. It doesn't need a full inventory of your software the way allow listing does, and it doesn't wait for a signature the way antivirus does. It takes a handful of behaviors that almost never have a good reason to happen, and it shuts them off. For a lot of organizations, that's the best return in the whole hardening stack. Low effort compared to application control, real protection against the techniques that actually get used. But notice the phrase I used almost never have a good reason. Almost. That's the gap. Because while a rule blocks behavior that's nearly always bad, your environment has its own exceptions. A finance macro that launches a script, an installer that spawns a helper process. an admin tool that reads memory. It probably shouldn't. The rule can't tell those apart from an attack. It sees the behavior. It doesn't see the intent. And a rule that blocks the wrong thing on day one is a rule that gets switched off by day three. So you can't turn these on blind ASR rollout audit mode first. Every ASR rule has a mode. Four of them are actually not configured. Audit block and warn not configured means the rule does nothing. Block means it stops the behavior. No questions asked. Warn is the middle ground. The user gets a prompt, sees what's being blocked, and can click through and allow it anyway. An audit means the rule runs, watches, and logs every time. It would have blocked something, but it doesn't stop anything. That last one is the mode that matters because audit mode answers the question. The baseline can't. What does this rule hit in my environment? You don't guess. You don't ask the finance team to remember every macro they've ever written. You turn the rule on an audit, you wait and the devices tell you every hit gets recorded with the rule, the process, the file path, and the device. That's your evidence collected from real work with nobody locked out while you gather it. So the first move for every rule is the same audit, not block with a plan to loosen it later ordered with a plan to tighten it though sounds similar, but they end up in very different places. Starting in block mode means your first data arrives as tickets. Starting an audit means it arrives as a report. Now where do you read that report in Microsoft Defender for endpoint, there's a reporting view for attack surface reduction. It shows rule detections across your devices split by rule, by audit versus block and by device. Advance hunting gives you the raw events. If you want to query them yourself, look at it by rule first, not by device. You're asking which rules are noisy. A rule with a handful of hits is probably clean, a rule with thousands of hits from one process. That's a conversation waiting to happen. Then drill in which program triggered it? Which path? How many devices? One machine hitting a rule five hundred times usually means one odd tool five hundred machines hitting at once. Each usually means something your whole department runs, and that difference tells you what to do next. Give it enough time to. A week of data is rarely enough. A month and macro won't fire until month end. A quarterly script won't fire until the quarter closes. If your audit window skips those, your data has a hole exactly where the risk is. So what shows up? Most environments see the same three patterns line of business macros, a spreadsheet or document that launches something it shouldn't as part of a process. The business depends on. These usually light up the office child process rule admin scripts obfuscated or encoded PowerShell that your own team wrote years ago. It looks suspicious because it's ugly, not because it's malicious. The script obfuscation rule catches these and install a behavior software deployment tools, Updaters and setup programs often do things that look exactly like an attack. They drop files, spawn processes, and run from odd locations. Your management tooling itself can show up in the report. Notice what these have in common. Each one is a real legitimate hit. The rule worked. It just worked on something you need. So now you have data and you need a decision. And the decision is per rule, not for the whole set. For each rule, you land in one of three places block. Now the audit shows almost nothing or only hits you can trace to something harmless. Move it to block. This is usually most of the rules and it's the easy win audit longer. The hits are real, but you don't understand them yet. Keep watching. Find the owner of the process. ask what it does and decide with more information or exclude. The behavior is legitimate. You've confirmed who owns it and the business needs it. You keep the rule in block mode for everyone else and carve out a narrow exception for that one thing. Each rule gets one of those answers and each answer gets written down. Rule, decision. Reason owner. That table becomes your rollout plan rules. In the first group, go to the pilot ring in block mode rules in the second, stay in audit rules in the third, move forward with their exclusions attached. And if you want a softer landing for a rule that's close to ready, warn mode helps users see the block understand it and can override it. It's a way to learn how real people react before you remove the choice. But notice where that third group leads. An exclusion feels like a small thing. One line, one path, one problem solved. It's also the place where your protection starts to leak ASR exclusions without guilt or gaps. An exclusion isn't a failure. Some behavior in your environment is legitimate. The rule can't know that, so you tell it. The question is how you tell it, because that's where the gaps get made. Start with scope. Make it as small as the problem allows. ASR gives you a few ways to carve out an exception. You can exclude a file path, you can exclude a process, and in some setups you can attach the exclusion to one rule only instead of every rule at once. That last option is the one to reach for first. If the finance macro trips the office child process rule, exclude it from that rule, don't exclude it from lsass protection or from the email rule, or from anything else that has nothing to do with it. One rule, one path. One reason a broad exclusion. Hands every rule. A blind spot, a narrow one costs you almost nothing. And be careful with folders. Excluding a single file is tight. Excluding a whole directory means anything that lands in that directory gets a pass, including something an attacker drops there on purpose. So the more specific the path, the better. A named executable in a fixed location beats a wild card every time. Now the path most teams skip writing it down. Every exclusion needs three things attached an owner, a reason, a review date. The owner is a person, not a team. Somebody who can say, yes, we still need this. The reason is a sentence a stranger could understand a year from now, and the review date is the one that actually protects you because exclusions don't expire on their own. Think about what happens without that. An engineer adds a path during a bad week to get a deployment working. It works. Everyone moves on. Two years later, the engineer has left, the application is gone, and the exclusion is still there, quietly letting something through. Nobody knows what it was for. Nobody dares remove it. That's how a small decision turns into a permanent whole with a review date. The conversation changes every few months. Somebody looks at the list and asks one question per line is this still true? If the owner confirms it, the date moves forward. If nobody answers, you test removing it in the pilot ring. Silence isn't approval. Now the danger I'd rank above all the others. The global exclusion List defender lets you set exclusions that apply across the whole ASR configuration one list covering everything. It's convenient. It's also exactly the shortcut people take under pressure because it makes the ticket go away in a minute. But a global entry doesn't say allow this. For the macro rule, it says ignore this path. For every rule I have a single careless line. There can undo the rules you spent weeks tuning, and it won't show up as an error anywhere. The dashboard stays green. The protection just has a door in it. So treat the global list the way you treat a domain admin account. Keep it short, keep it justified, and make anyone who wants to add to it explain why a per rule exclusion won't work. There's one more question worth asking before you exclude anything at all. Can you fix the application instead? Sometimes the answer is yes, and it's cheaper than it looks. A macro that launches a script can often be rewritten to do the work. Inside Excel. An admin script full of encoded commands can be saved in plain readable form. An installer can run from a signed managed location instead of a temp folder. Each of those removes the conflict at the source. No exception. No review date. No leak. Sometimes the answer is no. The vendor is gone. The code is frozen. The business can't wait. Then you exclude it narrowly with an owner and a date and you move on without guilt. The goal was never an empty exclusion list. It's a list where every line is deliberate that covers ASR, which defends a running machine against attack. But a machine can also simply walk out the door. And for that, none of these rules help at all. BitLocker what it protects and what it doesn't. BitLocker has one job. It makes the data on the disk unreadable to anyone who doesn't have the key. That's a narrow promise, and it helps to be exact about which threat it answers. Because people hear encryption and assume it covers everything. The threat is a device that's no longer in your hands. A laptop left in a taxi, a bag taken from a car. A machine pulled from a drawer after someone leaves. In each case, the attacker has the hardware, and the hardware has a disk. Without encryption, they can pull that disk, plug it into another computer, and read every file. No password needed. Windows login never even enters the picture. BitLocker closes that door, the disk contents are scrambled and the key stays locked up until the machine proves it's in a trusted state that's offline access. It's the whole scope. What it doesn't do matters just as much. Once a user signs in and the drive unlocks, BitLocker steps back. Malware running in that session reads the files like normal. A Phished user who hands over their credentials still loses their data. A stolen laptop that's powered on and unlocked gives the thief everything, so BitLocker protects against loss. It doesn't protect against attack. That's why it sits next to ASR in a hardening plan, not in place of it. Now, how does it get turned on without bothering anyone. On devices joined to enter ID Intune can encrypt the drive. Silently the user sees nothing. No wizard, no prompt, no choice. The policy lands windows, starts encrypting in the background and the key gets backed up on its own. That sounds simple, and it is. As long as the prerequisites hold. The device needs a TPM. That's the chip that stores the key material and checks the boot state it needs uEFI firmware with secure boot enabled, and the Windows Edition and version have to support the Silent path. Miss any one of those and the policy doesn't fail loudly, it just can't complete the device shows pending or it prompts the user, which defeats the point of going silent. So hardware readiness decides the outcome long before the policy does. Think about what that means. In a real fleet, you rarely have one kind of machine. You have the new laptops, which are fine. Then the older ones from the last refresh cycle where secure boot might be off, or the TPM sits at an old version, then a few odd models nobody remembers buying. Before you assign anything, inventory that TPM and secure boot on firmware in uEFI mode, not legacy Bios. That list tells you which devices will encrypt quietly and which ones will need a person next decision. The encryption method. The standard choice today is z s a s two hundred fifty six. It's the stronger option, and it's what most modern guidance points to. For fixed drives. The trade off is small but real. Stronger encryption costs a little more processing on every read and write on current hardware. You won't notice on older machines with slower storage, a user might. There's also a compatibility point. The cipher gets set when encryption starts. If a device already encrypted itself with a weaker method, changing the policy later doesn't re-encrypt it. You'd have to decrypt and start over, so settle the method before the first device encrypts, not after, and pay attention to one more thing. A policy that sets the method only works cleanly on a device that hasn't been encrypted yet. If users already turned on BitLocker themselves or an old image. Did you have a mixed fleet? Some drives on one cipher, some on another, all showing encrypted in a report that doesn't tell you the difference. That's a quiet gap. The checkbox says yes, the strength says maybe. Still, getting a drive encrypted is the easy part. Windows does the work. Intune just asks. The hard part is the day something goes wrong and the user is staring at a blue screen asking for a forty eight digit number. That's the part you actually have to design. BitLocker Recovery designing for the bad day. A recovery key is a forty eight digit number. That's all it is forty eight digits that unlock a drive when the normal path fails, and the whole question of recovery comes down to where that number lives and who can reach it. When silent encryption runs, Intune tells the device to back up the key to entry ID. This happens during encryption before the drive is considered protected. Each key gets stored against the device object along with the key ID. That ID is the short string the user sees on the blue screen. It's how you find the right key, because a single device can hold several over its life, so the escrow isn't an afterthought. It's part of the policy and you want to confirm it actually worked because an encrypted drive with no escrowed key is the worst possible state. The data is locked and the only way back is gone. Check that before you scale. Pick a pilot device, look up its recovery key in the portal and make sure it's there. Do it for every hardware model in the ring. One missing key found in week two is a quiet fix, one found during an incident is a data loss. Now who can read these keys by default? More people than you'd like. Global administrators can. Some built in roles can, and any user can view the keys for their own devices. Unless you turn that off. That last setting deserves a decision. Letting users see their own key is convenient. It saves a call, but a key shown on a screen is a key that can be photographed, forwarded, or read out to someone pretending to be it. Many organizations switch it off for exactly that reason. For everyone else, use role based access. Intune and entra have roles that grant permission to read BitLocker Keys specifically without handing out broader admin rights. Give it to the Help Desk group that actually performs recovery and nobody else. Fewer people, smaller risk and every read leaves a trail when someone views a recovery key, entry logs it in the audit log, who looked, which device and when. That log is your answer to a hard question. Later a key gets used, a laptop gets accessed, and somebody asks who released the secret? You can say, but only if someone reads the log. A trail nobody checks is just storage. Which brings us to the workflow because the technology is the easy half. 00:33:59 Speaker: Picture the call. A user is locked out in a hurry and says they're the person who owns the machine. The help desk can see the key. The user wants it now. What stops a social engineer from making that exact call? Only the process. So write one. Verify the identity before the key is released using something an attacker couldn't guess. A callback to a known number. Approval from the manager or a check against something in the directory. Pick a method and use it every time, even for the executive who's annoyed. Then release the key and make a note in the ticket. And here's a detail that gets missed after a key has been used. Treat it as exposed. The device should rotate to a fresh one. Intune can do this automatically when the key was used for recovery, and you should turn it on. Otherwise, the old number stays valid and it's been read aloud over a phone. Now, why does recovery happen at all? Most of the time it isn't theft, it's a change. The TPM noticed BitLocker binds the key to the state of the machine firmware, boot files, hardware configuration. If any of those change in a way the TPM doesn't expect, it refuses to release the key and the user lands on the recovery screen, so recovery events spike after specific things. A Bios or firmware update, a firmware push, a hardware swap like a motherboard or a new disk controller. Sometimes a change to boot settings or secure boot state. Each of those is routine. Each one is also a ring wide event. If you deploy it to a whole fleet at once. That's the pattern worth planning around. Firmware updates and BitLocker policy shouldn't land in the same week on the same ring. If recovery calls jump, you want to know which change caused it. Stack them and you'll never untangle the answer. You can also reduce the risk directly. Some firmware tools can suspend BitLocker protection for a single reboot, so the update applies without tripping recovery. It takes some setup, but it turns a predictable ticket storm into a non-event. And the same logic applies to how the machine starts up in the first place. How much the user has to do at boot decides how often they ever meet that blue screen. BitLocker Pre-boot pins and the user experience tags. There are two ways a BitLocker machine can start up TPM only, or TPM plus a PIN with TPM only. The chip checks the boot state, and if everything looks right, it releases the key on its own. The user powers on sees the windows sign in screen and never knows encryption was involved. Fast. Invisible. That's why it's the default for most fleets. With a PIN, the user has to type something before windows even loads a short code set by the user or by policy. No pin, no key. So what does that extra step actually buy you? It closes a specific gap. A TPM only machine will hand over its key to anyone who powers it on. As long as the hardware looks untouched, that means an attacker holding a stolen laptop can start it up, and some physical attacks, like sniffing the traffic between the chip and the processor, become possible. A pin breaks that the key stays sealed until a human who knows the secret shows up. That's a real gain. It's also a real cost, and the cost lands on every user every morning. Think about what a second code means in daily work. Another thing to remember. Another thing to forget. Another reason to call the help desk after a holiday and a pin prompt before sign in means no remote restarts. A machine that reboots overnight for updates now sits at a pre-boot screen until someone walks up and types your patching window. Just got a dependency on people so you don't apply it to everyone. You apply it where the risk justifies the friction. Two groups come to mind. First, high risk roles like executives, finance leaders, and anyone holding data that would hurt if it left the building and roaming devices, the laptops that live in bags, on trains and in hotel rooms where theft is a realistic event and not a thought experiment. An office desktop bolted to a desk doesn't need the same treatment. The threat model is different, so the control should be two. Now the awkward cases, shared devices and kiosks. A shared workstation has no single owner to remember. A pin a kiosk may need to restart and recover with nobody present at all. Pre-boot authentication on those machines creates a lockout nobody can clear for these, TPM only is usually the honest choice, paired with physical controls and tight sign in rules, pushing a pin policy onto them doesn't make them safer, it makes them stop working. One more thing worth checking is the pin length. Short and numeric is easy to remember and easy to guess. Longer enhanced pins allow letters and symbols, but users type them on a bare pre-boot screen, sometimes with a layout that differs from windows tested with real users. First, a strong pin that people can't enter is just a different kind of outage. Then there's removable media, USB sticks and external drives walk out of buildings all the time, and they're often the weakest link in the data story. BitLocker to go can require encryption before a user writes to a removable drive. Done well, that's protection that travels with the data, but enforce it bluntly. And you block people who plug in a drive to move a presentation they can't save. They can't copy. Suddenly, the policy is the reason a sales meeting starts late. A softer path helps allow reads on unencrypted drives, require encryption only for writes, and give users a clear prompt that explains what's happening. That way, the control targets what leaves your control without stopping the work? That was never the problem. Every one of these choices follows the same logic. Pick the strongest protection the user will actually put up with, because a control they root around protects nothing. And that brings us to the account that every one of these machines carries, whether you think about it or not. The local admin problem nobody wants to fix. Every windows machine ships with a built in administrator account. It's been there since day one. Full control over the device and in way too many environments. That account has the same password on every single machine. Not similar. Identical. It usually starts with a good reason someone builds an image and that image needs a local admin so the technician can get in. They set a password. The image gets deployed to two hundred laptops, then two thousand. Nobody changes it because changing it means touching every device. And that's a project nobody has time for. So the password sits there for years, known by more people than anyone can count. The help desk knows it. The deployment team knows it. A contractor who left in twenty nineteen knows it. It's probably in a shared spreadsheet or a wiki page, or a note somebody pasted into a ticket. Now think about what that gives an attacker. They don't need to break into your whole network. Just one machine, a single phished user, a single unpatched laptop. Once they have admin on that box, they pull the local account's credentials out of it. And because every other machine uses the same secret, they now have admin on all of them. That's lateral movement. An identical local credentials are the best fuel it can ask for. One foothold turns into the entire fleet with no further effort, because you handed over the key to every door at once. It's a quiet kind of risk. Nothing about it shows up in a dashboard. The machines are encrypted, patched and compliant, and every one of them shares a secret that lets an intruder walk across the whole estate. So why does it survive? Why hasn't everyone fixed it? Because the shared password isn't really the problem. It's the symptom of a different one. Users have local admin rights because they need them. Be honest about that. They install software the company doesn't package. They update drivers for a dock or a printer. They run a VPN client that wants elevated access every time it connects. A developer needs to run a tool that writes to a protected folder. A salesperson needs to install a plugin before a demo in ten minutes. Take away admin rights without solving those and you haven't improved security. You've created a queue at the help desk and a line of angry people. And what do people do then? They find another way. They ask a colleague with admin to log in for them. They use a personal device, they hunt for a portable version of the tool, or they push until a manager signs an exception, and the exception turns into a standing admin, right for the whole team. So the fix has two halves and teams usually only attempt one. The first half is removing admin rights from daily accounts. Users sign in as standard users. That alone shuts down a huge class of attacks because malware that runs as a standard user can't touch the system the way it could with admin behind it. The second half is making sure the work still gets done. That means packaging the apps people really need and deploying them through Intune, so nobody has to install them by hand. It means pushing driver updates through managed channels. It means giving the VPN client a deployment that doesn't depend on a user's rights. Do the second half first, then the first half stops being a fight, but there's still a leftover. Even in a clean environment, somebody occasionally needs a local admin, a technician fixing a machine that won't sign in a repair that can't happen remotely. The built in account has to exist for those moments so the account stays. What has to change is the secret. Instead of one password shared across the fleet, every device needs its own unique, long, random, and changed on the schedule so that a password stolen today stops working next month. That's a hard thing to do by hand. Nobody can generate, store, and rotate a unique password on every machine every thirty days with a spreadsheet, but windows can do it for you. Windows labs How it works the tool is called Windows Labs local administrator password solution. And the idea is simple every device gets its own local admin password, unique, random, and rotated on a schedule the device generates it, stores it somewhere safe, and changes it again when the time comes. Nobody types it. Nobody remembers it. Nobody pastes it into a ticket that removes the shared secret completely. A password stolen from one machine opens that machine and nothing else. And when the rotation runs, even that password stops working. Now, where does the password go after the device creates it? There are two places entry ID or on premises active directory for devices joined to entry ID. The backup goes to enter. The password is stored against the device object and you read it through the portal or the graph API. No domain controller involved. For devices that are domain joined or hybrid joined, you can send it to Active Directory. Instead. It lands in an attribute on the computer object and the schema needs to be extended first. That's a one time step, but it's a step. The difference matters for who can reach the password and how entry users enter roles and the audit log you already know. Active directory uses permissions on the computer object and its own auditing. Pick the one that matches where your devices actually live and pick one. A device backs up to a single directory at a time. Next, the policy itself. In Intune, you configure it with an account protection policy or through the settings catalog and a handful of settings do most of the work. Account name by default, lapse manages the built in administrator, but you can point it at a custom account instead, which is a good idea. The built in one has a well-known name that attackers go looking for. A renamed account is a small hurdle, but a free one. Password age how many days before the password rotates? Thirty is a common choice. Shorter means a stolen password dies faster. Longer means fewer changes to track. Most teams land somewhere between fifteen and thirty. Complexity and length. You choose the character types and how long the password runs go. Long machines don't mind fourteen random characters, and nobody's typing it from memory anyway. And post authentication actions. This one decides what happens after somebody actually uses the password. You can have labs reset it and optionally sign out the account or reboot the device. After a set delay, we'll come back to why that matters. One more thing the policy has to land before the device can do anything until it applies, the machine keeps whatever password it had. So a device that's late to check in is a device still running the old shared secret? Now, a question that comes up in almost every environment. What about the older tool? Before Windows Labs, there was a separate download now called Legacy Microsoft Labs. It worked with Active Directory, used its own attributes, and needed an agent installed on every machine. Plenty of organizations still run it. Windows labs is built into the operating system. No agent supported on windows ten and eleven builds and on recent Windows Server versions. It uses new attributes, and it adds the extra backup that the old one never had. So migrating isn't a flip of a switch. The two tools use different storage, and they can collide on the same device. If both are active and pointed at the same account, they'll fight over the password. The clean path is staged. Check that the devices are on a supported build. Disable or remove the legacy policy for a pilot group. Apply the Windows Labs policy to those same devices, then confirm the new password shows up in the directory before you widen the ring. There's also an emulation mode that lets Windows Labs read the old policy settings during the move, but treat that as a bridge, not a destination. The settings are the easy part. Five or six choices in a policy. What takes real thought is everything around them. Who's allowed to read the password, how you know when they did, and what happens when the device isn't reachable at all. Laps in practice. Who gets the password and when? Here's the blunt truth once laps is running, your local admin passwords live in your directory, and anyone who can read them can become admin on those machines. So the real security question shifts. It's not about the password anymore. It's about who's allowed to ask for it in entry ID. Reading elapsed password requires a specific permission. A few built in roles carry it. Cloud device administrator. Intune administrator. Global administrator. Look at that list. Some of those roles are way broader than anyone needs for a single job, so build a custom role instead. Entry lets you create one that holds only the permission to read local admin credentials and nothing else. Assign it to the group that handles hands on repairs. Maybe that's tier two support. Maybe it's the desktop engineering team. It's almost never the whole helpdesk and scope it if you can. Administrative units let you limit a role to a slice of devices. A regional team reads passwords for its own regions machines, not the whole tenant. Every read gets logged when someone pulls a password. Entra writes an audit entry who, which device, and when. That's the second half of control permission decides who could. The log tells you who did. Here's where teams slip. They turn laps on, confirm passwords are being stored, and never open the log again. Then months later, somebody asks why a device was accessed at two in the morning and nobody knows where to look. Set up an alert on it, a password read outside business hours or a burst of reads from one account should reach a person. It doesn't take much, it just takes someone deciding it matters. Now the setting. I said we'd come back to post authentication actions. Think about what happens when a technician uses a password. They read it, they sign in, they fix the machine, and now that password has been displayed on a screen, typed by a person and possibly spoken across a desk. It's exposed. If it stays valid for another twenty days, you've recreated a small version of the shared secret problem so a lapse can act after the use. You set a grace period, say eight hours. And when it expires, the device resets the password on its own. You can also have it sign out the managed account or reboot the machine so no session survives. Holding the old credential that turns every user into a one time event. The password worked once for one job and then it stopped being useful. Pick the action to fit the fleet. A reset alone is gentle and safe almost everywhere. A forced reboot is stronger, but think about the user whose laptop restarts Mid-meeting because the technician finished early. For shared or unattended machines, it's often fine for someone's primary device. Probably not. Then the cases that don't fit the happy path. First, the offline device labs stores the password in the directory, but the device has to reach the directory to rotate it. A laptop that's been in a drawer for three months holds a password that's three months stale. When it finally comes online, it rotates. Until then, the last known password is the one on record, so check the timestamp on any retrieval and don't assume a fresh value. Second, the device that can't sign in at all. Maybe the network profile is broken or the machine lost its join to the directory. The stored password still works locally. That's the entire point of having it. But if the device never managed to back it up, there's nothing to retrieve. That's the break glass problem. Test it before you need it. Pick a machine, pull the password, and sign in as the managed account. If it fails in a quiet moment, you've learned something cheap. Everything so far has been about configuring devices. Settings go down, passwords come up, but configuration is only half the story. The other half is deciding which devices you're willing to trust at all. Compliance policies defining a healthy device. A configuration policy pushes settings down to a device. A compliance policy does something different. It asks the device a question, and then it records. The answer. Is this machine in a state we're willing to trust. That's all compliance is. It doesn't change anything on the device. It reads. The state compares it to rules you wrote and returns a verdict compliant or not compliant. Two outcomes, and one of them has consequences. And that distinction trips up a lot of teams. They assume that turning on a compliance policy makes devices more secure. It doesn't. A compliance policy can't encrypt a drive. It can't enable secure boot. It can only tell you whether somebody else already did. So what do you put in the question? The common signals are the ones we've already built toward is BitLocker enabled on the system? Drive is secure. Boot on. Is the operating system at or above a minimum version? Is defender running with real time protection on and signatures current. And if you've connected defender for endpoint, what's the device's risk level? That last one is useful because it brings live threat data into the verdict. A machine that's encrypted and patched but showing signs of an active compromise can still come back as not trusted. Notice what each of those has in common. There are facts about state, not about intent. The device either has the property right now or it doesn't. Now here's where the model matters. The verdict doesn't sit in a report that nobody reads. It travels. Intune handles the compliance result to entry ID and conditional access reads it. That's where the consequences live. A rule somewhere says to open exchange online, the device must be compliant. So when the verdict flips to noncompliant, the user doesn't get a warning banner. They get blocked at sign in. That's powerful. It's also why the policy deserves care. You're not writing a checklist. You're writing the condition under which a person can or can't do their job. So what should it contain? There's a design trap here, and it's worth naming many teams, right? The compliance policy by copying the baseline, every setting the baseline enforces gets mirrored as a compliance check. It feels thorough. It's actually redundant, and it creates a second place for the two to drift apart. Think about the roles the baseline configures compliance. Verifies if the baseline turns on BitLocker compliance should confirm BitLocker is on. It shouldn't also recheck forty other things the baseline already controls and can fix by itself, so keep it small. Ask only about the properties that if they failed, you genuinely want to cut that device off. Encryption secure boot a minimum OS version that matches your patching policy. Defender healthy risk level acceptable. A handful of checks, each one tied to a reason you could explain to the person it just blocked. Then ask a second question about each one. Can the user fix this themselves if the device fails because the OS is two months out of date, the user can run an update if it fails because the TPM is missing, no amount of effort helps. The first kind of failure belongs in a compliance rule. The second belongs in your hardware plan because a rule nobody can satisfy just creates a permanent lockout with a polite label on it. 00:50:56 Speaker: There's one more behavior to understand because it surprises people. Compliance isn't continuous in the way they imagine devices evaluate on a schedule, and a check in a device that change state an hour ago may still carry the old verdict, and a device that never checked in at all has no verdict, which Intune can treat as compliant or not, depending on a tenant setting you choose. So the verdict has timing gaps and a default. Each one affects who gets locked out and when. Which raises a harder problem a device can flip from healthy to not healthy at any moment for reasons the user never saw. If that verdict lands instantly with no warning and no time to react, you haven't built a security control. You've built a way to lock out your own workforce on a Friday evening. Compliance actions and the grace period. Design. Every compliance policy has a section. Most people skim past actions for non-compliance. It's a small table inside the policy, a list of things Intune does when a device fails and when it does them. And by default, it holds exactly one entry. Mark the device non-compliant immediately. Zero hours. Zero hours is the Friday lockout. A device fails a check at four forty in the afternoon. The verdict flips conditional access, sees it, and the user is out of outlook before they finish reading the message. That explains nothing. So the first design move is to change that default. You can add a delay to the mark as non-compliant action a day, three days a week. During that window, the device is still treated as compliant. Nothing breaks, but Intune knows the clock is running and it can do other things while it ticks. That window is the grace period, and it works as a safety valve for your whole rollout. Think about what it absorbs. A new compliance rule lands in a ring and some devices fail it for reasons you didn't predict. An older model reports secure boot off a laptop that hasn't been updated since the holidays. Misses the minimum OS version without a grace period, every one of those becomes an outage. With one, they become a list. You see who's failing, you fix the pattern and most users never find out it happened. Now what goes in the window? Notifications. Intune can send an email to the user and it can push a message to the company portal. You can schedule several one at the start of non-compliance, one halfway through one the day before the block. Each is a chance for the person to fix the problem before it costs them access. But the message itself is where most teams fail. The default template says something like your device doesn't meet company requirements. That tells the user nothing. They don't know which requirement, they don't know what to do, so they ignore it. Or they call the help desk. And the help desk doesn't know either. Write it like a person. Name the problem. Your laptop needs a windows update. Say what to do. Open settings. Choose Windows Update, install, restart, give a deadline in plain days, and give a contact for when the fix doesn't work. Four sentences and no jargon about posture or policy. You can customize the text and you can add your own branding and the support link. That's twenty minutes of work that prevents hundreds of calls. Then there's the third action the heavy one. Retire the non-compliant device or remove it from management. Use it sparingly. It exists for devices that have been non-compliant for a long time and likely belong to nobody. A laptop in a drawer. A machine from someone who left a retire action at thirty or sixty days helps clean the inventory pointed at active users by mistake. It wipes company data from a working device. so set the timing deliberately. A reasonable shape looks like this. Day zero. The device fails and the user gets a notification. Day three a reminder. Day five. A warning that access ends tomorrow. Day six Mark noncompliant and weeks later, if the device still hasn't come back, a different process picks it up. Each step gives the person a reason to act and a path to do it. One more point and it concerns timing of a different kind. Avoid letting blocks land at the end of the week. The grace period counts days from when the device first fails. So a failure on Tuesday with a five day window lands the block on Sunday and Sunday becomes Monday morning. That isn't a disaster, but it's a pattern worth watching if you can shorten or lengthen the window so enforcement hits early in the week when the help desk is fully staffed and people can still reach someone. None of this weakens the control. The device that stays broken still gets blocked. The only thing you've removed is the surprise. But a compliance verdict only has teeth because of what reads it, and the thing that reads it can shut off every cloud app you own all at once. Conditional access coupling. The blast radius conditional access is where a compliance verdict turns into a decision. One policy, one ground control require device to be marked as compliant. And that single checkbox does something that's easy to underestimate. It doesn't apply to one app. It applies to every app the policy covers. At the same moment. Exchange SharePoint teams, the whole set of cloud apps you pointed it at. So think about the size of that. A device flips to not compliant, and the user loses mail files and chat in one move. There's no partial failure. Everything they open from that device asks the same question and gets the same answer. That's the blast radius. And it's why this is the step where hardening stops being an IT concern and becomes a work concern. Now, the safest feature in the whole flow is also the most skipped report only mode. Conditional access lets you create a policy that evaluates every sign in records, what it would have done, and blocks nothing. You switch it on, wait, and then read the results in the sign in logs. Each entry shows whether the policy would have passed or failed that user on that device for that app. That's audit mode. The same idea we used for ASR evidence first, enforcement later. And what does it tell you? Mostly it finds the people you forgot the shared conference room device. The contractor on an unmanaged laptop, the mobile app that signs in from a phone you never enrolled. Each one shows up as a would have failed, and each one is a conversation you get to have before it's a ticket. Run it long enough to cover a full work cycle. A week is thin. Two or three gives you the people who travel, the ones on leave, and the ones who only sign in at month end. Then there's the list of things that must never be caught by this policy. Break glass accounts come first. These are the emergency admin accounts you keep for the day. Something goes wrong with condition access itself. If a bad policy locks everyone out, including the admins who could fix it. You've built a trap with no exit, so exclude two emergency accounts from the policy. Protect them with strong separate controls and alert on any sign in they make. Service identities are the second group automation accounts, service principals, and anything that signs in without a person at a keyboard. A compliance requirement means nothing to a script. It has no device to check, so it simply fails and whatever process depended on it quietly stops. Scope the policy to users and handle workload identities with their own rules. And one more category guests. External users bring their own devices, and your compliance policy knows nothing about them. Decide on purpose whether the policy covers them, because the default answer is rarely the one you wanted. Next. The timing problem, which catches almost everyone. A device that has never checked in has no compliance verdict at all. Brand new laptop just enrolled. Still pulling down its first policies. Intune can't say it's compliant because it hasn't had time to look. There's a tenant setting for this. It decides how devices with no assigned policy get treated compliant by default or not compliant. The secure choice is not compliant, but it means a freshly enrolled device is blocked until its first evaluation finishes. And during provisioning, that's exactly when a user is trying to sign in for the first time. So plan for it. Let the enrollment process complete before the user's first real session. Use the enrollment status page or the autopilot flow to hold the device at setup until policies land. Otherwise, your newest employees meet your hardening on day one as a block screen. The same gap affects devices that went quiet. A laptop that's been closed for three weeks holds an old verdict, and it won't refresh until it connects. Every one of these cases comes back to one question who gets this policy and in what order? Because the strictest control in the tenant shouldn't reach everyone on the same day. Rings staged rollout as the core control. Here's the shift. Everything so far has been a setting, a rule, a policy. But the control that decides whether any of them survives contact with real users isn't a setting at all. It's the order you ship them in. A ring model is the simplest version of that. You split your fleet into groups, and you send each change through the groups one at a time. Small first, bigger after the most sensitive last four rings cover most environments a pilot, a group of early adopters, a broad population, and then the critical devices. That last one is the ring. People forget to name executives, laptops, the machines that run production lines, the devices where an outage costs money by the minute they go at the end. Not because they matter less, but because by then you've already found the surprises somewhere cheaper. Each ring is a safety margin. The pilot catches the obvious failures, the ones that would have hit everyone. The early adopters catch the odd ones. The app only one department uses, and by the time you reach the broad ring, the policy has already run on real machines with real people for weeks now. How do you build them in into an. A ring is just a group. You assign a policy to enter security groups, do the job and you can fill them two ways. Static groups where you add members by hand or dynamic groups where a rule fills them for you based on device properties like model department or operating system. Version. Dynamic groups save effort, but they have a catch membership updates on a delay, sometimes minutes, sometimes longer, and a device that's moved to a different ring keeps getting the old ones policies until the evaluation catches up. For a pilot that needs to stay exactly the same size, a static group is the calmer choice. Then there's assignment filters. A filter narrows an assignment further without creating a new group. Say you want a policy to reach every windows eleven laptop in the early adopter group and skip virtual machines. One group, one filter. Done. It keeps your group list short, which matters more than it sounds. A tenant with sixty overlapping groups is a tenant where nobody can say who gets what. So who goes in the pilot? It obviously they understand the tools, they forgive rough edges, and they'll read an error message instead of calling someone. But a pilot made only of it isn't a test, it's a rehearsal in friendly conditions at power users. The people who push their machines hard and notice when something shifts. And a few skeptics, the ones who didn't want the policy and will complain loudly the moment it misbehaves. That's not a flaw. A skeptic with a real problem tells you faster than a supporter who assumes it's their fault will go deeper on choosing those people in a moment. First, the question that decides whether the rings mean anything. How long does a ring last? Most teams answer with a date pilot for two weeks, early adopters for two more then everyone. It feels organized. It's actually a guest dressed up as a plan because time passing doesn't prove anything. Two quiet weeks might mean the policy works, or it might mean nobody opened the one app that breaks. So replace the calendar with exit criteria conditions the ring has to meet before the next one opens. Policy delivery above ninety five percent with no unexplained errors or conflicts. Ticket volume from that ring at or below its normal baseline. Every ASR audit hit reviewed and decided no open BitLocker recovery spikes a named person who signed off if the criteria are met on day four. Move on if they aren't met on day twenty, stay. The ring ends when the evidence says so, not when the calendar does. That also changes the conversation with leadership. Nobody has to defend a delay. As a feeling. You point to the number that hasn't cleared and the discussion is about the number. But there's a dependency hiding in all of this. Exit criteria only work if you can actually see the results. A ring you can't observe isn't a safety margin, it's just a smaller group that fails in the dark. Choosing pilot users who will tell you the truth, a pilot has one job. It has to look like your fleet. That sounds obvious, but most pilots are built from whoever said yes, and the people who say yes are rarely typical. They're the curious ones. The ones with newer hardware, the ones who already know where the settings live. So start with representativeness, pull a device inventory and look at what you actually own. Hardware models, firmware versions, which line of business apps run, where, which sites have the strange network setup, and which roles use the one tool that still needs a macro, then build the pilot to cover that. Spread one or two devices from each major model, one user from each department that runs something unusual, a person from the remote office with the slow connection and one who travels. Why does this matter so much? Because breakage hides in the corners. BitLocker recovery spikes on one laptop model after a firmware update, an ASR rule blocks a finance spreadsheet that nobody in it has ever opened. A compliance check fails on a TPM that's two generations old. None of that shows up. If every pilot device is a fresh machine in a technical team, an all out pilot is the clearest example. It passes every time because IT admins have local tools, patience and workarounds for everything, and they fix problems quietly without telling anyone. So you walk into the broad ring with a green scorecard and a fleet that behaves nothing like your test group. Then give the pilot users a way to talk and make it fast. A ticket form with six required fields isn't a channel. A shared teams chat is one place, one name for it. One person watching it during the first week. Tell the pilot group what's changing in plain words, what to look for and exactly where to say something and tell them that a short message is fine. Excel closed when I opened the budget file is enough. You can find the rest. Respond quickly to. Even if the answer is. We're looking at it. A pilot user who reports a problem and hears nothing stops reporting. Now the harder part. Not everyone reports. Some failures never reach you as complaints. They arrive as absence. A user hits a blocked action, shrugs, and stops. Using that feature. They quit printing from a certain app. They stop opening the shared drive. They start sending files through a personal email account because the work one got awkward. No ticket, no error, just a quiet change in behavior that looks from your side like a ring with no problems. So ask directly. Check in with pilot users at the end of the first week and don't ask any issues. That question gets a no. Ask what they stopped doing. Ask what felt slower. Ask whether anything they normally do now takes an extra step. People will answer a specific question that they'd never raise on their own and treat silence as data, not proof. A ring with zero tickets might be healthy, or it might be full of people who gave up. Which is why the pilot can't be your only source of truth. What users say is one signal. The rest has to come from the systems themselves, the ones that report whether policy landed and whether anything broke after it did Monitoring Intune deployment. Health. Start with the simplest question you can ask about a policy. Did it arrive? Intune answers that with a status on every assignment, five of them matter succeeded. Error conflict not applicable and pending. Each one means something different and mixing them up is how teams chase the wrong problem for a week. Succeeded means the device received the policy and applied the settings. Error means it tried and failed, and there's usually a code attached. Conflict means two policies set the same value in different ways, and Intune couldn't pick a winner. Not applicable means the policy doesn't fit that device. Maybe the wrong OS edition or a hardware rule that didn't match that one is usually fine. It's the system telling you the assignment landed on something it shouldn't have pending is the one people panic over, and it's usually the least worrying. Here's why Intune doesn't push changes the second you save them. Devices check in on a schedule roughly every eight hours once they're settled, and more often right after enrollment. A device that's offline, asleep, or in a bag on a train hasn't missed the policy. It hasn't heard about it yet. So a ring sitting at seventy percent succeeded and in thirty percent pending an hour after assignment is a normal ring pending only becomes a finding when it stays pending a day later. A week later, the same device is still waiting. Then it's a device problem, not a timing. One broken enrollment, no network path, or a machine that was powered off for a month. You can force the issue. The company portal and the settings app both have a sync button, and Intune can send a remote sync to a device handy for the pilot where you want answers today, don't build a process around it for the whole fleet. Now go one level deeper than the policy. A baseline holds hundreds of settings, and the status of error on the whole profile doesn't tell you which one failed. The per setting view does open the device configuration report. Pick the profile and you can see each settings result across every device. Maybe three hundred pass and one setting fails on forty machines. That single line is your lead. Read it by pattern. Does the failure follow a hardware model, an OS build one site patterns. Turn a pile of errors into a cause, and a conflict row shows both policies that fought over the value, which tells you exactly which side to change. When the portal isn't enough, go to the device. Intune agent on windows is called the Intune Management Extension, and it keeps logs in a folder under Program Data inside the Microsoft Intune Management extension directory. They're verbose and they're rough to read, but they show what the device tried and when. For settings that arrive through the MDM channel, event viewer has the answer. Look under Applications and Services logs. Then Microsoft Windows and Device Management enterprise diagnostics provider. In the admin log, each applied setting leaves an entry there and failures carry an error code you can search. There's also a diagnostics collection you can trigger remotely from the portal, which pulls those logs without anyone touching the machine. Use that before you ask a user to send you files. Two habits make all of this faster. Check the same view at the same time for each ring so you compare like with like and record what normal looks like before a change. Because ninety four percent succeeded means nothing unless you know last week's number. But notice what all of this tells you. It tells you the policy landed. It tells you the setting applied. It says nothing about what happened to the person sitting in front of that device. Afterward, a ring can show one hundred percent success and still be full of broken workflows. Delivery is a receipt. It was never a result. Monitoring for breakage signals beyond Intune. So where does impact show up? Not in Intune. It shows up in the places people already go when something stops working. The first one is the help desk. Every ticket is a free sensor reading and almost nobody uses it that way. Tech tickets by category and tag them by ring. Then compare. If printing tickets jump in the early adopter group the week after a baseline lands. That's not a coincidence. That's a lead with a date on it. The catch is that ticket systems are messy people right? Computer broken and the category says other. So give the help desk a short list of tags tied to your changes sign in. Printing office macros. BitLocker recovery blocked app five minutes of training. It turns a pile of complaints into a chart. The second place is Endpoint Analytics, which sits inside the Intune Admin Center. It measures what users feel instead of what policies report. Start up performance tells you how long a machine takes to reach a usable desktop application. Reliability counts, crashes, and hangs per app. Silent timing shows how long people wait at the door. 01:07:53 Speaker: Why does that matter for hardening? Because some breakage isn't a block. It's a slowdown, a new credential protection setting, an extra startup script, a scan that now runs on every login. Nothing fails, so nothing alerts. But the startup score drops six points in one ring and stays flat in the others. And now you know which change to look at. Watch the trend per ring, not the fleet average. An average smooths away exactly the group you're testing. Third defender for endpoint. We talked about audit mode for ASR. And this is where that data lives. Every audited or blocked rule leaves an event. Which rule which process which file path which device. The built in reports give you the summary. Advanced hunting gives you the detail. Advanced hunting is a query window over your device events. You write a short query against the table that holds ASR events. Filter by rule and group by the process that triggered it. A few lines and you see that one rule fired nine hundred times, and eight hundred of those came from a single finance application. That's not an attack. That's a decision waiting for you. Save those queries, run them at the end of every ring. The first time takes an hour. The tenth time takes a minute. You can also hunt for the opposite signal blocks that stopped. If a rule that fired daily goes silent after a change, either the threat vanished or something stopped reporting check which the fourth layer is correlation. And this is where teams either build something useful or drown. Send your Intune logs and defender data into a log analytics workspace. Intune can export device compliance, enrollment, and audit events through diagnostic settings. Once they sit next to your sign in logs and your helpdesk data, you can ask a better question than what's broken. You can ask what changed right before it broke. The audit log is the piece people overlook. Every policy edit and assignment change is recorded with a time and an admin name. Lay that timeline over an incident graph and the gap between someone changed a policy and ticket started often measures in minutes. A workbook makes that visible one page per ring policy changes along the bottom, ticket counts, crash rates and ASR hits stacked above. You don't need anything fancy. You need one view that the endpoint team, the security team, and the helpdesk lead all read the same way. Then set thresholds before you need them. Decide that a ticket rate above a certain multiple of normal in any single ring pauses the rollout. Write it down. A threshold you invent during an incident is a negotiation. One you wrote in advance is a rule, and that rule leads to the part nobody likes to rehearse. A signal fires, the ring pauses, and somebody has to decide whether to undo what was just done. If you haven't tested that path, the answer won't be fast and it may not even be possible. Rollback and kill switches. Most admins believe in a button unassigned the policy, and the device goes back to how it was. Clean. Simple. A one line answer to any bad day. But in reality, that's only true for some settings. Intune policies work in two ways. Some settings are enforced. The device holds the value only while the policy says so. Remove the assignment and the next check in puts it back to default. Those revert. Others are written once into the registry or the system itself, and nothing in the policy tells the device to undo them. Those persist. The policy goes away. The setting stays. So a baseline can be unassigned, but not always undone. You won't know which kind you have by reading the profile. You'll know by testing. Take a pilot device, apply the policy, confirm the setting, then remove the assignment and sync. Watch what comes back. Do that for the settings you worry about. Most credential handling, firewall rules. Anything that changes how a user signs in some pieces need a different kind of reversal. BitLocker doesn't decrypt because you removed a policy, a drive stays encrypted, and that's a good thing. But a changed encryption method or a startup PIN requirement may need a deliberate step to walk back. A lapsed policy removed from a device leaves it with whatever password it last rotated to, and an ASR rule set to block returns to default only after the policy leaves and the device syncs. So a rollback there takes a full check in cycle to reach everyone, which means speed has a flaw. You can't undo a change faster than devices can hear about it, so plan the rollback before the rollout and plan it per ring. For each ring, write down three things what gets reverted and how, which settings won't revert and need a script or a manual fix, and how long the whole thing takes, measured from the decision to the last device settling. If the honest answer is about a day. Then you now know that every change you ship carries a day of exposure. That number should shape how brave you are. Some teams go further and stage the reverse policy in advance. A second profile already built that sets the old values explicitly. Instead of removing the baseline and hoping you assign the reversal. It sits unassigned in the tenant named clearly waiting when you need it. You don't design anything under pressure. You assign a group and wait. Then comes the part that's about people, not policy. Who's allowed to pull the plug? In many organizations, the answer is a committee. Security wants to hold the line. Endpoint engineering wants to fix forward. The helpdesk lead wants relief now. And while they discuss it, the tickets keep coming. So decide in advance and write it down. One role holds the authority to pause or reverse a ring. Maybe it's the endpoint engineering lead. Maybe it's the on call admin and the trigger is the threshold you set earlier ticket rate above the line, or a critical app down for a defined group. And that person acts first and reports after. No vote, no approval chain. Pausing is cheap. Reversing is cheap. If you've prepared. Debating costs the most. And the rollback isn't a failure, it's the control doing its job. The ring contained the damage to a small group. You pulled back and now you have a reason and a fix to bring forward. But sometimes the signal isn't a mistake at all. The policy worked exactly as designed and it still broke something that has to keep working. That's not a rollback problem. That's an exception. Exceptions. As a design system, every tenant has them. The lab machines that run unsigned test tools. The engineering workstation with a compiler that looks to defender exactly like malware. The finance desk that still opens a spreadsheet from twenty eleven built on macros. Nobody alive fully understands. You didn't plan for these devices. They were already there, and the baseline doesn't know they exist. So exceptions aren't a sign that your policy failed. They're the sign that your fleet isn't uniform, and it never was. The only question is whether you design for that or let it happen to you. Here's what happens when you don't. A user complains. An admin trying to be helpful drags the device out of the policy group. No note, no reason. No date. Three months later, that machine is running with no encryption requirement and nobody can say why. Multiply that by forty devices over two years and you don't have a baseline anymore. You have a rumor of one that's the silent opt out and it's the most common way hardening dies. The fix is to make the exception a real object in your tenant. Not a favor, not a one off a group. Create an exception group for each control that needs one. Name it so the purpose is obvious. Exception. Azure office macros. Finance. Legacy. Then assign the policies to everyone except that group. Now the device that's exempt is visible. You can list it, count it and query it. But a group alone isn't enough. A group with no context is just a quieter version of the same problem. So every exception carries four facts written where the next admin will find them an owner, a named person who's accountable for that device or that workflow. Not a team, a person, a reason. One sentence specific enough to test legacy invoicing tool requires unsigned macros, not business. Need a scope which control is relaxed and only that one. A device exempt from the Azure Macro rule doesn't also skip BitLocker and an expiry a date when the exception ends. Unless someone renews it, that last one does the most work without an expiry. Exceptions only grow with one. Every exception forces a small question on a schedule is this still true? You can store these facts in the group description, in a tracking list, in SharePoint, or in a ticket system. What matters is that the record lives somewhere outside one admins memory. Now, an exception shouldn't mean no protection. It should mean different protection. If the finance machine can't take the macroblock ask what else reduces the risk? Maybe the device sits behind stricter network rules. Maybe it gets a tighter defender cloud protection level, or it loses internet access except to the tools it needs. Maybe the macro enabled files are limited to one trusted folder and nothing else runs. These are compensating controls. They don't match the baseline, but they cover the same threat from another side. Write the compensating control into the exception record right next to the reason. An exception with no compensating control isn't a decision, it's a gap you've agreed to ignore. Then comes the part that keeps the whole thing honest. Review. Once a quarter, open the the list. Go through every exception and ask the owner three things. Does this still need to exist? Has the application been fixed, replaced, or retired? Is the compensating control still in place? You'll be surprised by the answers. A legacy tool got replaced last spring and nobody told security. A lab closed and the machines were reassigned. Some exceptions disappear the moment someone looks at them. The ones that remain get renewed with a new date and a fresh signature. That's the cost of keeping them. And it should cost a little on purpose, because without this loop, the exception list drifts upward slowly, then fast. And one day the exempt group is bigger than the pilot ring, and the baseline covers a minority of the fleet. That's how an exception turns into the new normal. But designing the system is only half of it. The harder question is whether the business will use it or walk around it. Governing the exception process without becoming the blocker. Think about the last time you needed something approved at work. You filled in a form. It went to a queue. Someone asked a question. You answered. Two weeks later you got a yes or you gave up and found another way. That's what most exception processes look like. And that's exactly why people walk around them. So the first design rule is speed. The request path has to take minutes, not weeks. One form five fields. Which device or group which control why, for how long and who owns it. That's enough to start a short request that gets answered today. Beats a thorough one that sits for a month, because the user with a deadline won't wait. They'll find their own fix. They'll use a personal laptop or ask a friend for admin rights, or just stop using the managed machine. Set a response time and keep it same day for a pilot question. Two days for a standard request. Publish the number so the business knows what to expect. Now the harder part who decides? In many shops it approves its own exceptions. Security says yes or no, and the business finds out afterward. But think about what an exception really is. It's a risk someone chose to carry, and the person who carries it should be the one who signs for it. So the business owner signs the head of finance for the finance macro exception, the engineering director for the compiler workstation. IT and security supply the facts. What the control prevents, what gets exposed without it and what compensating control comes in its place. Then the owner reads that and puts a name on it that changes the conversation suddenly. Can you just turn it off? Becomes. Are you willing to accept this risk in writing for ninety days? Most people pause there. A good number decide they don't need the exception after all, and the ones who do still need it have just made it a business decision, not a quiet favor from an admin. Then measure the system because an unmeasured process drifts. Three numbers cover most of it. Count how many active exceptions exist per control age, how long each has been open, and how many are past their expiry and percentage of fleet. What share of devices sits outside the baseline for each setting? Put them on one page and look at them monthly. A count of twelve. Steady with every item inside its date is a healthy system. A count that climbs every month is telling you something. So is an age column full of overdue entries, because that means the review loop stopped and watch which control the exceptions cluster around. This part matters most if forty exceptions all point at the same asser rule. You don't have forty difficult users. You have one rule that doesn't fit how the business works. Same with a compliance check that half the engineering team can't pass, or a BitLocker setting that trips on one hardware model. High exception volume on a single control is feedback about the policy, not about the people asking. So treat it that way. When a cluster forms go back to the control, maybe the rule needs a narrower scope. Maybe the application needs fixing. Maybe the hardware needs replacing. Fix the cause once, and a dozen exceptions close at the same time. That's the difference between a process that blocks and one that learns each request, each signature, each review feeds something back into the baseline, and that feedback is the piece that ties every part of this together, because none of it runs once it all keeps arriving. The new model hardening as a continuous loop. Here's what changes. Once you've built the rings, the exceptions, and the monitoring, you stop thinking of hardening as something you finish because nothing in this system holds. Still, Microsoft publishes a new baseline version, and your existing profile doesn't update. It sits there aging until someone chooses to move it. Defender for endpoint keeps collecting ASR audio data. So a rule you parked in ordered last month now has four more weeks of evidence behind it. Devices drift out of compliance as updates slip and users change settings. New hardware arrives with different firmware. A department buys a tool. Nobody in it has heard of. All of it arrives continuously. None of it waits for your next project window. And that's where the model breaks for good. If hardening is an event, every one of those arrivals is an interruption. If it's a loop, they're just input. So what does the loop look like? It has five steps and they repeat, observe, test in the pilot, expand through the rings, measure, retire. What you no longer need. Observe means you read the signals before you touch anything. A new baseline version, a spike in ASR hits a cluster of exceptions around one control. Something tells you it's time to change. Testing the pilot means the change meets real devices first with the users who'll tell you the truth. Small, watched and reversible expand means the change moves ring by ring, and each ring opens only when its exit criteria clear. Not a date. evidence measure means you look at what happened after delivery tickets, crash rates, compliance numbers, recovery events. Did the change do what you meant it to do? And did it cost what you expected? And retire is the step most teams never reach. Exceptions that expired settings that no longer apply. Old policy profiles that still sit in the tenant assigned to nobody. Confusing the next admin. A loop that only adds things grows heavier every cycle. One that removes things stays something you can actually reason about. Then the loop starts again because something new has already arrived. Now a loop like this needs owners. Otherwise it's a diagram. Security sets the intent. They decide what the organization is trying to prevent. Credential theft, data loss from a stolen laptop, ransomware through a macro. That's their job, and it's a real one. But intent isn't. Delivery. Endpoint engineering sets the delivery. They choose how a control reaches a device, in which order, through which ring, with which rollback ready. They own the policy objects, the groups, the filters and the reports, and the help desk supplies the signal. This one gets overlooked. The people answering the phones see the impact before any dashboard does. If they aren't part of the loop, you've cut off your fastest sensor. Three groups, three different questions. What do we need to prevent? How do we ship it safely, and what is it doing to people right now? When those groups work separately, you get the old pattern. Security throws a baseline over the wall, the help desk absorbs the pain, and endpoint engineering gets blamed for both. When they share the loop, the same change moves through all three views before it reaches the broad ring. One more piece how you report this upward. Executives don't need to hear that you deployed four hundred settings. That's activity and it tells them nothing. They need outcomes. Fewer security incidents tied to endpoint weaknesses, fewer lockouts caused by compliance changes, faster recovery when a device is lost or a BitLocker key is needed, a smaller shrinking list of exceptions with names attached. Those numbers do something else, too. They show that hardening and productivity aren't opposites. A lockout rate that falls while coverage rises is the proof that the rollout model works. So that's the structure. Observe, test, expand, measure, retire three owners, one loop, and numbers that mean something to the people funding it. But a loop only matters if it starts. And starting is a different problem from understanding. So what does the first month actually look like? A practical first thirty days start with a week of looking not changing. Week one is inventory. Two lists. Both will be uglier than you expect. The first list is policy conflicts. Open every profile assigned to windows devices. Baselines, settings catalog policies, endpoint security policies, old configuration profiles. Then check the conflict and error views. Anything showing a conflict gets written down with both policies named add your Group Policy Analytics report next to it and mark the settings you'll delete instead of migrate. By Friday, you should know which policy wins for every setting you care about. The second list is hardware readiness. Pull every device with its model firmware version, TPM version, and secure boot state. Flag the machines with no TPM or an old one. Those are your BitLocker problems. Those are your compliance failures, and you haven't written a single rule yet. It's much cheaper to learn that now than during a ring. Week two is where the evidence starts. Put the ASR rules in audit mode on the pilot group, not block audit. Then let them run. Don't touch them in the same week, verify BitLocker recovery keys. Pick a handful of pilot devices and confirm each key sits in entry ID. Then do the full drill. Have a help desk person look one up. Verify the user and read it back. You're testing the process as much as the escrow. A key that exists but can't be found in two minutes might as well be missing. Week three brings two new pieces. Start a pilot on a small group. Confirm that passwords rotate that the right role can read one, and that the read shows up in the audit log. Then build your compliance policy, assign it to the pilot, and pair it with conditional access in report only mode, nothing blocks your reading. What would have happened and who you forgot. Also, in week three, write the notification text for plain sentences. Name the problem. Give the fix. State the deadline. Add a contact. It's small work and it decides whether users fix their own devices or call you. Week four is the first real expansion, but before you open the next ring, define the exit criteria on paper delivery above ninety five percent tickets at normal levels. Every ASR ordered, hit reviewed, no recovery spikes. One named person signs off. Then check the numbers against that list and move only if they clear. Pause on one thing. Before you start, write the rollback plan for the ring you're about to enter and name the person who can pull the plug. If you can't answer those two questions, you're not ready for week four. You're ready for a longer week three. That's the whole month. Inventory evidence, trial, expansion. None of it needs a big announcement and none of it needs a week end. By day thirty, you won't have a hardened fleet. You'll have something more useful, a loop that runs with data behind every step. Conclusion. Security that users don't notice. Hardening succeeds when delivery is staged, observed, and reversible. The settings were never the hard part. Microsoft has already written most of them for you. What decides the outcome is how they reach people, and whether you can see what happens next. Because the strictest policy in your tenant is worthless if it gets rolled back on Friday. If this changed how you think. Leave a review. It helps more endpoint admins find this episode and connect with me on LinkedIn and send in the topic you want next.