Intune and endpoints
Why is this laptop blocked? Intune compliance and access
Toggle a laptop's encryption, antivirus and firewall, and watch compliance decide whether it gets in.
- Intermediate
- About 35 minutes
- Portal and command line
- Simulation + real-world
- Published 26 October 2026
The scenario
Alex's company laptop can't open Outlook: the device "doesn't meet requirements". The cause is a chain: a compliance policy checks the device, Intune marks it, and Conditional Access reads the mark. Break one link and access fails.
At a glance
Before you start
- The Conditional Access lab, or equivalent understanding of grant controls
- For the real-world part, a test tenant with Intune and a test Windows device you can enrol and change
- Requiring a compliant device in Conditional Access needs Microsoft Entra ID P1
Tools
Microsoft Intune admin centerCompany Portaldsregcmd /statusMicrosoft Entra sign-in logs
You'll be able to
You can trace a "device not compliant" block back to the exact failing setting, and you know where to look on the device and in the admin centre.
Try it
Browser simulation. Runs entirely in your browser. Nothing connects to real systems.
Simulated tenant with six example policies. A simplified model of how Conditional Access decides; it never connects to Microsoft services.
Result
Access blocked
Blocked by CA003. A single failing policy is enough to block, whatever the others say.
- Sign-in status
- Failure
- Conditional Access
- Failure
Policies in this tenant
Change a policy's state to see report-only mode in action: it is evaluated and logged, but never enforced.
- CA001Block legacy authenticationAll users, all apps, legacy clientsNot appliedClient is a browser or modern app
- CA002Require MFA outside the officeAll users, all apps, except trusted locationsSuccessSign-in is from an untrusted location. Satisfied: multifactor authentication.
- CA003Require a compliant device for Microsoft 365Staff and admins, Outlook and SharePointFailureStaff or admin opening a Microsoft 365 app. Device is marked not compliant.
- CA004Protect admin portalsAdmins, Azure portalNot appliedOnly admins are in scope
- CA005Block high-risk sign-insAll users, all apps, high sign-in risk. Risk conditions need Microsoft Entra ID P2.Report-only: Not appliedSign-in risk is none
- CA006Guests always use MFAGuests, all appsNot appliedUser is not a guest
The chain behind “this device doesn’t meet requirements”
- A compliance policy in Intune defines what “healthy” means: for example, BitLocker on, a minimum OS version, antivirus running, firewall on.
- The device checks in with Intune and reports its state against each setting.
- Intune sets a compliance status on the device, and that status is shared with Microsoft Entra ID.
- A Conditional Access policy with the grant control “Require device to be marked as compliant” reads that status at sign-in.
The simulation above starts with BitLocker off, so the laptop is not compliant and CA003 blocks Outlook. Turn BitLocker on and watch the decision change.
Things to notice in the simulation
- Not enrolled is not the same as not compliant. A device Intune doesn’t manage has no compliance status at all, so it can never satisfy “require a compliant device”.
- The check-in matters. Intune has a tenant-wide compliance status validity period. A device that stops checking in for longer than that period is treated as not compliant, even if nothing about it changed.
- Location and MFA are separate questions. Fixing compliance satisfies CA003, but CA002 can still require MFA from outside the office.
On a real device
Is the device joined and registered?
On the Windows device, open a terminal and run:
dsregcmd /status
In the output, AzureAdJoined : YES shows the device is joined to Microsoft Entra ID, and the DeviceId identifies its device object. A device that isn’t joined or registered can’t present a compliance state at sign-in.
What does Intune think?
In the Microsoft Intune admin center, go to Devices, find the device, and open its Device compliance view. You will see each assigned compliance policy and, inside it, the state of every setting. This is where “Not compliant” turns into “BitLocker: Not compliant”.
Make the device check in now
After fixing a setting, the device must report again before its status changes:
- In the Company Portal app, open the device and choose Check status (or Check access).
- Or in Windows Settings, go to Accounts > Access work or school, select the work account, choose Info, then Sync.
Some changes need more than a sync. Enabling BitLocker, for example, only completes after encryption has finished, and the next check-in reports it.
Confirm in the sign-in log
Open the user’s failed sign-in in Microsoft Entra sign-in logs. The Conditional Access tab shows which policy failed, and the device details show whether the device was compliant and managed at that moment.
Portal labels move occasionally. If a menu isn’t where this lab says, search the admin centre for the setting name.
Expected result
You can explain the full chain from compliance policy to access decision, toggle the simulated laptop from blocked to allowed by fixing only the failing setting, and list the three places to check on a real device: dsregcmd /status, the device’s compliance view in Intune, and the sign-in log.
Further reading
- Device compliance policies in Microsoft Intune (Microsoft Learn)
- What is Conditional Access? (Microsoft Learn)
Key lessons
- Access depends on a chain: compliance policy, device check-in, compliance status, then Conditional Access.
- An unenrolled device has no compliance status, so it can never satisfy "require a compliant device".
- After fixing a setting, the device must check in again before access changes.
Keep going
Read a sign-in like an admin: Conditional Access decisions
Change who signs in, from where and on what device, and watch six policies decide. Then read the same decision in a real sign-in log.