Lesson 38 — Microsoft Entra Conditional Access Device Conditions
Microsoft Entra Conditional Access can evaluate the device used during a sign-in and use that information to make access decisions.
Device conditions can identify the operating system, determine whether the device is registered, joined or hybrid joined, check whether Microsoft Intune reports it as compliant and apply device filters to target specific hardware or ownership scenarios.
This lesson explains device identity, platform conditions, compliance, join state, managed and unmanaged access, BYOD design, browser behaviour, device filters, troubleshooting and the Zero Trust principle that device trust must be continuously validated.
What you will learn
This lesson explains how device identity, compliance, join state and platform signals strengthen Conditional Access decisions.
Learning objectives
After completing this lesson, you should be able to design and troubleshoot device-based Conditional Access controls.
- Explain why device identity matters.
- Evaluate supported device platforms.
- Distinguish compliance from join state.
- Compare registered, joined and hybrid joined devices.
- Use device filters for granular targeting.
- Protect access from unmanaged and BYOD devices.
- Investigate device-condition failures.
- Apply Zero Trust device principles.
The problem this solves
A valid username and password do not reveal whether the requesting device is managed, patched, encrypted or known to the organisation.
Device conditions allow Conditional Access to require stronger assurance before sensitive resources are opened.
Device evaluation flow
Why devices matter
Compromised credentials are less useful when access also requires a known and healthy device.
Device signals help reduce risk from unmanaged laptops, personal devices, stale endpoints and unsupported platforms.
Conditional Access is not device management
Conditional Access consumes device information but does not configure antivirus, encryption, patching or firewall settings.
Those controls normally come from Microsoft Intune or another supported management platform.
Core device signals
| Signal | What it represents | Typical policy use |
|---|---|---|
| Device platform | Windows, macOS, Linux, iOS or Android | Platform-specific controls and unsupported-platform blocking |
| Compliance | Whether the management service reports the device as compliant | Require compliant device |
| Join state | Registered, Microsoft Entra joined or hybrid joined | Require organisational device identity |
| Device filter | Rules based on device properties | Include or exclude precise device populations |
| Ownership and management | Corporate or personal context | Different controls for managed and BYOD access |
Device platforms
Conditional Access can target common endpoint platforms including Windows, macOS, Linux, iOS and Android.
Platform detection should be treated as one signal because user-agent information can be imperfect or manipulated.
Unknown platforms
Some clients may not report a recognisable platform.
Policies should define how unknown and unsupported platforms are handled rather than assuming every request will be classified correctly.
Platform policy design
| Design choice | Benefit | Caution |
|---|---|---|
| Include all platforms | Broad baseline protection | Requires careful exclusions and testing |
| Target one platform | Supports platform-specific controls | Other platforms require separate coverage |
| Block unsupported platforms | Reduces unmanaged access paths | Legacy and service clients may be affected |
| Require compliance by platform | Aligns controls with management capability | Compliance availability differs by platform |
Device compliance
A compliant device is one that currently satisfies the compliance policies reported by the device-management service.
Examples can include encryption, password, operating-system version and threat-protection requirements.
Compliance is time-sensitive
Compliance can change when a device falls behind on updates, disables protection, stops checking in or is rebuilt.
Conditional Access evaluates the available compliance state at sign-in time.
Compliance workflow
Microsoft Entra registered
Registered devices are commonly personal or BYOD devices associated with a user account.
Registration provides device identity but does not automatically mean the device is compliant or corporate owned.
Microsoft Entra joined
Microsoft Entra joined devices are organisational devices joined directly to Microsoft Entra.
They can support cloud-native management, authentication and Conditional Access scenarios.
Hybrid Microsoft Entra joined
Hybrid joined devices are joined to on-premises Active Directory and registered with Microsoft Entra.
They support organisations that retain domain-joined endpoint requirements while using cloud identity controls.
Registered versus joined versus hybrid joined
| State | Typical ownership | Identity relationship | Common use |
|---|---|---|---|
| Registered | Personal or BYOD | Associated with a user | Work access from a personal device |
| Microsoft Entra joined | Corporate | Joined directly to Microsoft Entra | Cloud-native organisational endpoints |
| Hybrid joined | Corporate | On-premises AD joined and Microsoft Entra registered | Hybrid identity environments |
Join state is not compliance
A joined device can still be unhealthy or non-compliant.
A compliant registered device may satisfy some access requirements without being fully corporate joined.
Require compliant device
This grant control requires the current device identity to be reported as compliant.
It is effective for protecting sensitive resources when users should access them only from managed endpoints.
Require hybrid joined device
This control requires a hybrid Microsoft Entra joined endpoint.
It can support established domain-device requirements but should not be confused with a health or compliance check.
Combined requirements
Policies can require multiple controls depending on how grant-control logic is configured.
For example, an organisation may require both MFA and a compliant device for privileged applications.
Managed versus unmanaged access
| Device type | Available assurance | Typical access approach |
|---|---|---|
| Managed and compliant | Device identity plus current management state | Full access where policy permits |
| Managed but non-compliant | Known device with failed health requirements | Block or direct to remediation |
| Registered BYOD | Known user-device association | Limited or application-protected access |
| Unmanaged | Little or no device assurance | Block, restrict download or allow limited browser access |
| Unknown device | No usable device identity | Apply the least-trusted access path |
BYOD considerations
Personal devices may be acceptable for selected browser or mobile scenarios but inappropriate for unrestricted file access.
Define which applications, data types and session actions are permitted from BYOD devices.
Browser access
Browser sessions may provide less device context than modern applications, especially when the device is not registered.
Session controls can help restrict downloads or enforce application-proxy behaviour where supported.
Mobile applications
Mobile access can combine device compliance with approved client applications and application-protection policies.
The correct design depends on whether the device is fully managed or only the organisational data is protected.
BYOD decision flow
Device filters
Device filters allow Conditional Access to include or exclude devices by supported properties.
They provide more granular control than broad platform or join-state conditions.
Filter use cases
- Target corporate-owned devices.
- Exclude approved kiosk devices.
- Apply controls to a specific trust type.
- Separate supported and unsupported hardware populations.
- Stage a policy for a known device group.
Filters versus user groups
User groups target people; device filters target the endpoint represented during sign-in.
Use the correct object type so the policy reflects the intended control boundary.
Device filter processing
Stale device objects
Rebuilds, re-enrolments and replacements can create multiple device objects for one physical endpoint.
Administrators must verify which object the current sign-in is actually using.
Token and registration timing
New device registration or compliance state may not appear instantly in every session.
Testing should account for sign-in refresh, device check-in and token acquisition.
Unsupported clients
Legacy authentication and some clients cannot provide modern device claims reliably.
Block legacy authentication and validate each supported client path.
Common policy designs
- Require compliant device for sensitive cloud applications.
- Require MFA and compliance for administrators.
- Block unmanaged device access to high-value resources.
- Permit limited browser access from BYOD devices.
- Apply device filters to specialised endpoints.
- Block unsupported device platforms.
Agent Foskett investigation: “The compliant device wasn't compliant.”
Investigation evidence
- User Sign-in Logs
- Conditional Access policy result
- Device ID and object ID
- Join and registration state
- Compliance state and check-in time
- Operating system and client application
- Intune device record
- Authentication and token details
Troubleshooting workflow
Operational warning signs
- Multiple objects exist for the same physical device.
- Compliance records are stale.
- Users rely on old browser sessions.
- Device filters have no owner or documentation.
- BYOD receives unrestricted download access.
- Privileged access accepts unmanaged devices.
- Unsupported clients bypass the intended path.
Device-condition review checklist
| Review area | Question | Evidence |
|---|---|---|
| Platform scope | Are all supported and unsupported platforms covered? | Policy inventory and sign-in data |
| Compliance | Are compliance policies current and meaningful? | Intune compliance configuration |
| Join state | Is join state being used for the correct purpose? | Device architecture and policy design |
| BYOD | Is personal-device access appropriately limited? | Application and session controls |
| Filters | Are device filters documented and tested? | Filter expressions and change records |
| Stale objects | Are duplicate and inactive devices removed? | Device inventory and lifecycle reports |
| Troubleshooting | Can support teams trace the sign-in device ID? | Runbook and Sign-in Logs |
Common mistakes
- Assuming joined automatically means compliant.
- Looking at the wrong device record.
- Ignoring browser and client differences.
- Using platform detection as a strong security boundary.
- Allowing unmanaged devices to download sensitive data.
- Creating filters without lifecycle ownership.
- Testing without fresh sign-in tokens.
Best practices
- Combine identity, MFA and device assurance.
- Require compliance for sensitive resources.
- Separate corporate, BYOD and unmanaged access.
- Use device filters for precise, documented exceptions.
- Block legacy authentication.
- Review stale device objects regularly.
- Test every supported client and platform.
Key takeaways
- Device conditions are a core Zero Trust signal.
- Conditional Access consumes device information but does not manage the device.
- Compliance and join state are different concepts.
- Registered, joined and hybrid joined devices support different scenarios.
- Managed and compliant devices provide stronger assurance than unmanaged endpoints.
- BYOD access should be intentionally limited and protected.
- Device filters provide granular targeting based on device properties.
- Browser, mobile and desktop clients can present different device context.
- Investigations must follow the exact device ID used in the sign-in.
- Zero Trust continuously validates device identity and health.
Related Agent Foskett resources
Continue learning
Microsoft Entra Conditional Access Device Conditions
Microsoft Entra Conditional Access Device Conditions evaluate device platform, compliance, join state, registration and filter rules when deciding whether users can access organisational applications and data.
Microsoft Entra Academy Lesson 38 — Conditional Access Device Conditions
This Agent Foskett lesson explains managed and unmanaged devices, Microsoft Entra registered, joined and hybrid joined endpoints, Intune compliance, device filters, BYOD access, browser behaviour and device-condition troubleshooting.
