When we set up an environment, we start with a clear picture of how it should look. We pick a standard and build a baseline, which is really a promise about how every device should be hardened. For a short while, every device matches it. Then time passes. Settings get turned off during troubleshooting, new profiles get layered on, devices get onboarded a little differently, and each small change nudges a few machines away from where they started.
Imagine a fleet of 15,000 Windows devices aligned to a CIS Level 1 baseline. A support team temporarily relaxes a setting during troubleshooting. A new configuration profile introduces an overlapping setting. A business unit onboards a few hundred new devices using a slightly different process. Nothing breaks, nobody notices, and every change makes sense on its own. Over time, 2,000 devices have drifted away from the intended configuration. There is no outage, no security alert, and no obvious sign anything happened. The baseline still exists on paper. It just no longer describes reality.
At scale that adds up fast. One intended configuration slowly fragments into hundreds of variations. That gap between intended and actual state is drift, and it’s normal. It’s just what happens to any configured state nobody keeps checking, and the mistake is treating a baseline as a one-time project instead of something you keep verifying.
The risk is that security rarely fails all at once. Most environments don’t become vulnerable because a single control disappears overnight. Instead, protection erodes one setting at a time. A browser hardening policy is missing on hundreds of devices. A credential protection setting conflicts with another profile and stops applying across an entire department. Nobody notices because nothing is visibly broken. Over time those small gaps accumulate until the security posture of the fleet no longer matches the standard it claims to follow.
This blog post is about that gap. What it is, why spot checking won’t catch it, how to measure it across a whole fleet, and how to close it.
CIS Benchmarks
CIS Benchmarks are secure configuration guides published by the Center for Internet Security. They are built by consensus, so what you get is a community-backed answer to what “secure” means for a given product. There are benchmarks for well over a hundred technologies, including Windows, Edge, Office, and Intune itself, each a list of settings with a recommended value and guidance for auditing it.
They are living documents. Since 2023, the Windows benchmarks have been refreshed yearly to line up with Microsoft’s release schedule, with new versions covered within 90 days. So, the one you adopted two years ago is probably not current. That matters here, because your fleet drifts from the baseline while the baseline itself moves under you when a new version lands.
These days, CIS is close to a default requirement for most enterprises. A few years ago, it was fairly niche, and now it turns up in cyber insurance questionnaires, customer security reviews, and audit checklists. Getting it right and keeping it right isn’t really optional. It comes in two levels, a practical Level 1 and a defense-in-depth Level 2. Most fleets I see start at Level 1. The point of adopting it is a fixed, recognized target to measure against, one you can point to when an auditor or insurer asks how your endpoints are hardened.
From GPO build kits to Intune-native benchmarks
How you apply a CIS baseline changed as management moved to the cloud. For years, this was a Group Policy job. CIS shipped Build Kits, prebuilt GPO packs you imported into Active Directory, and Group Policy handled any overlap for you. As fleets moved to Intune, CIS followed, with a dedicated Intune for Windows benchmark at the start of 2023 that was rewritten in 2024 around the Settings Catalog. The Build Kit is now delivered as importable JSON profiles. CIS also added a mapping document that lines up each Intune recommendation with its on-prem GPO equivalent, so teams moving from AD can carry a known baseline across instead of rebuilding it.
One detail from that guidance is worth pulling out, because it’s the same point I keep coming back to. CIS specifically tells you not to set the same control in both GPO and Intune on a hybrid device. Set it in one place and use the mapping to divide the work. The standard treats an overlap as something to design out, not something the platform will quietly sort out for you. That is exactly the behavior worth understanding next.
Precedence is gone, and conflicts are silent
In the AD world, resolving overlaps was mechanical. When two policies disagreed, precedence sorted it out. Link order, enforced links, and block inheritance gave you a deterministic winner and a resultant set of policy you could reason about.
Intune doesn’t work like this. There is no link order and no precedence you control. I have seen people try to approximate it with layered profiles, groups and filters, but none of that gives you the deterministic winner GPO did.
When two profiles set the same setting to different values, Intune does not pick a winner. It reports a conflict, and for most settings, a conflicted setting simply doesn’t apply.
There is one exception. Certain security-related settings resolve to the most restrictive value, so the stricter one wins. You cannot rely on it, though, because you have to know in advance which settings behave that way. For everything else, the device is simply left off the value you intended, and nothing tells you which profile should have won.
So an overlap that GPO resolved quietly becomes a silent conflict, a setting that looks configured but isn’t enforced. The fix is to keep the baseline in as few profiles as possible, with as little overlap as you can manage, and to watch the conflict state closely. In Intune, a conflict is drift.
One more Group Policy behavior hides drift completely. Setting a value writes it to the registry, but removing it from the policy, going from Enabled or Disabled back to Not Configured, doesn’t clear it. The value stays behind, because Not Configured means leave this alone, not put it back. So the device keeps enforcing something that no longer exists in your policy, and nothing tells you. That is drift in its purest form: a setting with no owner.
How to think about tracking drift
There is no single button for this, so a few questions help sort out what you actually need before reaching for a tool.
First, what are you measuring against? Some approaches only tell you whether your own configuration applied. Intune reports assignment status and per-setting results, so you can see that a profile deployed and whether it hit an error or a conflict. That’s useful, but it answers “did my policy apply,” not “is this device hardened to the standard,” and only some methods measure against the benchmark itself. Be clear which one you are getting, because only one of them holds up in an audit.
Second, is it continuous and fleet-wide, or a point-in-time sample? A scan tells you the state at the moment you ran it, which is what you want for audit evidence and close to useless as an early warning, because drift the next day stays invisible until the next scan. Anything you run one device at a time has the same problem, because the healthy majority hides the drifted long tail. What I want to know is how many devices across the whole fleet are off the baseline right now, and which controls have drifted, which usually means a scan for evidence and a continuous view on top of it.
Third, does it close the loop, and what does it cost to own? Measuring drift and fixing it are two different jobs, and a lot of setups stop at the report. You can build a lot of this yourself with PowerShell and Graph against a known-good baseline, which is fine for a one-off but a real maintenance burden as a permanent capability. Buying removes that burden, building keeps you in control, and neither is wrong as long as you choose on purpose.
Closing the gap
Seeing the gap is only half the job. Closing it is where people reach straight for the reapply button and stop there.
Reapplying is not always fixing. If a device has drifted, reassigning the profile will often push the value back down, and for a one-off, that’s fine. But most drift has a cause, and if the cause is still there, it just drifts back. So transient drift reapplies cleanly, while structural drift needs a configuration change first.
It’s also why I don’t chase individual devices. If the same control has drifted on a few hundred machines, that’s almost never a few hundred separate problems. It’s usually one cause, a conflicting profile, a gap in assignment, or a setting that was never in the baseline. Fix that, and you fix the whole cluster.
When you work through a gap report, go after exposure first. Focus on the controls that carry real security weight, and the ones drifted across the most devices. The long tail needs automation, because doing it by hand doesn’t scale. Just remember that automation enforces a bad baseline just as happily as a good one, so keep it behind a test ring and a change you can back out.
Leave room, too, for the drift that’s meant to be there. If a device or group has a good reason to sit off the benchmark, mark it, own it, and review it. Otherwise, it shows up as noise, and people stop reading the report.
Keeping it in check
Closing the gap once is a project. Keeping it that way comes down to three habits.
- Measure continuously, not now and then. A baseline is a state, not an event, and a state you check once a quarter is one you don’t really know. Whatever you use should run on its own and keep running, so the gap is visible on a normal working day, not just before an audit.
- Alert on movement, not just on status. What you want is the change itself, a control that was compliant and now isn’t, or a conflict that appeared where there was none. Drift is easiest to fix when it’s small and recent and you still remember what changed.
- Give the baseline an owner. A baseline with no owner drifts because nobody is accountable for the number moving the wrong way. Someone should own it, its version, its exceptions, and its fleet-wide compliance, the same way someone owns patching or identity.
Final thoughts
A security baseline is not something you deploy and file away. It’s a claim about your fleet that’s only as good as the last time you checked it. Define it against a recognized standard, measure the gap continuously across every device, fix the causes rather than the symptoms, and give someone ownership of it. A baseline only has value if it continues to describe reality. Do that, and it stays a description of how your endpoints are actually configured, not how you hoped they would be on the day you set them up.
