Device Compliance and Endpoint Posture Guide

A valid password and MFA prompt say nothing about whether the device asking for access is encrypted, patched, monitored or even owned by your organisation. Device compliance and endpoint posture checks close that gap by making the state of the device part of every access decision. Done well, they stop stolen credentials working from an attacker's laptop and keep unhealthy devices away from sensitive data. Done badly, they create false confidence: default settings that mark unmanaged devices compliant, self-reported signals that malware can fake, and exclusion lists that grow until the policy protects little. This guide covers posture signals and how far to trust them, managed versus unmanaged and BYOD devices, compliance policy design, device health attestation, posture-based access and a staged rollout. It is written for endpoint, identity and zero trust practitioners.

Key takeaways

• Compliance is a verdict, posture is the evidence. A compliance policy turns signals such as OS build, encryption and EDR risk into a pass or fail that access policies consume; weak signals give a weak verdict.
• Attested signals beat self-reported ones. RFC 5209 puts "lying endpoints" out of scope, so prefer hardware-backed attestation such as Windows Device Health Attestation or Apple Managed Device Attestation for high-value access.
• Fix the defaults before you enforce. In Intune, devices with no compliance policy are marked compliant by default, and compliance status stays valid for 30 days unless you change it.
• Not every device needs to be managed, but every device needs a decision. Give BYOD and contractor devices app-level or browser-level controls rather than either full access or none.
• Posture checks run at sign-in; tokens outlive them. Session cookies stolen from a compliant device can be replayed elsewhere, so pair posture with token protection and short sessions.

Compliance, posture and device trust

• Posture: RFC 5209 (Network Endpoint Assessment) defines it as the "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy". Examples are OS version, disk encryption, firewall state and EDR health.
• Compliance: the result of evaluating posture against a policy. In Microsoft Intune, Google endpoint management or Jamf, this becomes a flag on the device record.
• Device identity: a directory object that lets the access system recognise the device at all. Microsoft Entra ID offers three ways to get one: registration (BYOD and mobile), join (organisation-owned Windows) and hybrid join, which Microsoft calls "an interim step on the road to Microsoft Entra join". Entra states that devices "must be registered in Microsoft Entra ID before they can be marked as compliant".
• Posture-based access: the policy decision that combines user identity, authentication strength and device compliance. NIST SP 800-207 rejects implicit trust based on network location or asset ownership and requires authentication and authorisation of "both subject and device" before a session.

Device certificates, TPM-backed keys and IoT device identity are covered in the Device and IoT Identity Guide. This guide focuses on assessing the health of user endpoints and using it in access decisions.

Posture signals and how far to trust them

The NCSC describes device health as "compliance with device configuration policies and device state", and recommends monitoring health signals continuously. Not all signals are equal: some come from hardware measurement at boot, others from an agent that malware with administrator rights can tamper with.

RFC 5209 is explicit that detecting or handling lying endpoints is out of scope for network endpoint assessment, and that a compliant endpoint may still be vulnerable. Apple lists "a compromised device lying about its properties" as the first threat Managed Device Attestation prevents. That is the difference between asking a device how healthy it is and having hardware prove it.

Managed, unmanaged and BYOD devices

Microsoft's "Require approved client app" grant was due to retire in early March 2026; new Conditional Access policies should use "Require app protection policy", which is generally available on iOS and Android and in preview for Microsoft Edge on Windows. See the Mobile Device Security Guide.

Building a compliance policy

Start with tenant-wide settings, because they decide what happens to devices no policy covers.

• Mark devices with no compliance policy assigned as: defaults to Compliant, which Microsoft describes as "This security feature is off". Set it to Not compliant once every platform in use has a policy.
• Compliance status validity period (days): default 30, range 1 to 120. A device that stops checking in keeps its compliant status until this expires, so shorten it for high-risk estates.
• Actions for noncompliance: every policy marks the device noncompliant by default. Add user notification, then remote lock or retire after a grace period, and agree that grace period with HR and the service desk.

