Sign In
In this module

AD3.1 Why Device Compliance Is the Third Priority

5-6 hours · Module 3 · Free
Operational Objective
You've deployed MFA and conditional access (Module AD1) and email protection (Module AD2). Identity controls stop 99.9% of credential attacks. Email controls reduce phishing reaching users by 60%+. But there's a gap in the defense: the device itself. A user can pass MFA, receive a clean email, and access corporate data from a laptop with no encryption, an outdated operating system, disabled antivirus, and no firewall — because nothing in your current configuration checks the health of the device. An attacker who steals a session token through an AiTM proxy can replay it from any device — their personal laptop, a VM, a cloud instance — because your conditional access policy CA003 is still in report-only mode. This module activates the device layer: compliance policies that define what a healthy device looks like, and the conditional access enforcement that blocks everything else.
Deliverable: Understanding of why device compliance is the third priority (not first, not last), what it protects against that identity and email controls don't, and the deployment sequence for this module.
Estimated completion: 20 minutes
THE THREE-LAYER DEFENSE — IDENTITY + EMAIL + DEVICE LAYER 1: IDENTITY ✓ MFA + Conditional Access Stops: password-only attacks Deployed in Module AD1 LAYER 2: EMAIL ✓ Safe Links + Attachments + Anti-phish Stops: phishing delivery Deployed in Module AD2 LAYER 3: DEVICE ← Compliance + CA enforcement Stops: unmanaged device access THIS MODULE THE GAP WITHOUT DEVICE COMPLIANCE Attacker captures session token via AiTM → replays from their own device → MFA shows "satisfied by claim" → no device check → full access to Exchange, SharePoint, Teams from an unmanaged laptop Device compliance blocks this: attacker's device isn't enrolled → CA003 denies access → token is useless

Figure AD3.1 — The three-layer defense model. Identity (MFA) stops credential attacks. Email (Safe Links/Attachments) stops phishing delivery. Device compliance stops access from unmanaged or unhealthy devices — including AiTM token replay where the attacker passes MFA but uses their own unmanaged device. Without Layer 3, the attacker has a bypass.

Why device compliance comes third, not first

The ordering is deliberate. Device compliance depends on conditional access for enforcement — you built conditional access in Module AD1. Without CA, compliance policies exist but don't block anything. The blast radius of device compliance is also higher than identity or email controls. MFA affects the login experience (a 5-second prompt). Email protection works in the background (users don't notice Safe Links checking URLs). Device compliance can lock a user out of their email entirely if their device doesn't meet requirements — and unlike a password reset (which takes 5 minutes), fixing a non-compliant device can take hours (OS update, encryption enablement, antivirus installation).

Deploying compliance before identity and email would create maximum user disruption with incomplete protection. Deploying it after identity and email means the highest-impact controls are already in place, and the compliance enforcement adds the device layer without being the only thing standing between the attacker and the data.

The practical consequence: if you had to stop after Module AD1 and never configure device compliance, your environment would still be dramatically more secure than when you started. MFA alone provides 99.9% protection against credential attacks. Device compliance provides the additional protection against the 0.1% of sophisticated attacks (AiTM token replay) and against data loss from stolen or compromised devices. It's important — but it's third priority, not first.

What device compliance actually checks

An Intune compliance policy evaluates the device against a set of requirements every time the device checks in (typically every 8 hours, or on-demand when the user signs in to a conditional access-protected resource). The compliance check is pass/fail — either the device meets every requirement, or it doesn't. There's no partial compliance.

The five checks that matter most for security:

BitLocker encryption. An unencrypted laptop that's lost or stolen exposes every file on the disk — emails cached in Outlook, documents synced from OneDrive, cached credentials, browser passwords. BitLocker encryption ensures the disk is unreadable without the recovery key. This is the most fundamental device security control and the one most frequently missing.

Minimum OS version. An outdated operating system misses security patches that fix known vulnerabilities. An attacker with local access to a device running Windows 10 21H2 (end of support: June 2024) has a library of unpatched exploits to choose from. Setting a minimum OS version ensures devices stay current.

Firewall enabled. The Windows Firewall blocks unsolicited inbound connections. Disabling it (which some users and even some IT teams do to "fix" connectivity issues) exposes the device to network-based attacks when connected to public WiFi, hotel networks, or compromised corporate networks.

