Microsoft Intune Compliance Policies - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What are compliance policy is actually checking? It's Monday morning and Intune has locked your own laptop out of work. You get no warning, only a sign in box that keeps saying no. That gatekeeper is a Microsoft Intune compliance policy, and it's the checklist your device has to pass before your company trusts it. With data. The checklist itself never blocks you because a separate layer does the blocking. By the end, you'll know what a compliance policy checks, what happens when a device fails, and where the whole system gets it wrong. This is the plain version with no jargon and no admin console tour. A compliance policy is a set of rules that a device has to satisfy, and Intune is the service that asks the questions. It only asks them about devices it manages, which just means devices that have been enrolled or signed in and registered with the company. For you. That usually looks like signing into the company portal app one time or answering a prompt the first time you open outlook on a new phone. After that, the device is on the list and Intune can start asking. Intune checks whether the operating system has the latest updates, whether the drive is encrypted, whether there's a PIN or a password, and whether anyone has tampered with the device in a way the manufacturer never intended. Each answer rolls into a single verdict, and that verdict is either compliant or not compliant. That verdict decides whether your laptop or phone is allowed anywhere near company email, teams and files. So when a device falls short, the first thing you notice isn't a list of rules you notice your inbox won't load, and teams keeps asking you to sign in again. The rule stays invisible and the consequence doesn't. Companies don't do this to be difficult. A single lost laptop with an unencrypted drive can expose customer records, and a compliance policy is the cheapest way to make sure that laptop was protected before it ever walked out the door. There's one setting buried in Intune that trusts devices nobody ever gave a policy to, and it's switched on by default. We'll come back to it later because it explains a lot of the confusion beginners run into. The two halves of Intune compliance. The first surprise is that Intune compliance isn't one list, it's two lists. Sharing a name and mixing them up is the fastest way to get confused. The first list is tenant wide, and you can think of it as a house rule that applies to every guest, whether or not you handed them a printed sheet. Two settings live there and both matter. One sets how long a device can go without reporting in before Intune stops trusting it, and the default is thirty days. The other decides what happens to a device that has no policy assigned at all. That default from a minute ago lives right here in this first list, and it's the one that causes the most confusion. The second list is the one you build. These are the platform specific policies you assign to groups of people or devices. Windows gets its own policy. iPhones and iPads get their own, Android gets its own, and Mac OS and Linux each get theirs. That's where the real rules live, like requiring encryption or setting a minimum operating system version. There's also a built in policy that every enrolled device receives, and it never shows up in your list of custom policies, it quietly checks three things. First, the device has a compliance policy assigned. Then the device has to be active and in contact with Intune. Finally, the enrolled user has to exist with a valid license. That baseline exists, so a device can't be completely invisible. Even when nobody builds a custom policy for a brand new tablet. The built in check still asks whether it's online and whether the person using it has a valid license. A device has to pass this built in check, and every custom policy you assign to it, and missing any one of them tips the whole result to non-compliant. That's two lists plus a baseline. Nobody sees all feeding one verdict. What a policy can actually look at. Now for the rules themselves. And most of them sound more technical than they are. Take the operating system rule. You're telling Intune the oldest version you'll accept. So a phone that has missed months of security fixes gets flagged. There's a jailbreak rule to which catches phones and tablets that someone has unlocked to install software the manufacturer blocks on Android. The same idea is called routing. Then you have the encryption rule, which checks that the data on the device is scrambled. So a lost or stolen laptop doesn't hand over everything on it. A passcode rule makes sure a device can't sit there unlocked with no PIN. If your company uses threat detection software, a policy can also check the level of risk the phone is reporting, and a separate security app on the device does the reporting. If that app finds malware, the report can flip the verdict on its own. Windows devices get a longer list, and the names are worth learning because they show up in error messages. BitLocker is Microsoft's drive encryption, and a policy can require it. Secure boot makes sure the machine starts up in a trusted state, so a tampered startup process gets caught. Code integrity confirms that the drivers and system files loaded into memory are the genuine signed ones. Then there's the trusted platform module, a small chip that stores the keys, protecting the device, along with checks for the firewall, antivirus, and the device's risk score from Microsoft Defender for endpoint building one of these policies feels less like coding and more like filling out a form. You pick a platform, expand a category, and flip a switch to require or ignore each setting. Nothing hides behind a command line. The idea to hold on to is that none of this is one giant switch. Each platform gets its own policy, and you pick the lines that fit your organization. A front desk tablet that never leaves the building might need fewer rules than a sales laptop that flies around the country every week. Failing one of these checks doesn't just sit there doing nothing, it triggers a response. And that response is the part people actually feel. What happens when a device fails? Every compliance policy comes with one action built in and it can't be removed. The moment Intune decides the device isn't compliant, it marks the device non-compliant. That's the default, and it fires immediately at zero days. Everything else is optional, and this is where you get to be gentle or strict. You can send the user an email explaining the problem, and Intune can keep sending it on a schedule until things get fixed. You can push a notification to the device through the company portal app. You can even remotely lock the device, which forces a PIN or passcode before anyone can use it. Again, that email matters more than it sounds. People who get blocked with no explanation assume the worst, and a short message that names the exact problem turns a support ticket into a two minute fix. Then there's the sharpest tool, and it deserves a careful explanation. A policy can add a device to a list. Retire sounds dramatic, and it is because it removes all company data from the device and drops the device from Intune management entirely. The saving grace is that it never happens by itself. An administrator has to open that list and confirm the retirement one device or all of them before anything is wiped. The friendliest part is the grace period. Every action can be scheduled for a number of days after the device fails, and that number can run from zero all the way to three hundred and sixty five. If you set the email for day two and the lock for day seven, people get a real chance to fix the problem before anything bites. So the checklist asks the question, and these actions decide how loudly the answer lands. The policy doesn't block anyone. Now for the twist that trips up almost every beginner. A compliance policy never blocks your access on its own. It produces a verdict, and something else acts on that verdict that something is called conditional access. Picture a building with a checklist at the front desk and a guard at the door. Intune writes the checklist and checks it. And conditional access is the God. The God looks at the verdict and decides whether to let the device through to email teams, SharePoint, and the rest of the company's resources. The checklist alone can't keep you out, and the guard alone has nothing to check, so you need both to make the system work. There's a licensing detail worth knowing here because it catches people out. Conditional access is a feature of Microsoft Entry ID, which is Microsoft's cloud service for identity, and using it requires an entry ID, P1, or P2 licence. Ensuring compliance by itself doesn't require entry ID at all. That means it's entirely possible to build a careful set of compliance policies and have nothing enforce them, because the guard was never hired without conditional access. A compliance policy is really just a report card. It tells you which devices are healthy and which aren't, and it can email people who need to fix something, but it can't stop a sick device from opening your inbox. That's why two teams can build almost identical policies and get completely different results. One of them hired the guard and the other one only wrote the checklist. There's a second style of conditional access worth knowing about. Device based checks assume the whole device is managed, which works well for company laptops. App based checks protect just the app, which is how companies handle personal phones that people don't want fully managed. It's the same guard standing at a different door when the two work together. The flow is simple. The device reports its health to Intune, and Intune passes that status to entry ID. If the conditional access policy says a device must be marked compliant than a healthy device gets in and an unhealthy one gets stopped. It's the same device, the same person, and the same inbox. And the only thing that changed was the verdict. That's the real control point. And it lives one step away from the policy everyone talks about. One ordinary morning for a non-compliant laptop. Let's make this concrete, because the abstract version is where people get lost. Picture a marketing manager named Dana. Dana opens her work laptop on a Tuesday and outlook refuses to sign in. Teams throws up the same wall. The laptop works fine for everything else, which makes the whole thing more confusing, not less. Dana assumes the network is down and the network is fine. What actually happened is that a security update to the compliance policy landed overnight. Her laptop was still running an older version of windows, so it now fails the minimum version line. The verdict flipped to non-compliant and conditional access did its job. There's no email, no teams, and no files until the device is healthy again. The fix is quieter than the problem. Dana opens the Company portal app, which is the little helper app that connects her device to the company. It tells her why she's blocked in plain language and points her to the update. She installs it, the laptop checks in with Intune and access comes back. The honest wrinkle is that the checkin doesn't happen the instant she clicks update, Intune learns the device's state when the device checks in, and the report and admin sees reflects the last check in. Not this second. Microsoft notes that when a device is online, it can take up to twenty four hours to show up in a policy report. In practice, it's often faster, but the point stands compliance is a snapshot, not a live feed. There's a second wrinkle on shared machines. A report shows the compliance state of the last user who checked in, so a shared laptop can report one person's status while someone else is sitting at it. If you've ever seen a device that looks fine to you but wrong to it, that's usually the reason the mistakes people make. First, almost everyone makes the same handful of mistakes with Intune compliance, so it's worth naming them before you trip over one. The first is that default setting we flagged earlier out of the box. Intune marks devices with no compliance policy assigned as compliant. That runs backwards from what most people assume, so it's worth reading twice a device that nobody gave a single rule to gets treated as fine. Microsoft recommends flipping that setting to non compliant when you use conditional access, so unmanaged devices don't walk straight through. The second mistake is treating a passing score as proof that a device is secure. A compliance policy is a checklist, and a checklist only knows the questions you asked. A device can tick every box and still be compromised in ways the policy never thought to check compliance lowers risk. It doesn't remove it, and believing otherwise is how people get surprised. The third mistake is going too far in either direction. If you set the rules too loose, you've built security theater that stops nothing. If you set them too strict, you lock out half the company on a Monday, which is a fast way to lose the trust you were trying to protect. Good policies, start small and grow. The last one is a quiet trap with a boring name. When a compliance policy and a device configuration policy disagree, the compliance policy wins even when the other policy is stricter. So an old rule sitting in your compliance policy can quietly override a newer, tougher setting somewhere else. If something refuses to behave the way you set it up, that conflict is a good place to look. first. There's one more mistake that bites at the worst possible time. If every admin account is covered by the strictest policy and something goes wrong with the policy itself, nobody can get in to fix it. Most teams keep one emergency account outside the rules and they test it on purpose. The limits nobody mentions. Compliance policies do a lot, and it's fair to be honest about where they stop. The biggest limit is timing. Nothing here is instant. A device's status is whatever Intune last heard, and a report can lag behind reality by hours. That gap is why a user can fix their laptop and still be blocked for a while, and why an admin can see a device as fine when it isn't anymore. If you expect real time, you'll spend a lot of energy being frustrated. The second limit is a safety valve that turns into a blind spot. When a setting can't be evaluated and reports an error. Intune keeps the device's previous compliance state for up to seven days before it flips to non-compliant. That's meant to shield people from false alarms during a glitch. It also means a device can hold on to a stale, healthy verdict for a week. The third limit appears the moment you want to check something Intune doesn't offer out of the box, you can write custom rules, but that means a rules file and a detection script, and the scripts output is capped at two thousand and forty eight characters. If you pile on too many custom rules, the output gets cut off, which breaks the whole evaluation. The last limit is a moving target. One of the older Android management options, called Device Administrator, is deprecated and no longer available on devices with access to Google's mobile services. Plenty of older guides still walk beginners through it. If you follow one of those, you'll spend an afternoon chasing something that no longer exists. There's one more gap worth naming compliance only reaches devices that Intune manages a personal phone that someone uses to check work email through the browser without ever enrolling can sit completely outside this whole system. That's exactly why app based protections exist. As a second line. None of this makes compliance policies a bad idea. It just means the system is a tool with edges, and knowing the edges is how you use it well. Where this sits in Microsoft three hundred sixty five and Azure, this all lives in your Microsoft world in a simpler shape than the acronym Soup suggests. Intune is the device management piece of Microsoft three hundred sixty five. It handles the laptops, phones and tablets, and it usually comes bundled rather than bought separately. The base plan, called Intune Plan one, comes with Microsoft three. Sixty five E three, E five, F one and f three with Business Premium and with the enterprise Mobility and security bundles, there are higher tiers as well, but for a beginner, the headline is simple. Many organizations already own Intune and don't realize it. The identity half of the story lives in Microsoft Android. The Microsoft service that manages who people are and what they can reach. That's where conditional access lives. And that's where the actual yes or no decision happens. Intune reports on the device entry ID decides on the access and together they produce one outcome. There's a special case worth a mention for shared devices like kiosks and front desk tablets that don't belong to one person. There's a device only license. It costs less, and it comes with a trade off. Those devices don't support conditional access, app protection policies or the user based features. You can still manage a lobby, tablet or a shared warehouse scanner, but you can't put it behind the same access checks as everyone else. This isn't happening inside Azure. The way people imagine the devices report to Intune, the identity decisions happen in entry ID, and Azure is where the underlying cloud services run. For a beginner. The useful part is simply knowing which service does which job. That default setting. From the start of this episode, the one that trusts devices with no policy, is the reason the whole picture can look more protected than it actually is. If you flip it to not compliant, the gap closes the short version. And one question for you, let's pull it together. A Microsoft Intune compliance policy is a checklist your device has to pass, and it comes in two halves, the tenant wide rules and the platform policies you build. When a device fails, a set of actions decides what happens, and a grace period decides when. The checklist never blocks anyone by itself, because conditional access is the guard that acts on the verdict. And the whole system is a snapshot, not a live feed. My question for you is simple which device in your life holds the work you'd hate most to lose? And would it pass this checklist today? Tell me in the comments because I read everyone. If this made the topic feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work.