The Australian Signals Directorate's Blueprint for Secure Cloud publishes an as-built Windows 10/11 compliance policy that makes a useful reference baseline:

Intune re-evaluates through the Intune Management Extension on a schedule and, for key Windows settings, in near real time when a change is detected, with throttling when many changes occur. The ASD notes its values are a baseline, not a prescription; adjust them to your operating context.

Device health attestation

• Windows: Intune uses the Device Health Attestation service to confirm devices "boot to a trusted state". Require code integrity "detects if an unsigned driver or system file is being loaded into the kernel".
• Apple: Managed Device Attestation (iOS 16, iPadOS 16.1, macOS 14, tvOS 16 or later, on A11 or later and Apple silicon) provides a Secure Enclave-backed declaration of properties such as serial number, UDID and sepOS version. An MDM server requests it with a DevicePropertiesAttestation query; including a DeviceAttestationNonce forces a fresh attestation, limited to one per device every seven days.
• Attested certificates: with ACME, a certificate authority can request attestation during enrolment so the device certificate's private key is generated in the Secure Enclave and bound to genuine hardware. That makes the device credential itself much harder to copy to another machine.
• Network access control: the NEA model in RFC 5209 (posture collectors and validators exchanging attributes over the PA, PB and PT protocols) describes the same pattern as Trusted Network Connect and other network admission control architectures it cites. Network posture checks still help on campus networks, but cloud applications reached over the internet need identity-layer checks as well.

The NCSC describes attestation as "taking a snapshot of the state of a device"; treat it as point-in-time evidence and combine it with continuous EDR signals.

Posture-based access policies

• Baseline: require a compliant or hybrid joined device for all cloud apps for workforce users on Windows and macOS, and app protection on mobile.
• Admin portals: require a compliant device and phishing-resistant authentication strength together for directory, cloud console and device management admin roles. See the Zero Trust Identity Guide.
• Platform gaps: block unknown or unsupported device platforms rather than letting them fall through. Entra's compliant device control supports Windows 10 and later, iOS, Android, macOS and Linux Ubuntu, and treats Microsoft Edge InPrivate on Windows as noncompliant.
• Risk-driven tightening: feed the EDR risk score into compliance so a device with active high-severity threats loses access automatically.
• Google Workspace: Context-Aware Access builds access levels from attributes such as encryption, minimum OS version and company ownership; desktop device policies need Endpoint Verification, and only licensed editions enforce them.

Where identity fits

Every device record is an identity, and attackers treat it as one.

• Device registration as persistence: MITRE ATT&CK T1098.005 (Account Manipulation: Device Registration) describes adversaries registering a device or virtual machine to Entra ID and Intune to get past conditional access, with APT29 and Scattered Spider among the procedure examples. Require MFA to register devices, block enrolment for inactive accounts and use a temporary access pass for first enrolment.
• Session theft after the check: T1539 (Steal Web Session Cookie) bypasses posture entirely once a cookie leaves a compliant device. In the CircleCI breach, malware on an employee's laptop stole an SSO session that was already authenticated. See the Token and Session Security Guide.
• The management plane is tier 0: whoever controls the MDM controls every device. In the Stryker attack, one hijacked admin account used Intune to wipe tens of thousands of devices. Protect MDM admin roles like domain admin, with multi-admin approval for wipe and bulk actions where the platform supports it.
• Managed device, unmanaged profile: in the Okta support system breach, a service account credential ended up in a personal Google profile. Control browser profiles and sync on managed devices, not just the device itself.

Rolling out posture-based access

