Microsoft Intune Device Not Compliant: Diagnose and Fix Common Compliance Errors

A Windows laptop says “This device does not meet your organization’s compliance requirements” and blocks Teams, Outlook, VPN, or other work apps. The machine may be enrolled in Microsoft Intune, yet the Company Portal reports that the device is not compliant. Repeatedly signing in rarely fixes the underlying problem: compliance reflects a combination of organization-specific security rules, device reporting, and Microsoft Entra Conditional Access policies.

This guide starts with user-safe actions, then walks Microsoft 365 administrators through compliant and noncompliant states, stale check-ins, missing policy assignments, BitLocker, Defender, Windows Update, security baselines, and reporting conflicts. Do not disable encryption, antivirus or Conditional Access just to make the status turn green. The purpose of compliance is to ensure a device meets your organization’s security requirements.

Best first action: Open Company Portal, inspect the specific failed requirements, correct them, select Check access or Check status, and trigger a device sync. If you manage the tenant, inspect the individual failed compliance setting before changing policies. Microsoft documents these actions in the Windows Company Portal guide.

What “not compliant” means — and what it does not mean

Intune uses compliance policies to evaluate settings such as operating system version, encryption, passwords, device threat levels or other platform controls. Those results may be consumed by Microsoft Entra Conditional Access, which can deny access to protected resources. A device may be enrolled and managed but still noncompliant. Conversely, an app sign-in problem might originate in a different policy altogether.

Microsoft explains how Intune compliance policies interact with Conditional Access. The organization ultimately defines acceptable settings; internet-wide “universal fixes” cannot replace the local policy.

End-user fix: check which requirement failed

1. Open the Company Portal application on Windows 11 and sign in using the assigned work or school account.
2. Open Devices, select the affected device and choose Check access.
3. Read the reported failed settings. Note whether the problem names encryption, Windows Update, firewall, password, antivirus, or configuration.
4. Select any How to resolve or Resolve links shown for the failed check.
5. After fixing the requirement, run Check access again and allow time for cloud reporting and sign-in tokens to refresh.
6. If your organization requires admin approval, contact its support team rather than bypassing the requirement.

If you cannot install Company Portal, visit portal.manage.microsoft.com using the work account, open Devices, select the device and request Check status. Microsoft’s Company Portal website instructions identify possible results, including “Can access,” “Out of compliance,” and “Cannot access company resources.”

Force a legitimate device sync on Windows 11

A fresh sync can collect current policies after a network outage or when a device has been off for days; it does not make a device compliant if it still fails the rule.

1. In Company Portal, go to Settings → Sync.
2. Alternatively, open Windows Settings → Accounts → Access work or school, select the managed account, choose Info, and use Sync where available.
3. Wait for sync completion; avoid restarting repeatedly while the enrollment services are working.
4. Run Check access and inspect the new result.
5. If the result is unchanged, record the time of the sync and the exact failed requirement for IT.

Microsoft provides official Windows sync methods. On managed endpoints, menu names and permissions can differ. Do not disconnect the work account or unenroll a corporate laptop to force a fresh start.

Fix failure: BitLocker or encryption requirement

Confirm encryption state without turning it off

On an authorized Windows 11 system, open Settings → Privacy & security → Device encryption when that control is available, or check Manage BitLocker on supported editions. An administrator can inspect the state from an elevated terminal:

manage-bde -status C:

Look at protection and conversion state, not merely whether a padlock icon appears in File Explorer. If encryption is disabled but required, follow the organization’s enrollment and key-escrow process. Before enabling BitLocker, confirm that the recovery key is backed up to the required managed location. On a laptop owned by your company, escalate if encryption controls are inaccessible or recovery key escrow has failed.

Encryption active but Intune still says noncompliant

This is a reporting diagnosis, not proof that BitLocker should be disabled and re-enabled. Trigger a device sync, confirm the device matches the correct Intune record, inspect encryption policy deployment, and look for conflicting encryption configuration profiles. Administrators should validate whether the compliance result reflects a stale state or a missing encryption prerequisite.

Fix failure: Windows update level or minimum OS version

Open Settings → Windows Update and install updates approved by the organization. Reboot only after saving work, and verify the installed build with winver. Corporate PCs may use Windows Update for Business, an update ring, or deployment deferrals, so absence of an offered update may be intentional.

If the compliance requirement demands a build the device cannot currently install, report the conflict to IT instead of installing unsupported preview builds. Administrators should compare minimum and maximum OS fields against rollout schedules, servicing channels and assigned groups. A device can be fully updated for its approved channel and still fail a misaligned policy.

Fix failure: Microsoft Defender, firewall or device health

