A deployed baseline is not a finished baseline. OpenIntuneBaseline moves, and the interesting problem is never importing the new version. It is carrying a live deployment from one version to the next without falling behind upstream on one side or flattening your own adjustments on the other. This is the operate phase, and it has exactly two failure modes: drift away from the baseline, and drift away from yourself. The whole discipline is keeping those two from becoming one unrecoverable mess.
What a version actually is
Start by correcting a natural misreading. The release number, v3.8 as I write this, is the train, not a stamp applied to every policy inside it. Each policy carries its own version in its name, reflecting when that specific policy last changed, so a v3.8 release legitimately contains policies still marked v3.1, v3.3, and v3.4 sitting beside genuinely new ones. When you compare, you are not looking for everything to read v3.8. You are looking for what moved.
v3.8, released in May 2026, is a useful concrete example. It added a couple of Settings Catalog policies, one hardening NTLM and one governing Automatic Restart Sign-On. It added firewall rules that block a few of the usual living-off-the-land binaries from reaching the internet. It retired a deprecated Defender setting and the last remnants of the Chrome profiles. And, quietly, it gave every policy a per-policy tracking identifier. That last change is the least visible and the most operationally important, and I will come back to it.
The compare, and what it is comparing
The Deployer’s Existing Deployment path exists for precisely this moment. You sign in, it reads the latest release straight from the repository, and it reports your tenant against upstream: what is new, what changed, and what you already hold. On a real tenant that is the difference between a guess and an inventory. Walking it against a tenant that already carried the baseline, it correctly separated the handful of genuinely new policies from the dozen and more already present, rather than offering to re-import the whole set. That report is the entire reason to reach for the tool at update time rather than eyeballing a changelog against a policy list.
Be precise about how the matching works, because it governs everything downstream. The tool compares by policy name. If you deploy something whose name already exists and select it regardless, you get a duplicate rather than an update. So updating is not “select all and deploy again.” It is a smaller, deliberate act: deploy what is genuinely new, and handle what changed as a conscious decision rather than a bulk operation.
Drift away from yourself: the fork rule
This is where most estates quietly wound themselves. You deploy OIB, and over the following months you tune. You loosen one setting for a line-of-business application, tighten another to satisfy an auditor, disable a third that fights your environment. If you made those changes inside the OIB-named policy, the next version’s compare cannot help you, because your policy no longer matches upstream and nothing anywhere records what you altered or why. You have traded a known-good baseline for a personal one that looks official and is not.
The discipline, which the tool’s own guidance states plainly, is to never edit an OIB policy in place. When you need to customize, duplicate the policy, give it a name that is visibly yours, and change the copy. The original stays pristine and comparable; your fork carries your intent under a name that announces itself as a deviation. Then at version time the compare speaks cleanly, telling you what moved upstream, and you make a conscious decision about whether your fork should absorb that change or hold its ground. This one practice is what keeps the two kinds of drift separate and therefore both recoverable.
It is also why the restraint at deploy time, in [5.1.4], was worth insisting on. A tool that let you edit policies on the way in would have destroyed comparability before you ever reached your first update. The Deployer refuses to do that, and the refusal is a feature you only appreciate a version or two later.
Working an update
Read the changelog before you touch the diff, not the other way round. The compare tells you what changed; the changelog tells you why, and OIB documents its reasoning where it deviates from CIS or Microsoft. A firewall rule that now blocks notepad.exe from reaching the internet is not an oversight, it is a deliberate mitigation against a common attack technique, and you want to understand that before some application owner talks you into an exemption. Judgment at update time is only as good as the rationale you bring to it.
From there the work sorts into three piles. Genuinely new policies go into the pilot ring exactly as a first deployment would, and the ring rollout from [5.1.1] validates them before they widen. Changed policies you have not forked are a straightforward re-deploy of the new version and retirement of the superseded one, minding the by-name duplicate behavior so you replace rather than double. Changed policies you have forked are the only genuinely manual judgment in the whole process: set the upstream change against your reason for forking, decide whether your rationale still holds, and update the fork or leave it deliberately. That decision is yours precisely because it is the one a tool cannot make, and it is small enough to make well because the fork rule kept it isolated.
Where this is heading
The per-policy identifier introduced in v3.8 is the start of making this less manual. It gives each policy a durable identity independent of its name, which is exactly the thing name-based matching has always lacked, and it is what lets tooling eventually tell an updated policy from a new one even when the name itself changed. It is worth knowing the identifier exists and worth preferring the current baseline because of it. It is not worth waiting for, because the operating discipline does not change: pull the compare, read the changelog, ring the new, reconcile your forks.
The baseline that stays valuable is the one that stays current and stays honest about what you changed. The Deployer makes the first part quick, and the compare turns a version bump from an act of faith into an inventory. The fork rule makes the second part possible. Neither removes the quarterly habit of reading a changelog and deciding what your estate should do about it, which is the operating posture this entire phase has been arguing toward. A baseline is not a thing you install. It is a thing you keep.
The OIB Deployer is the work of James Robinson (SkipToTheEndpoint), author of the OpenIntuneBaseline: github.com/SkipToTheEndpoint/OIBDeployer, official instance at deploy.openintunebaseline.com. The instance linked elsewhere on this site is a self-hosted replica of that tool, run for reader convenience only. Release notes and changelog live on the OpenIntuneBaseline releases page.
Intune Deployment Guide · Phase 5: Windows Security Configuration
‹ Previous: [5.1.4] Deploying OIB with the Deployer: Empty Tenant to Green Baseline
Next: [5.2] Configuration Profiles and the OIB Approach ›
