Intune compliance policies + Conditional Access integration

image

Most people I speak to think the work of locking down devices in Microsoft 365 is creating the Intune compliance policy. They tick the boxes — BitLocker on, minimum OS, no jailbreaks — hit Save, and walk away feeling secure.

They aren’t.

A compliance policy on its own does precisely nothing to a sign-in. It’s a label. Intune looks at a device, decides “compliant” or “not compliant”, and writes that state back to Entra ID. That’s it. Nothing is blocked. Nothing is challenged. The policy is information, not enforcement.

The enforcement lives somewhere else entirely. It lives in Conditional Access.

If you’re not wiring those two things together, you’ve done half a job. And the half you skipped is the half that actually protects the tenant.

What is an Intune compliance policy, really?

Think of a compliance policy as a health check that runs on the device and ships the verdict back to your tenant. Encrypted? Patched? Joined to your tenant? Defender running? Out comes a true/false, and Entra ID writes it onto the device record.

That verdict is now available as a signal. Anything that can read Entra signals — and Conditional Access is the big one — can use it to make access decisions.

So the compliance policy is the sensor. Conditional Access is the gate. You need both, or you have neither.

Step-by-Step: wiring compliance to Conditional Access

Portal only. No PowerShell. This is what I do on every Business Premium tenant I touch.

Fix the tenant default first

Open the Intune admin center, go to Devices > Compliance > Compliance policy settings.

Find the setting Mark devices with no compliance policy assigned as. It ships set to Compliant.

Change it to Not compliant. Save.

That one setting is the difference between “any device in my tenant counts as good” and “a device has to earn it”. You’d be amazed how many tenants I audit where this is still on the default.

Build the compliance policy

Same portal. Devices > Compliance > Policies > Create policy. Pick Windows 10 and later (start there — do iOS and Android next).

Use the settings catalog options to set sensible rules — require BitLocker, a minimum Windows build, Defender real-time protection on, Defender signatures up to date. Don’t try to be heroic on day one. Set what you can defend with a straight face. Microsoft’s own walkthrough is the canonical reference.

In Actions for noncompliance, do not leave the default of “Mark device noncompliant: 0 days”. Give yourself a grace window — 1 to 3 days — and add a Send email to end user action a day earlier. People deserve a heads-up before they’re locked out of email.

Assign to a pilot user group. Not all users. A pilot group.

Build the Conditional Access policy

Now flip over to the Entra admin center: Entra ID > Conditional Access > Policies > New policy.

Users: include your pilot group. Exclude your break-glass account. Always.

Target resources: All resources.

Grant: Require device to be marked as compliant. Save.

And here’s the critical bit — set Enable policy to Report-only. Not On. Report-only.

Users:       Pilot group
Exclude:     Break-glass account
Resources:   All resources
Grant:       Require device to be marked as compliant
Enable:      Report-only

Notice what’s missing? MFA. That belongs in a separate policy. One policy, one job. Stack them, don’t fuse them.

Watch report-only for a week

Sign-in logs > Report-only tab. You’re looking for users who would have been blocked and shouldn’t have been — usually a missing enrollment, a personal device that needs the App Protection path instead, or a service account.

When the report-only data is clean, flip the toggle to On. Microsoft’s compliant-device CA template walks the same path.

Why this actually changes behaviour

“But MFA is already on. Isn’t that enough?”

It isn’t. MFA proves the user. Compliance + CA proves the device. Token theft doesn’t care about your MFA prompt — it cares whether the device the token landed on is one you trust. This is the bit MFA-only tenants are missing.

It also collapses three messy conversations down to one. “Is this laptop ours? Is it patched? Is it encrypted?” All of it rolls into one signal — compliant, or not. Conditional Access reads that one signal and decides. No more inventory spreadsheets. No more guessing.

And if you’re an MSP, this is the most defensible artefact you can show a client during an incident. The device was non-compliant. Access was blocked. That’s a finished sentence.

A compliance policy isn’t there to make a list of bad devices. It’s there to make sure they never sign in.

Why Being Small Is Your Real Advantage With AI

image

I had a conversation last week with the owner of a twelve-person business who spent the first ten minutes telling me how far behind they were. The big firms in their industry have AI strategies, AI committees, AI roadmaps. He didn’t have any of that. He thought it was a problem.

I told him it was the opposite. The thing he saw as a weakness — being small — is actually the only real advantage he has right now. And he was wasting it by feeling sheepish about it.

The giants are not as far ahead as they look

When you read the announcements from large enterprises about their AI programs, it sounds impressive. The reality on the ground is messier. Inside those organisations there are governance committees, procurement cycles, security reviews, change boards, and three different vendors pitching competing platforms. By the time they finish arguing about which group owns the rollout, eighteen months have gone past.

A small business doesn’t carry that weight. There is no internal committee. There is the owner, the team, and the work. That’s it. Decisions get made on a Tuesday afternoon and acted on by Wednesday morning.

You can turn Copilot on this week

This is where the gap becomes obvious. A small business can switch on Microsoft 365 Copilot for ten people on a Monday and by Friday have someone using it inside Outlook to triage their inbox before lunch, someone else using it in Excel to clean up a messy supplier list that’s been sitting there for two years, and another person catching up on a Teams meeting they missed without watching the recording. None of that requires a steering group. It requires a licence, half an hour of curiosity, and a willingness to have a go.

The big firm down the road is still drafting their pilot scope document. You’re already past the awkward learning phase and into actual benefit.

Pivoting is cheap when there’s nothing in the way

The other thing being small lets you do is change your mind. When a better way of doing something comes along — a new agent in Copilot Studio that automates an approval, a Power Automate flow that handles client onboarding, a smarter way to use SharePoint as a knowledge base — you can swap it in without unwinding a tangle of legacy processes. There’s no 200-page change management plan. There’s a conversation, a test on Thursday, and a rollout next week if it works.

Bigger organisations can’t move like that. Every change touches another change, which touches a third. There’s a process owner who needs to be consulted, a training team that needs to be briefed, an integration that needs to be re-tested. The cost of pivoting goes up sharply the larger you get. For you, that cost is almost nothing — and you should be spending it freely.

Stop trying to look like them

The mistake I see SMB owners making is trying to copy the way big businesses adopt technology. They want a strategy document, a steering committee, a phased rollout plan. They think that’s what serious looks like.

It isn’t. That’s what slow looks like.

Serious, for a small business, is being three steps ahead because you didn’t waste six months talking about it. The bigger players will catch up eventually — they always do. Your job between now and then is to use the head start, not apologise for it. Get Copilot in front of your team, let them break things, and bank the lead while you’ve got it.