If the report identifies antivirus, antimalware, firewall or a minimum risk score, inspect Windows Security status and any managed endpoint protection dashboard. Do not uninstall endpoint security to make the check disappear. For Microsoft Defender for Endpoint integrations, confirm the device is onboarded, reporting successfully and within the permitted threat level defined by the policy.

If an alternative antivirus product is deployed, IT must ensure the organization’s policy and device detection agree with that product’s presence. Users should not edit registry settings to spoof protection results.

Fix failure: password, PIN or lock-screen rules

Company Portal may require a stronger device password, supported PIN, screen lock or minimum inactivity timeout. Read the exact requirement and follow the provided remediation link. Avoid disabling Windows Hello for Business without IT guidance: this can conflict with identity or device enrollment policy. On shared kiosks or specialized devices, a policy targeted to the wrong device class may be the real issue.

For administrators: establish one authoritative device record

At Microsoft Intune admin center, locate the device under Devices, verify its serial number, management name, operating system and primary user, and compare the displayed last check-in with the actual machine. Duplicate Entra registrations or old Intune records after a rebuild may lead support staff to troubleshoot the wrong device.

Record the device ID, associated user, current compliance state, last check-in, and assigned compliance policies. Inspect each policy’s per-setting results rather than changing the entire tenant policy based on a single red badge.

Evaluate “No compliance policies assigned” correctly

Intune has a tenant-wide setting controlling how devices without an assigned compliance policy are treated. Microsoft documents the “Mark devices with no compliance policy assigned as” option and warns that the default may treat unassigned devices as compliant. When Conditional Access relies on compliance, administrators should deliberately choose an appropriately secure tenant configuration and assign policies to the intended devices.

A temporary change to treat unassigned devices as compliant merely to restore access can weaken your security design. Instead confirm group inclusion, exclusions, platform targeting, filters and any assignment conflicts. Read the official overview of compliance policy settings before changing tenant-wide behavior.

Investigate assignment and configuration conflicts

A device can receive multiple applicable compliance policies. Administrators should compare the failing setting across all policies and validate policy scope and filters. If one policy requires one minimum OS version and another requires a newer version, the device must meet the relevant evaluations; selecting only the easiest policy is not a remedy.

Useful questions: Did the user move between security groups? Was a compliance policy recently edited? Does the configuration policy actually enforce the setting compliance expects? Has the device received a custom compliance script? Has the compliance policy been scoped to a platform that matches the device? Document any planned changes and test on a pilot group before broader deployment.

Conditional Access says device not compliant despite a green Intune status

This scenario requires checking both Intune and Microsoft Entra. Confirm that the sign-in came from the expected device, with a current token and the intended work account. In Entra sign-in logs, inspect the exact Conditional Access policies evaluated and the reported failure reason. Conditions such as client app, device platform or grant controls can explain the denial.

Do not simply exclude all users from Conditional Access. If you have an emergency access design, follow the documented organization’s break-glass workflow and log the exception. Microsoft’s Conditional Access troubleshooting guidance outlines how scope and targeting influence enforcement.

Stale check-in and compliance validity period

The compliance system uses a validity period to determine whether a device has reported recently enough. Microsoft notes a 30-day default validity setting that administrators can change. A laptop unused during vacation may have an old compliance state until it reconnects, syncs and reports. A device online but failing authentication may remain stale despite frequent manual checks.

Avoid promising an exact number of minutes for every synchronization or Conditional Access change. Tenant health, network conditions and Microsoft service timing affect propagation. Use current timestamps and logs rather than repeatedly re-enrolling a device.

Common compliance problems and safe next steps

Gather diagnostic evidence without exposing secrets

For IT tickets, capture the device ID, tenant, time, error text, Company Portal status, last sync time, relevant policy name and Windows build. Use screenshots that obscure personal information. Never copy BitLocker recovery keys, access tokens, passwords or account secrets into public support forums. Microsoft provides an Intune troubleshooting pane for reviewing user and device states.

Where administrators collect MDM event logs, keep the collection within approved management processes. A basic Windows version check is non-destructive:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber

The output reports OS properties only; it does not prove device compliance by itself. Platform-specific remediation requires the actual failing check.

Risky “fixes” to avoid

• Do not turn off BitLocker, Microsoft Defender or firewall protections just to pass a security check.
• Do not delete the enrolled device object, wipe the laptop or leave Microsoft Entra ID without an IT-approved recovery plan.
• Do not remove conditional access controls globally for one user experiencing an endpoint problem.
• Do not deploy random scripts that force device registration state or manipulate compliance reporting.
• Do not ignore ransomware or high-risk device alerts; security incident response can take precedence over access restoration.

