The settingWhat we hold this to
CreativeTechs minimum
A CA policy in state ENABLED requiring device marked compliant OR Entra hybrid joined. Scope is per client: admins at minimum, then SharePoint and OneDrive, then all cloud apps.
Benchmark position
CISA and Microsoft both treat device compliance as a core Conditional Access grant. No numeric value.
Where we differ, and why
Blocked for us specifically: our Macs are managed in Addigy, not Intune, so nothing currently reports compliance state into Entra. That integration is the prerequisite and it is a project. Until it lands this control cannot be measured on a Mac fleet, and claiming otherwise would be dishonest.
Where the switch is
Entra admin centre → Protection → Conditional Access → Policies → New policy → Grant → Require device to be marked as compliant.
How to verify
Graph: /identity/conditionalAccess/policies → grantControls.builtInControls contains 'compliantDevice'
- Why it matters
- The strongest single control after MFA. It turns a stolen credential into nothing at all without the physical device.
- How we check
- Maester MT.1001, MT.1014.
- Fix — M365
- CA policy → require device marked compliant, or Entra hybrid joined. This is not a checkbox for us — our Macs are managed in Addigy, not Intune, so how device compliance signal reaches Entra is a project in its own right and needs answering before this can be promised to anyone.
- Fix — Google
- Context-Aware Access with endpoint verification.
- User notices
- BYOD, contractors and personal phones stop working until enrolled. That is the point and also the problem.
- Expected pushback
- The big one. Fine for Addigy-managed Macs we already control; it breaks freelancers, contractors and the personal iPhone checking mail. Realistic path: admins first, then SharePoint and OneDrive, then everywhere — or price it per client as the upsell that comes with full device management.
- Reason on file
- Addigy→Entra device compliance signal is a project, not a toggle. Nothing can be promised until that lands.
