Microsoft 365 Baseline Conformance: Compare Settings, Not Names

Here is a scenario every Intune admin has lived through. You have a golden baseline. You roll it out to a tenant. Months later you rename your policies to a cleaner convention, split one big policy into a few focused ones, or rebuild the set entirely. Then you run a comparison to confirm the tenant is still aligned, and the report screams that a hundred things changed.

TL;DR: Most Microsoft 365 configuration comparison tools match policies by name, so renaming or reorganizing a baseline produces dozens of phantom "changes" that bury the real ones. Baseline conformance compares the actual settings inside your policies instead of their names, so a setting that simply moved reads as a match and only genuine differences surface.

Why name-based config comparison lies to you

We saw this recently. A tenant rebuilt its baseline under a new naming convention. The settings inside were essentially the same, but the policy names had changed completely. A name-based comparison reported 108 changes: dozens of policies "deleted", dozens "added". Almost none of it was real. The Bitlocker configuration was still there, doing the same thing, under a new name.

That is the core problem with most configuration comparison: it matches policies by name. Rename a policy, move a setting into a different policy, or reorganize your baseline, and the tool loses the thread. It cannot tell "this setting moved" apart from "this setting disappeared and a new one appeared." So it reports noise, you stop trusting it, and the genuinely important change hiding in the list gets buried.

Compare settings, not policy names

Implora's baseline conformance takes a different approach. Instead of pairing policies by name, it reduces every policy on each side to its underlying settings and their values, then compares those. Names and grouping become irrelevant. A setting that simply moved to a differently named policy reads as a Match. A setting that was actually turned off or changed reads as a finding. Those 108 phantom changes collapse down to the handful of settings that genuinely differ.

This is a deliberately different question from drift detection. Configuration drift answers "did what I deployed change?" and is anchored to the policies you pushed. Conformance answers "is this tenant actually configured to our standard, however it got there?" That distinction matters most for the tenants you did not build yourself, where the policy names and structure are whatever the previous admin chose.

How baseline conformance works in practice

You pick a reference to measure against. That can be one or more of your configuration packages (your curated standard), or another tenant: a known-good golden tenant, or simply tenant A versus tenant B. The subject is always a live tenant, captured fresh at run time.

Implora reduces both sides to their settings across Settings Catalog, Compliance, App Protection, Conditional Access, and device configuration profiles, then reports each setting as one of:

• Match - present with the same value.
• Different - present on both sides, but the values differ.
• Missing - the reference defines it, the tenant does not have it anywhere.
• Conflict - one side sets the same setting more than once with different values (worth a look, often intentional, like staggered update rings).
• Extra - the tenant configures something the reference does not mention.

You get an overall conformance percentage and a per-workload breakdown, so you can see at a glance whether the gap is in compliance, in Conditional Access, or in device configuration. You can drill in three ways: by setting, by reference policy, or by assignment group. Every finding traces back to the exact policies that set it, on both sides, so a "Conflict" is never a mystery. You can see which policy holds which value.

From report to action

The deterministic comparison is the source of truth, and you can export it to Excel for a full audit trail. When you want to hand something to a stakeholder, generate the report as a Word document, with or without an AI-written summary that calls out the high-impact gaps in plain language. And because the whole comparison is grounded in real settings, you can ask Lora, Implora's assistant, questions like "what is this tenant missing against our baseline?" and get answers from the actual data, not a guess.

Where it fits

Reach for baseline conformance when you are onboarding a tenant and need to know how far it sits from your standard, when you want to validate a tenant against a golden baseline no matter how its policies are named, or when you want to compare two tenants setting by setting. It is read-only, pure analysis with no changes pushed, so it is safe to run against any tenant, any time. For tenants you deployed yourself and want to watch over time, pair it with configuration drift detection.

Names change. Baselines get reorganized. Your conformance report should not care.

Frequently Asked Questions

Does running a conformance check change my tenant?

No. Baseline conformance is read-only. It captures the tenant's current configuration and compares it to your reference. Nothing is written back, so it is safe to run against production tenants at any time.

How often should I run baseline conformance?

Run it at onboarding to establish the gap, then periodically and before audits to confirm a tenant still matches your standard. For continuous change tracking on tenants you deployed to, configuration drift detection is the better fit.