JUMP TO SECTIONChoose a lesson section
A green check in one portal isn't the whole story.
Effective endpoint management requires observing several different services, not assuming that enrollment proves security compliance.
Registered, joined and hybrid joined are different states.
Microsoft Entra manages device identities used for sign-in and resource access. Organizational Windows endpoints are commonly Entra joined. Personal devices may be Entra registered. Existing on-premises domain machines may be hybrid joined. None of these labels, by itself, proves Intune management or compliance.
Microsoft Entra registered
Common for personal or BYOD endpoints used with organizational resources. A device identity exists, but the device's primary sign-in isn't necessarily joined to that organization.
An employee adds a work account on a personal laptop.Microsoft Entra joined
An organizational Windows device joined directly to Microsoft Entra. An organizational identity signs in to Windows. Device management may then be provided by Intune.
Northstar's company-owned FIN-LT014 signs into Windows with Alex's company identity.Microsoft Entra hybrid joined
A device joined to on-premises Active Directory and also registered in Microsoft Entra for cloud-aware scenarios. Deployment and policy dependencies differ from cloud-only joining.
An older domain-joined workstation synchronized to Microsoft Entra.Intune enrolled
The endpoint is enrolled into a mobile device management service and can receive assigned policies and applications. Enrollment is distinct from the Entra join type.
FIN-LT014 has a device record and recent management check-in in Intune.For Northstar Services, FIN-LT014 is a company-owned Windows 11 laptop with an Entra device identity. We will treat its join type and Intune management state as separate pieces of evidence throughout the exercises.
Management begins after identity.
Enrollment establishes the MDM relationship needed to deliver supported policies and applications. Windows Autopilot can streamline new-device provisioning, including registration and setup experiences, but Autopilot, Entra join, Intune enrollment and compliance aren't synonyms.
Device identity
The device is represented in Microsoft Entra ID as registered, joined, or hybrid joined.
A joined device is not automatically compliant or fully managed.Management enrollment
The endpoint enrolls into Microsoft Intune (MDM) and receives management authority.
An enrolled device may still have no correctly targeted compliance policy.Policy assignment
Groups and filters determine which configuration, application and compliance policies apply.
A policy that exists in the portal isn't proof it targets this device.Device evaluation
Windows and Intune evaluate required conditions such as encryption, security boot state or supported OS version.
A healthy local setting doesn't always imply the current cloud compliance report has updated.Compliance reporting
Intune reports compliance state to Microsoft Entra following evaluation and service processing.
An Intune compliant status does not independently grant SharePoint permissions.Conditional Access
When scoped, Entra access rules can require the device to be marked compliant before granting access.
Conditional Access is not the same system as Intune compliance evaluation.Configure it. Evaluate it. Decide access.
Deploy or manage a setting.
Configure BitLocker encryption and other baseline settings.
A setting assignment isn't itself proof the endpoint satisfies a separate compliance rule.Evaluate whether the managed device satisfies required conditions.
Require BitLocker, Secure Boot and an approved Windows build.
A policy must apply to the device and its state must be evaluated/reported.Enforce an access decision for a targeted user/resource using signals, including reported device compliance.
Require a device marked compliant for the Finance SharePoint resource.
It doesn't encrypt disks or directly configure the endpoint.Protect organizational data within supported apps, including scenarios without full MDM enrollment.
Require supported app controls for mobile work data.
It isn't interchangeable with a Windows device compliance policy or every CA grant.A configuration policy might enable a required control, but a compliance policy determines whether the relevant conditions are satisfied. Intune then reports device compliance to Entra. A separately scoped Conditional Access policy can require that compliant-device signal before allowing SharePoint access.
Intune has a tenant-wide setting that determines whether unassigned devices are marked compliant or noncompliant. For a conditional-access design relying on compliance, Microsoft's guidance recommends treating devices without an assigned compliance policy as not compliant. Simply missing a policy must not become an unexamined access bypass.
BitLocker, Secure Boot and operating system posture.
Windows compliance policies can evaluate encryption, Secure Boot, supported operating system versions, Defender-related settings and other signals depending on configuration. These requirements aren't one universal Microsoft default; they depend on the organization's explicit policy.
BitLocker
Protects supported Windows storage at rest. Inspect local encryption, key protection and recovery arrangements, then the policy's actual device report.
Secure Boot
Helps ensure trusted components start the operating system. A compliant device must satisfy whatever Secure Boot condition is assigned.
Attestation & reporting
Some Windows device health/compliance signals require a fresh boot-time assessment. Local remediation and cloud reporting may not update simultaneously.
Supported OS
Minimum/maximum versions and security requirements depend on policy, platform support and applicable organization standards.
Our first case models a healthy local BitLocker volume with a stale boot-attestation result. That's an educational simplification of a real troubleshooting pattern: a local state and a reported compliance state can diverge. We won't imply that every BitLocker compliance failure requires rebooting; the exact failing setting and its evidence matter.
What is actually blocking Alex?
Adjust the fictitious device's identity, enrollment, policy and health signals. Watch what Intune can evaluate—and whether a compliant-device Conditional Access rule receives the signal it requires.
Cloud-joined company device
Management channel exists; enrollment ≠ compliance.
Northstar Windows Secure Baseline applies.
Illustrative boot-time attestation is stale.
After an authorized remediation, request check-in and inspect the resulting report; updates aren't instantaneous in real tenants.
Conditional Access requires a reported compliant device.
3 stage(s) lack a satisfied prerequisite. Find the earliest failing stage and inspect that evidence before changing tenant-wide policy.
Illustrative logic: a change does not run real Windows checks, and a toggle doesn't guarantee a real service result. Device policy support varies by platform, assignments and client context. A sync or reboot might be necessary for some real signals, but not all.
Follow the check-in and sign-in evidence.
Check the expected device record, Entra join type and actual signed-in device context.
Confirm Intune enrollment, device owner, last management check-in and enrollment errors.
Inspect compliance policy assignments, filters, exclusions and resulting effective device policies.
Open per-setting status. Is encryption really disabled, or is a reported health signal stale?
Inspect the affected user/resource sign-in and applied grant controls. Check whether the device compliance claim reached Entra.
After authorized remediation and reevaluation, reproduce the original SharePoint workflow and document the outcome.
On supported Windows endpoints, these read-only examples can complement Intune and Entra evidence. They do not replace the admin-center report or justify broad policy changes.
dsregcmd /statusInspect Windows device identity (for example, AzureAdJoined and DomainJoined), registration and relevant SSO diagnostics. Read carefully in the correct user context.
Get-BitLockerVolumeInspect the local BitLocker encryption and protection state. A healthy local volume doesn't alone prove Intune's reported health attestation is current.
Get-TpmCheck TPM status on supported Windows systems. TPM evidence is only one part of device posture.
Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumberRecord the effective Windows version/build before comparing it to the assigned compliance requirement.
Get-MpComputerStatus | Select-Object AMServiceEnabled,AntivirusEnabled,RealTimeProtectionEnabledInspect Defender status when the assigned compliance policy requires those signals; avoid changing protection to pass a check.
Use report-only testing during rollout, a properly scoped emergency-access strategy and approved exception processes. For incidents, diagnose the actual device state, policy assignment and sign-in evidence; do not bypass protections casually.
Can you separate enrollment from access?
01Why is FIN-LT014 Entra joined but noncompliant?
Join is a device identity state; Intune compliance separately evaluates targeted policies and reports results. Inspect enrollment, assignment, per-setting failures and check-in/attestation age.
02Does enrollment automatically assign every compliance policy?
No. Assignments depend on configured groups, filters and exclusions. Tenant-wide settings also govern how devices with no assigned compliance policy are treated.
03What if BitLocker is enabled locally but Intune still reports it as noncompliant?
Confirm which BitLocker setting fails, the device's report and last check-in, and whether health attestation needs an updated boot/evaluation. Some policy signals are measured during startup; don't reflexively decrypt and re-encrypt.
04Does manually syncing guarantee immediate compliance?
No. Sync initiates/requests policy and status processing; device, service and Entra reporting can involve latency. Look at actual timestamps and per-setting evidence.
05Could we temporarily turn off the compliance requirement in Conditional Access?
That changes organization-wide access protection rather than fixing the device. Prefer report-only testing during rollout, targeted diagnosis, and an authorized exception process when necessary. Do not casually disable safeguards.
06Is an Intune app protection policy the same as device enrollment?
No. Mobile application management can apply data protections in supported applications, including some unenrolled-device scenarios. Whether it satisfies a particular access policy depends on platform and policy design.
Verify your deployment details.
This is a fictional learning model, not a Microsoft Intune implementation. Your tenant's licensing, platform support, policy evaluation and sign-in behavior may differ. Consult the current Microsoft documentation before applying production changes.