When to contact IT and what to request

For an employer-managed device, IT should confirm which exact policy failed, why, and whether the device is checking in. Ask whether the block originated with Conditional Access or an app-specific permission, and whether there is an approved remediation path. IT may need to correct policy assignment, reapply managed settings, or investigate enrollment, but those steps should be performed through supported administrative procedures.

Verification after remediation

After implementing a documented change, run Company Portal Check access, confirm the relevant per-setting policy shows compliant in the admin center, then test the original protected resource. Check a new sign-in log entry rather than relying on an earlier failed attempt. Keep the fix recorded so future policy changes don’t recreate the problem.

Advanced Intune compliance investigations for IT teams

Scenario: BitLocker shows “On” locally, but the policy fails

Check whether the policy requires more than the mere presence of encryption. Different compliance and endpoint security controls may expect particular protection and recovery information. Confirm the intended encryption settings, device’s policy assignment, successful escrow of required recovery data and recent MDM check-in. Compare the state against a known-compliant device of the same configuration. If the device recently re-enrolled, be certain the old device object isn’t being read by the help desk. Avoid suspending protection or decrypting the drive just to force a report; changing security state can introduce real risk without resolving reporting.

Scenario: An employee’s laptop is blocked after annual leave

An offline computer may have missed synchronization and compliance reporting. Open Company Portal, connect to approved networking, run Sync, and check access. If the device was assigned a new Windows version requirement during absence, the update may also be necessary. Admins should review the last check-in, compliance validity period and whether a Conditional Access token still reflects an earlier state. A single sync often needs time to propagate through cloud services; document timestamps rather than insisting that the result appear instantly.

Scenario: Windows Update says “You’re up to date” but compliance requires a newer build

The device may be subject to an update ring, safeguard hold, organizational rollout schedule or hardware eligibility constraint. Identify the exact OS build required by the policy and the current winver result. Compare them with the deployment ring actually assigned to that device. If policy and deployment are inconsistent, change them through controlled IT review; do not tell end users to install unsupported pre-release Windows builds. The conflict can be between two legitimate administrative settings rather than a broken laptop.

Scenario: Teams and Outlook deny access, but Company Portal says compliant

Compliance is only one component of the identity decision. Open the corresponding Microsoft Entra sign-in log and inspect the Conditional Access policy applied to the failed event. Determine whether device filters, authentication strength, app conditions, location, client version or token age explain the block. Compare the object identity reported in sign-in logs with the Intune device record. Excluding the user from all Conditional Access policies would hide the symptom while creating an avoidable access-control gap.

Scenario: Company Portal reports no compliance policy

Determine whether the user and device fall within expected group assignments. Check device filters, operating system applicability, excluded groups, scope and whether the tenant’s “no policy assigned” setting is intentionally configured. If a pilot policy was deleted, restore an appropriate evaluated configuration rather than marking all no-policy devices as compliant. Device registration alone is not proof that a useful policy has been deployed.

Separate device health, compliance and configuration status

Three dashboards can describe the same device differently because they measure different things. Device health concerns active threats and operational status. Compliance evaluates the specific rules targeted to the device. Configuration profile status reports delivery and application of individual management settings. A policy can fail to configure an option while the device currently complies with the desired outcome; the reverse can also occur if configuration reported success but the current setting drifted later.

A good incident ticket records each result separately. For example, “Endpoint security healthy, compliance failed minimum OS, configuration policy successful, Conditional Access blocked” is much more actionable than “Intune broken.” This distinction also prevents administrators from reinstalling endpoint protection when the real problem is a minimum build requirement.

Microsoft Intune grace periods and enforcement design

Microsoft supports scheduled actions for noncompliance, including marking a device noncompliant and sending user communications. A grace period can help employees remediate an issue before access is affected, but not every risk warrants the same grace period. If a critical threat has been detected, immediate enforcement may be intentional. Review the policy and action schedule as part of the organization’s security design; avoid changing it in response to one support case without authorization.

Use email notifications that explain the exact action a user can take, where support is available and when enforcement will occur. Poorly written notifications drive unnecessary tickets and unsafe attempts to bypass protection. These settings should be managed centrally and reviewed with security stakeholders.

Evidence collection and escalation matrix

Device enrollment problems: when not to start over

Re-enrollment can change device identifiers, certificate state, work-app configuration, and managed data access. It may also erase corporate data when combined with management actions. For that reason, a clean enrollment should be a last-stage IT-controlled remedy after collecting logs, checking assignment, sync, identity and service health. A user who simply removes a work account to make a warning vanish may lose access to their applications and make recovery harder.

