Multi-factor authentication proves someone knows the right password and holds the right device at the point of login. It says nothing about whether that device is actually safe to trust with company data. Conditional access closes that gap by checking the device itself, not just the person, before granting access to Microsoft 365. For an Apple fleet, that check runs through DMS (formerly MDM), and it is the difference between a login policy and a genuine access-control system.
What does conditional access actually block that MFA alone doesn’t?
MFA confirms identity. Conditional access adds a second question: is this specific device in a state the business trusts?
The compromised-but-authenticated device scenario
A stolen laptop with a saved session, or a Mac running outdated software with a known vulnerability, can pass MFA perfectly well if the credentials are valid. MFA does not check whether the device itself is encrypted, patched, or free of known compromise; it only checks the person logging in. Conditional access is what catches this specific scenario, refusing access from a device that fails a compliance check even when the login credentials themselves are entirely valid.
Why passwords and MFA alone aren’t enough
Passwords and MFA are necessary but built to answer a narrower question than most businesses assume. They confirm who is logging in. They do not confirm what that person is logging in from, and for a business handling client data, the device matters as much as the identity behind it.
How does device compliance state drive Microsoft 365 access decisions?
Conditional access policies in Microsoft Entra ID make access decisions in real time, based on signals reported by the device itself.
A compliance benchmark feeds the access decision directly
A device is checked against a defined compliance benchmark: disk encryption enabled, operating system patched to a minimum version, no known malware present, security settings intact, and that benchmark can be built around CIS controls, Cyber Essentials requirements, or a baseline tailored to the business. If the device passes, access proceeds. If it fails, Entra ID can block access outright or restrict it, for example, allowing web-only access to email with no local download, rather than a full sign-in.
Choosing which benchmark to build the policy around matters. A CIS-aligned baseline tends to suit businesses wanting a widely recognised technical standard, while a Cyber Essentials-aligned baseline suits businesses already working towards or holding that certification, since the same evidence serves both purposes. A tailored baseline makes sense where a business has specific client contractual requirements that go beyond either standard.
The decision happens before data is exposed, not after
This is the practical distinction from a policy that only reviews access afterwards. Conditional access evaluates compliance state at the moment access is requested, so a non-compliant device is stopped before it reaches company data, not flagged for review once it already has.
Should a login from an unmanaged laptop at 2am be treated the same as one from the office?
Conditional access lets you set rules based on device, location and risk, not just a password. Talk to Dr Logic about getting it configured properly.
What has to be in place before you can turn this on?
Conditional access is not a standalone switch. It depends on two things already being configured correctly.
Device compliance management has to exist first
Before Entra ID can check a device’s compliance state, that state has to be actively tracked somewhere, typically through DMS enrolment feeding Intune, or a dedicated Apple DMS platform integrated with Entra ID. A business with unmanaged, unenrolled Macs has nothing for conditional access to check against, so this is the genuine starting point, not an optional add-on.
Microsoft 365 management needs a baseline first
Conditional access policies sit on top of an already-configured Microsoft 365 tenant, with Entra ID as the identity layer. A business starting from an unmanaged tenant needs that foundation in place, sensible admin role separation, and MFA enforced before conditional access policies have anything reliable to build on.
Sequencing for a business starting from zero
The realistic order is: enrol devices into DMS and establish a compliance baseline, confirm Microsoft 365 tenant security fundamentals are configured correctly, then layer conditional access policies on top, starting with a small pilot group before rolling out business-wide. Attempting conditional access before either foundation exists usually results in either locking out compliant staff by mistake or a policy that cannot actually evaluate anything meaningfully.
Running policies in report-only mode first, before switching them to actively block, is what makes this sequencing safe in practice. Report-only mode shows exactly which devices would have been blocked under a proposed policy without actually blocking anyone, which gives the business a chance to fix genuine compliance gaps, an unpatched device, or a missed enrolment before the policy starts enforcing access decisions for real.
How this differs from Zero Trust as a concept
Zero Trust is the architecture, the principle that no device or user is trusted by default. Conditional access is one of the concrete mechanisms that makes that principle enforceable day-to-day for an Apple fleet using Microsoft 365, checking device compliance state at the exact moment access is requested rather than relying on network location or a one-time login check.
If your Apple fleet is enrolled in DMS but conditional access policies aren’t yet built on top of it, Dr Logic’s cyber security team can sequence the rollout properly, starting with the compliance baseline your business actually needs.
Related articles
- Built secure, not made secure: why your IT strategy must start with zero trust
- Zero trust security: why “never trust, always verify” is the 2025 cyber security mindset
- The MFA and email security shortlist for Microsoft 365 and Google Workspace
FAQs
What is conditional access and how is it different from MFA?
Conditional access checks whether a device meets a defined compliance standard – encryption, patch level, malware-free – before granting access to Microsoft 365. MFA only confirms the identity of the person logging in; conditional access adds a check on the device itself, catching scenarios MFA alone cannot.
Does conditional access work with Apple devices on Microsoft 365?
Yes. Apple device compliance state, tracked through DMS (formerly MDM) enrolment, feeds directly into Microsoft Entra ID’s conditional access decisions, allowing policies to evaluate Mac and iPhone compliance the same way they would a Windows device.
What do I need before I can set up conditional access?
Two things need to exist first: an active device compliance management system tracking your Apple fleet, and a properly configured Microsoft 365 tenant with Entra ID as the identity layer. Conditional access policies build on top of both rather than replacing either.
Can conditional access lock out staff by mistake?
Yes, if rolled out without a defined compliance baseline or without piloting on a small group first. A phased rollout, starting with a pilot group and a clearly defined benchmark, is the standard way to avoid locking out compliant staff during setup.