Defender Antivirus active and up to date. Defender Antivirus is included with Windows and provides real-time protection against malware. The compliance check verifies that Defender is running, real-time protection is enabled, and signatures are current. A device with disabled antivirus or signatures more than 7 days old is a significantly higher risk.

Require Secure Boot. Secure Boot prevents rootkits and boot-level malware from loading before the operating system starts. It's enabled by default on modern hardware but can be disabled in BIOS settings. The compliance check ensures it stays enabled.

What happens when you enforce compliance

When compliance enforcement is active (CA003 switched from report-only to on), the authentication flow adds a device check. The user signs in, completes MFA, and then conditional access checks the device compliance state in Intune. If the device is compliant, access is granted. If the device is not compliant, the user sees an error page explaining that their device doesn't meet security requirements, with a link to instructions for resolving the issue.

This is where the blast radius hits. Users with non-compliant devices can't access Exchange Online, SharePoint, or Teams until their device is remediated. For a user whose laptop needs a Windows update, that's 30-60 minutes of downtime. For a user whose laptop needs BitLocker encryption enabled, that's 1-2 hours. For a user on a personal device that isn't enrolled in Intune at all, they're locked out until they enroll — or they access data through the browser only (which you can configure as a fallback with app protection policies).

This is why the report-only period is essential. You need to know how many devices would fail compliance BEFORE you enforce. Module AD3.2 covers the audit that gives you this data.

Compliance Myth: "Device compliance is only needed for BYOD — our corporate devices are managed"
"Managed" and "compliant" are different things. A corporate device enrolled in Intune is managed — you can push configurations to it. But if the user has disabled Windows Firewall, turned off real-time protection, or deferred Windows updates for 6 months, the device is managed but not compliant. Compliance policies check the actual security state of the device, not just whether it's enrolled. A managed device with disabled antivirus is more dangerous than an unmanaged device that the user has kept updated — because the managed device has cached corporate credentials and synced corporate data. Compliance enforcement ensures that managed devices actually meet your security standards, not just your management standards.
Decision point

You're about to start building compliance policies. Your Intune enrollment shows 180 of 210 devices enrolled (86%). The 30 unenrolled devices are a mix of personal devices (BYOD) used by 20 employees for email access and 10 older laptops that were never enrolled. How do you handle the unenrolled devices when you enforce compliance via CA003?

Option A: Enforce compliance for enrolled devices only and ignore the 30 unenrolled devices — they'll be blocked by CA003 anyway since they're not compliant.

Option B: Before enforcing CA003, enroll the 10 corporate laptops, create an app protection policy for the 20 BYOD devices that provides browser-only access with restricted download capability, and then enforce CA003.

Option C: Wait until all 210 devices are enrolled before enforcing compliance.

The correct answer is Option B. The 10 unenrolled corporate laptops should be enrolled — they're company-owned and there's no reason not to manage them. The 20 BYOD devices present a different challenge: you can't require personal device enrollment without a BYOD policy and user consent. App protection policies provide a middle ground — the user accesses email through the Outlook mobile app or browser, data is protected within the app container, but the personal device isn't fully enrolled. When CA003 enforces, the corporate laptops (now enrolled + compliant) get full access. The BYOD devices get restricted access through app protection. No users are locked out, and corporate data is protected on every device type.

Try it: Check your enrollment and compliance baseline

Navigate to intune.microsoft.com → Devices → All devices. Note the total count of enrolled devices. Compare this to your total employee count — the difference is your enrollment gap.

Now navigate to Devices → Compliance → Compliance policies. If you see "No compliance policies," your enrolled devices are all "compliant by default" — which means the compliance check has no teeth. Every device passes because there's nothing to check.

Click "Devices → Monitor → Noncompliant devices" (or Devices → Overview). If compliance policies don't exist yet, this shows zero noncompliant devices — not because all devices are healthy, but because nothing has been checked.

Navigate to Devices → All devices → click on any enrolled device. Check the "Device compliance" section. You'll see "No compliance policy assigned" if no policies exist. After you build the compliance policy in AD3.3, this section shows the specific pass/fail for each compliance check.

Record: total devices enrolled, total devices expected, enrollment gap (count and reason), and current compliance policy status (none, basic, or full). This is your device security baseline.