If an administrator decides re-enrollment is required, prepare a documented checklist: validate local business data and encryption recovery, confirm the tenant’s enrollment permissions and restrictions, capture the current device identifiers, plan application redeployment, and verify Conditional Access after the new registration. Treat device wipe and retirement as distinct, high-impact operations requiring approval.

Windows, macOS and mobile differences matter

Do not assume a Windows-specific Device Encryption setting exists on Android or iOS. Android work profiles, macOS management, iOS device passcodes and platform-specific compliance checks have separate enrollment and user interfaces. Company Portal’s precise remediation instructions are generally more reliable than generic cross-platform advice. If a user reports a compliance failure on mobile, gather that platform and enrollment type before offering instructions.

Post-incident improvements that prevent repeat tickets

After resolving a compliance incident, identify whether the root cause was an endpoint defect, an accidental policy mismatch, stale reporting, or a user who lacked clear instructions. Update the organization’s knowledge base with the specific verified remediation. Consider alerting IT to sudden spikes in noncompliant devices following policy changes or Windows updates. Where possible, test new compliance requirements in a pilot ring before expanding them. This keeps security strong while reducing avoidable disruptions.

Custom compliance scripts and reporting failures

Some organizations deploy custom compliance settings rather than using only built-in rules. If a device fails a custom policy, confirm the discovery script ran successfully, returned the expected JSON and used supported schema fields. A script that fails execution or returns unexpected content may produce an evaluation problem even when the underlying configuration looks correct. Review the official policy’s result details, and validate the script on a test machine under the intended execution context. Avoid modifying production policy logic based on one user’s anecdotal observation.

When troubleshooting a custom check, separate script execution, parsed output, policy evaluation and Conditional Access enforcement. Each step can fail independently. Document the output of controlled tests without including credentials, recovery keys or security-sensitive inventory. Microsoft’s custom compliance settings guidance provides platform-specific troubleshooting paths and notes that users can trigger Company Portal checks after correcting custom compliance issues.

Company Portal says compliant but a device object is stale

Intune and Entra can show identifiers that look similar, particularly after hardware replacement or Windows reinstallation. Verify device registration IDs, join state, primary user, last check-in and record creation time. An old object can remain in the admin center while a new enrollment represents the actual laptop. Don’t delete the older object during an incident without verifying dependencies and retention rules. Confirm which device ID is present in the most recent sign-in event and which record receives compliance reports.

Special considerations for BYOD and personal devices

A personally owned device enrolled for work may use a different management profile from an organization-owned laptop. Ask what data and settings the company is permitted to manage. Remediation might include a supported device passcode change or app protection configuration, but it should not involve corporate staff casually erasing the user’s personal files. Any proposed retire, wipe or enrollment reset must account for ownership, backups, employee consent and policy.

Users should understand that compliance access denial doesn’t necessarily mean their device is infected. It can reflect a perfectly legitimate policy, such as a higher OS requirement or encryption state, or a stale reporting signal. Explain the exact failed rule and the approved next action rather than telling employees to “reset the device.”

Build a repeatable compliance support playbook

A durable help-desk workflow asks the same questions in order: is the device enrolled; does Company Portal show the specific failed setting; has it recently synced; does the admin center display a matching device record; is there an applicable compliance policy; what does the latest Entra sign-in log say; and is the problem caused by an actual unsafe configuration or an evaluation mismatch? This sequence minimizes unnecessary endpoint changes.

If several hundred devices become noncompliant within minutes of a new policy deployment, stop individualized re-enrollment attempts and inspect the policy scope and deployment history. If one device fails after losing network access, treat it as an isolated endpoint investigation first. Incident scope should shape the response.

Final acceptance test for compliance restoration

An incident is resolved only when the relevant device satisfies the exact failed policy and the intended business resource works again. After remediation, sync from Company Portal, confirm updated compliance on the device and in the admin center, then inspect a fresh Microsoft Entra sign-in event. Have the affected employee open the originally blocked application. If access still fails despite green compliance, continue identity-policy diagnosis rather than repeating the same encryption or Windows Update steps. Preserve the evidence in the support record and identify how the organization can prevent recurrence.

Official sources and documentation

• Microsoft Learn — Intune device compliance overview
• Microsoft Learn — Create compliance policies
• Microsoft Learn — Company Portal: Check access for Windows
• Microsoft Learn — Sync enrolled Windows devices
• Microsoft Learn — Company Portal website status
• Microsoft Learn — Troubleshoot Intune Conditional Access
• Microsoft Learn — Actions for noncompliance

Editorial note: This independent troubleshooting article does not replace your organization’s security or device-management policies. Reviewed October 16, 2026.