Skip to main content

Your Tenant Says Every Device Is Compliant. It's Lying.

ยท 5 min read
Fabio van der Burg
Technical Consultant, Nerd

You did everything right. Conditional Access requires a compliant device before anyone touches company data. You tested it, it worked, you closed the ticket, you felt good about yourself. โ˜•

Then one Tuesday you spot a device in the sign-in logs you have never seen before. Personal laptop. No management. No Intune. Nothing. And right next to it, in cheerful little green letters: Compliant.

Wait. What.

The default lie ๐ŸŸขโ€‹

That device passed because it was never actually tested. Out of the box, a device that no compliance policy targets still gets a verdict, and the default verdict is Compliant. Not "unknown". Not "let me check". A confident, green, "yeah, they're fine".

Your require-compliant policy trusts that verdict completely. So the one machine you never enrolled, never hardened, never checked, gets waved straight through like a bored stormtrooper glancing at a speeder:

Move along. These aren't the droids you're looking for.

The compliance engine you so carefully built is only ever as honest as its default answer. And right now the default answer is "sure, come on in".

One switch, told to stop lying ๐Ÿ”€โ€‹

The fix is a single setting: Devices โ†’ Compliance โ†’ Compliance settings โ†’ Mark devices with no compliance policy assigned as โ†’ Not compliant (or secureByDefault, if you speak Graph).

Flip it and "no policy" finally means "not trusted", which is the only reading that lets Conditional Access do the job you hired it for. The full setting, the Graph one-liner and the validity-period details all live on the reference page.

Done. Ship it. Right?

No. Put the keyboard down. This is exactly where people hurt themselves.

The rollout that doesn't page you at 2AM ๐Ÿงฏโ€‹

Here is the trap. If a require-compliant Conditional Access policy is already enforcing, flipping that switch marks every no-policy device Not compliant in the same instant, and locks out every one of their users in the next. In a mature tenant with a long tail of unmanaged devices, that is not hardening. That is a company-wide outage with your name on the change ticket. ๐Ÿ’ฅ

So do it in this order, not the other one:

  1. Configure the setting before you check for it. This is the step everyone skips. A compliance policy is an inspector, not a builder: it verifies a state, it never creates one. So first deploy the thing that actually puts the device into that state, a configuration profile, a Settings Catalog policy, an Endpoint Security disk-encryption profile, or a remediation script. Turn BitLocker on by policy before any rule dares to require it. Skip this and the compliance check just paints the device red and hands the user a setting they have no clue how to enable, and now your "hardening" is a helpdesk queue with a side of angry. ๐Ÿ˜ค
  2. Then assign the compliance policies that check those states, broadly and per platform, so the pool of "no policy assigned" shrinks to almost nothing before you touch the default.
  3. Put the compliance CA in Report-only. Now it evaluates every sign-in and quietly tells you what it would block, without blocking a soul.
  4. Read the blast radius. The sign-in logs show you exactly who would fall over. This is the dress rehearsal, and you do not open on Broadway without one.
  5. Then flip the switch to Not compliant. With the settings enforced, the policies assigned and the CA still in report-only, this catches genuine gaps instead of your entire fleet.
  6. Then enforce the CA. Only once the report-only data is boring do you move it to On.

Skip straight to step 5 with an enforcing policy already live, and congratulations, you have written yourself a Monday-morning incident. Report-only is free. Use it.

Bonus nugget: the expiry date on trust โณโ€‹

While you are in there, glance at Compliance status validity period. The default is 30 days, which is roughly the point where a device that has gone dark for a month stops counting as compliant.

Two quick opinions:

  • Do not crank it to 120 to make noise go away. That is not tuning, that is agreeing to ignore stale devices.
  • Do not drop it below three weeks either, or you will spend every September re-compliancing half the company after the summer holidays. ๐Ÿ–๏ธ

30 is usually the right answer. Just pick it on purpose instead of inheriting it.

Wrap-up โœ…โ€‹

Your tenant is holding out the blue pill: everything's green, everyone's compliant, go back to sleep. ๐Ÿ’Š This one setting is the red pill. Flip the default from "sure" to "prove it", stage it behind report-only so the only devices that face-plant are the ones that were fibbing anyway, and you finally get to see the fleet as it actually is instead of as the dashboard wishes it were.

Is it a little less comfortable? Sure. But a green checkmark you can't trust is just a screensaver for your anxiety, and "we assumed it was fine" is not a sentence you want to be reading aloud in an incident review. ๐Ÿ˜ฌ

Prove it. Don't assume it. And never trust a device that grades its own homework. ๐Ÿ›ก๏ธ