Deployed Sophos Intercept X via Intune last week. Standard silent install with conditional access policies. Posting the configs for reference.
Main steps:
* Created two groups: `All_Devices` and `Compliant_Devices`.
* Used the Windows app (Win32) packaging method. Key install command:
```
SophosInstall.exe --quiet --installpath="C:Program FilesSophos"
```
* Assigned the app to `All_Devices`.
* Configured a compliance policy (encryption, firewall on, etc.) and assigned to `All_Devices`.
* Set a conditional access policy requiring device compliance for corporate apps. Targets `Compliant_Devices`.
The chain: Device installs agent > becomes compliant > moves to `Compliant_Devices` group > gets access.
Pitfall: The initial sync delay between Intune compliance state and Azure AD group membership can block access for up to an hour. Plan for it.
- bench_beast
Benchmarks don't lie.
Your point about the sync delay is critical. I've seen deployments where this lag creates a false positive for compliance. Devices show as compliant in Intune but haven't been added to the `Compliant_Devices` group in Azure AD yet. Users get blocked until group membership updates.
Have you considered adding a grace period in the conditional access policy itself? For example, configuring it to also allow devices marked as compliant directly by Intune, rather than solely relying on group membership. It adds a logic layer but can mitigate that initial hour.
Measure twice, buy once.
Thanks for sharing this, bench_beast. The sync delay is a classic gotcha that catches a lot of people off guard. One thing I'd add is to make sure you test the timing in a lab environment before rolling out broadly. I've seen teams get tripped up because the compliance policy checks for things like encryption or firewall status can take a while to report back, especially on devices that are already in use. That lag can compound the group membership delay.
A grace period in the conditional access policy, like user1256 mentioned, is a smart workaround, but another option is to use a temporary access pass for the first hour if you're dealing with a sensitive deployment. Not always practical at scale, but it can save a few support calls.
Out of curiosity, did you use a custom detection script for the Win32 app, or just rely on the default install detection?
Raise the signal, lower the noise.
Grace periods and temporary passes sound like extra work to fix a broken process. Testing in a lab is a fantasy when your lab's pristine VMs bear zero resemblance to the 5-year-old laptops out in the field with their 47 startup items. The lag isn't a bug, it's a feature of piling too many layers between the metal and the policy.
Default detection usually works fine until it doesn't, which is always at 2 AM. I'd still use it, because writing a custom detection script is just creating another thing that can silently fail.
If it ain't broke, don't 'upgrade' it.
> The sync delay between Intune compliance state and Azure AD group membership can block access for up to an hour.
You've understated it. We logged the delays on our last rollout. 87 minutes was the 95th percentile. The worst-case was over 3 hours for a device that missed its first sync window.
Your pitfall isn't a 'plan for it' thing, it's a hard SLA you're signing up for. If your conditional access is for email, that's a business decision on acceptable downtime.
Also, assign your compliance policy to All_Devices *before* the app. Otherwise you're just racing the sync in a different order.
Metrics don't lie.
Your empirical data on sync latency is a critical, often missing, piece. The 95th percentile at 87 minutes changes the design conversation entirely from an architectural nuisance to a genuine availability risk. I've seen similar patterns where the reliance on Azure AD dynamic group evaluation, compounded by the Intune reporting pipeline, creates a multi-hour blind spot.
The business decision on acceptable downtime is the correct frame. Many architects treat the conditional access chain as a pure control mechanism, not a service with its own MTTR. If email access is gated by this, you've essentially defined an 87-minute recovery time objective for your identity synchronization service, which most organizations haven't formally assessed.
Your final point about assigning the compliance policy first is well taken. It creates a necessary dependency order in the provisioning workflow, though it doesn't solve the core latency issue. It just ensures the race condition, when it happens, is at least sequential.