1. Measure coverage: compare directory sign-ins against enrolled devices to find who would be blocked. Fix enrolment gaps before writing any access policy.
2. Deploy compliance policies without enforcement: assign policies per platform with only the default "mark noncompliant" action and watch the compliance report for two to four weeks.
3. Change tenant defaults: once every platform has a policy, set unassigned devices to Not compliant and shorten the validity period.
4. Run access policies in report-only mode: Entra logs each result as Report-only: Success, Failure, User action required or Not applied. Exclude macOS, iOS and Android from report-only compliant-device policies, because Microsoft warns they can prompt users for certificates repeatedly.
5. Publish a remediation path: the NCSC asks that "legitimate users are given a defined and clear path to bring their devices to good cyber health". Link the block page to self-service fixes.
6. Enforce in rings: IT and security staff first, then a pilot business unit, then everyone, with admin portals enforced early because the population is small.
7. Keep break-glass accounts excluded and monitored. See the Break-Glass Account Guide.
8. Roll back cleanly: if enforcement blocks legitimate users, switch the policy back to report-only or off rather than deleting it, and keep a documented emergency exclusion group that is reviewed weekly.

Choosing an approach

Small organisations should take one platform's built-in compliance and conditional access end to end before adding signals. Large organisations need per-platform policies, an owner for exclusions and change control on compliance settings, because a single toggle can open or block the whole workforce.

Detection and measurement

• Sign-in logs: record device ID, compliance state, management state and join type for every sign-in; alert on successful access from unmanaged devices to apps that should require compliance.
• Device registration events: MITRE detection DET0036 covers suspicious device registration through Entra ID or MFA platforms; alert on registrations from new locations or for dormant accounts.
• Compliance changes: watch for devices flipping from compliant to noncompliant on antivirus, firewall or risk score, which can indicate tampering (T1685).
• Admin activity: log and alert on changes to compliance policies, tenant compliance settings, exclusion groups and bulk wipe or retire actions.

Metrics:

• Percentage of workforce sign-ins from compliant or app-protected devices (target above 98%).
• Number of users and devices in Conditional Access exclusion groups, and their age.
• Median time for a noncompliant device to return to compliance.
• Percentage of devices on an OS build within your supported range.
• Percentage of privileged sessions from attested, compliant devices (target 100%).
• Device registrations not linked to an onboarding or replacement ticket.

Framework mapping

Common failure patterns

• Leaving the default: devices with no compliance policy count as compliant, so a new platform or unassigned group passes every check.
• Self-reported health treated as proof: antivirus "on" from an agent that malware can stop; use attestation and EDR risk for sensitive access.
• Exclusion creep: executives, service desks and legacy apps added to exclusion groups and never removed, until the exclusions are the attack path.
• Unprotected device registration: anyone with a password can register a device and inherit device-based trust (T1098.005).
• Ignoring the session: the device was compliant at sign-in, but the stolen cookie is used from elsewhere, as in the CircleCI breach.
• Blocking BYOD with no alternative: users forward email to personal accounts instead, which removes all control.

Practitioner checklist

• Set "Mark devices with no compliance policy assigned as" to Not compliant once all platforms have policies.
• Shorten the compliance status validity period from 30 days to match your risk.
• Require BitLocker, Secure Boot, code integrity and an OS build range on Windows; review the minimum build monthly.
• Connect EDR risk to compliance, with a maximum of Medium, or Low for privileged users.
• Use attested devices and device-bound credentials for admin and other high-assurance roles.
• Give BYOD and contractors app protection, enterprise browser or virtual desktop access instead of a block.
• Require MFA for device registration and alert on registrations for dormant accounts.
• Test every access policy in report-only mode and roll out in rings with a published remediation path.
• Protect MDM admin roles as tier 0 and require approval for bulk wipe.
• Review exclusion groups monthly and report sign-ins from noncompliant devices.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• IETF: RFC 5209 Network Endpoint Assessment (NEA): Overview and Requirements
• NCSC: Zero trust principle 3, assess user behaviour, service and device health
• ASD: Blueprint for Secure Cloud, Windows 10/11 compliance policy
• MITRE ATT&CK: T1098.005 Account Manipulation: Device Registration
• Microsoft Learn: Conditional Access grant controls
• Microsoft Learn: Conditional Access report-only mode
• Apple: Managed Device Attestation

Related NHI Mgmt Group resources: Zero Trust Identity Guide · Device and IoT Identity Guide · Mobile Device Security Guide · Endpoint Security Guide · Token and Session Security Guide