On this page
An employee signs in with the right password and approves MFA. Microsoft 365 still asks for a managed or compliant device. The account sign-in succeeded, but the company also set rules for the computer or phone. Understanding those rules starts with separating device identity, management and access.
.jpg){kind=link}
What each status tells you
| Status | What it tells you | What to check next |
|---|---|---|
| Entra registered | Microsoft Entra recognizes the device alongside a work account | Whether the device is also enrolled in management |
| Entra joined | The device is joined to the organization’s cloud directory | Which management and compliance policies it actually received |
| Entra hybrid joined | The device belongs to an on-premises Active Directory domain and is also joined to Entra | Whether both identities and device management are working |
| Intune enrolled | Intune can manage the device within its platform and policy limits | Which configuration and compliance policies apply |
| Marked compliant | The device has been given a compliant status | Whether the sign-in presented that device identity and the access policy accepted it |
Enrollment, compliance and changes over time
Enrollment gives Intune a way to manage the device. Configuration policies can set requirements, such as how long a screen stays unlocked. Compliance policies evaluate conditions, such as encryption or an approved operating system version. Conditional Access can then require that compliance result for a particular sign-in. A company can have enrolled computers that fail compliance or a joined computer that has never enrolled. In Intune’s default configuration, a device with no compliance policy assigned can be marked compliant. To find out what was actually checked, confirm which policies apply and look at the individual settings. Microsoft documents this in its guide to interpreting compliance reports.
When compliance changes after a device was working
A laptop can start failing a requirement after a policy changes, after its operating system falls behind, or when management has stale information. A user may see the issue only when trying to open an app protected by Conditional Access. Compare the policy assignment and evaluation time with when the user first saw the block. If the device was out for repair or hasn’t been online, ask IT when it last reported and which remediation needs to happen locally.
Intune can schedule actions for noncompliance, including when to mark a device noncompliant. A grace period can give users time to correct certain issues. Have an administrator check the actual assignment and status before telling staff how long they have. See Microsoft’s actions for noncompliance.
How to investigate a blocked sign-in
Start with the application, time, device and any displayed error or correlation ID. Ask which policy blocked the sign-in, what device identity Microsoft received and what the last management check-in reported. A generic “compliant” label in one screen cannot explain which rule applied to a specific attempt.
Read a blocked sign-in from start to finish
| Evidence | What it helps establish |
|---|---|
| Sign-in time and application | Which attempt and resource to investigate |
| Device ID in the sign-in event | Whether the request presented the device IT expected |
| Conditional Access result | Which policy applied and which requirement failed |
| Intune record and last check-in | Whether management has received recent device information |
| Per-setting compliance result | Which requirement needs attention, such as encryption or OS version |
Suppose a bookkeeper can open Outlook on a company laptop but gets blocked in the browser. IT finds the failed sign-in using the time and correlation ID. The log shows that the browser presented the expected device ID and that the policy required a compliant device. In Intune, that same device shows a failed encryption requirement. IT resolves the encryption issue, waits for the device to report its updated state and repeats the browser sign-in. The two things to verify are the updated result for the encryption setting and a successful sign-in under the intended policy.
If the failed attempt had shown no device ID, the next check would be different. IT would first look at whether that browser and sign-in session can identify the device. An empty device field doesn’t tell you whether the laptop is encrypted.
What to test before enforcing compliance
Separate company computers, shared workstations and personal phones when setting expectations. A company laptop may need full device management. A personal phone may only need managed work apps where the platform and policy support that option. Have an IT administrator test representative sign-ins and document the recovery route before enforcing changes broadly.
A representative test covers a company computer, a new hire’s enrollment, a supported personal-device workflow and an expected denial. Include a staff member who uses a browser instead of desktop apps, and someone who works away from the office. Record which apps each person could open and confirm that denied attempts show the intended policy result.
Microsoft supports evaluating Conditional Access policies in report-only mode before enforcement. Use those results alongside real sign-in tests, then enable the policy for a small group with someone available to resolve a block. Give the support desk the rollout window and the expected recovery route. Decide in advance who can authorize an exception and when it expires.