Your conditional access policy CA003 requires a compliant device for Exchange Online, SharePoint, and Teams. An attacker captures a user's session token via AiTM proxy and replays it from a virtual machine they control. The token is valid — MFA was completed during the original session. What happens?
The attacker gets full access because the token has MFA satisfaction — Only if CA003 is still in report-only mode. If CA003 is enforced, the device check blocks access regardless of token validity.
Conditional access checks the device. The attacker's VM isn't enrolled in Intune, so it's not compliant. Access is blocked even though the token has valid MFA — Correct. CA003 evaluates device compliance independently from MFA. The token is valid, MFA is satisfied, but the device isn't enrolled. The compliance check fails. Access is denied. The attacker would need both a valid token AND a managed device — which means physically compromising a corporate laptop, not just phishing credentials.
The attacker is prompted for MFA again because the device is new — No. MFA status is carried in the token ("satisfied by claim"). The attacker isn't re-challenged for MFA. Only the device compliance check blocks them — which is why device compliance matters for AiTM defense.
Defender for Endpoint detects the anomalous device and blocks it — Requires E5 and MDE. Device compliance with CA003 blocks the access without requiring Defender for Endpoint. CA003 checks Intune compliance, not MDE. This works on E3.
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Count enrolled devices by platform
Get-MgDeviceManagementManagedDevice -All |
    Group-Object OperatingSystem |
    Select-Object Name, Count |
    Sort-Object Count -Descending |
    Format-Table
Operational Artifact — Device Security Deployment Sequence

The device compliance deployment follows the same phased approach as identity and email: audit first (AD3.2 — check enrollment gaps and predict non-compliance), then build policies (AD3.3-AD3.4 — Windows, macOS, mobile), then integrate with CA (AD3.5 — move CA003 from report-only to enforced), then handle exceptions (AD3.7-AD3.8). The total deployment takes 2-3 weeks: 1 week for audit and policy building, 1 week in report-only to verify blast radius, then enforcement with grace period. This is Phase 3 of your 10-week security improvement plan from Module AD0.

Verifying your current device management state

Before building compliance policies, confirm what's already in place. Navigate to intune.microsoft.com → Devices → Overview. This dashboard shows your enrolled device count, breakdown by platform, and management status. Note three numbers: total enrolled devices, total users with enrolled devices, and total devices that haven't checked in recently.

Run a quick PowerShell check for your Intune license and enrollment status:

If this returns zero results, Intune enrollment hasn't been deployed — you'll need to configure auto-enrollment through Azure AD Join or Intune enrollment before you can build compliance policies. If it returns results, you have a foundation to build on.

Also check whether CA003 exists from Module AD1. Navigate to entra.microsoft.com → Protection → Conditional Access → Policies. If CA003 (Require Compliant Device) exists in report-only mode, you're ready to add compliance policies that give it teeth. If it doesn't exist yet, build it now in report-only mode targeting Exchange Online, SharePoint Online, and Microsoft Teams — with the grant control "Require device to be marked as compliant." Exclude your break-glass accounts.

Confirming your licensing supports device compliance

Device compliance policies require Intune, which is included in M365 E3, M365 E5, M365 Business Premium, and EMS E3/E5. If you're on a plan that includes Intune, compliance policies are available at no additional cost. If you're on M365 Business Basic or Standard, you'll need to add Intune as a standalone license (Intune Plan 1) or upgrade to Business Premium.

Verify your Intune license is active and assigned. Navigate to admin.microsoft.com → Billing → Licenses. Check that your licence plan includes Intune. Then verify the service plan is enabled: admin.microsoft.com → Users → Active users → select a user → Licenses and apps → expand the license → verify "Microsoft Intune Plan 1" is checked.

If Intune is licensed but no devices are enrolled, you need to configure auto-enrollment. Navigate to entra.microsoft.com → Mobility (MDM and MAM) → Microsoft Intune → MDM user scope → set to "All" (or a specific group). For Azure AD-joined devices, this enables automatic enrollment when the device joins Azure AD. For existing devices already joined to Azure AD, trigger enrollment by navigating on the device to Settings → Accounts → Access work or school → Enroll only in device management.

© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus
← Previous Next →