You open Outlook or Teams on your Snapdragon laptop and hit the wall: “You can’t get there from here” — blocked sign-in, or an app demanding a compliant device you apparently lack. Your Intel desktop sails through the same policies. Nothing about the ARM chip is untrustworthy; the device is failing one signal Conditional Access checks, and the error message will not say which.

Conditional Access evaluates signals: device compliance, join state, TPM-backed device health, app protection, location, and risk. On Copilot+ PCs the likeliest failures are compliance items that assumed x64 (required agents, driver versions) and TPM attestation that behaves differently on ARM firmware.

This guide walks the diagnosis in order: reading the actual block reason, fixing compliance failures, repairing device trust, and working with IT on policy-side fixes.

Why this happens

  • Compliance requirements assuming x64: Requiring an x64-only security agent or a driver version with no ARM equivalent marks the Snapdragon device non-compliant while Intel devices pass.
  • TPM attestation fails or times out: Policies requiring healthy attestation can fail on ARM firmware where the first-boot attestation chain is slower — the device is healthy, the signal just did not arrive.
  • Entra-registered instead of Entra-joined: A registered state satisfies fewer CA grants than a full Entra join; user-set-up ARM laptops often land in the weaker state.
  • OS build below the compliance minimum: Compliance policies commonly require a minimum Windows 11 build; inventory-aged ARM laptops fail until updated.
  • Stale device object in Entra ID: A wiped-and-re-enrolled laptop can leave a stale record; CA evaluates the stale record’s signals and blocks the live device.
  • Location or network mismatch: CA policies with named locations or compliant-network requirements block laptops on home Wi-Fi or hotspots exactly as designed — the policy is working, not broken.
  • Risk-based policy reacting to the new device: A brand-new laptop signing in from an unusual location trips sign-in risk; CA blocks or demands MFA the established Intel desktop never sees.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Read the actual block reason instead of guessing

The user-facing message is deliberately vague. The real reason lives in the Entra sign-in log — readable by your IT admin in seconds — or in the Company Portal app. Get the reason before changing anything.

  1. Open the Company Portal app and check device compliance status — it lists exactly which checks pass and fail, in plain language.
  2. Retry the blocked app and screenshot the full error, including the error code (53003 = CA block; 53000-series = device-state issues) — the code tells IT which policy fired.
  3. Ask IT to look up the sign-in in Entra ID > Sign-in logs, filtered by your user and timestamp — the log names the exact CA policy and failed condition.
  4. Note whether the block hits all apps (device-level: compliance or trust) or one app (app-level protection) — this halves the search space.
  5. If the failing signal is device health attestation, continue to Fix 3; if it is a compliance item, continue to Fix 2.

Fix 2: Make the device compliant (the Company Portal checklist)

Most ARM blocks resolve here: the device fails one or two compliance items fixable on-device. Work the Company Portal checklist top to bottom.

  1. In Company Portal, open the non-compliant device’s checklist — address items in order: OS version, encryption, antivirus, required apps.
  2. Update Windows via Settings > Windows Update — install everything pending; the minimum-build requirement is the most common failure on inventory-aged laptops. The Windows 11 download page is the fallback if Update stalls.
  3. Verify encryption: Settings > Privacy & security > Device encryption must be on — ARM laptops sometimes ship with it off.
  4. Confirm Defender is active with current definitions (Windows Security) — a disabled or outdated antimalware state fails the threat-level signal.
  5. If a required app is x64-only and will not install on ARM, report it to IT — the compliance policy needs an ARM exemption (Fix 5’s territory).

Fix 3: Repair device trust, join state, and TPM attestation

When compliance passes but CA still blocks, the problem is device identity or attestation: the device cannot prove what it is. These repairs re-establish trust without wiping.

  1. Run dsregcmd /status elevated and check AzureAdJoined: YES — if NO or only WorkplaceJoined, the CA grant likely needs a full Entra join (Settings > Accounts > Access work or school > Connect).
  2. Check DeviceId matches the object IT sees in Entra ID — on mismatch, IT should delete the stale object so the live one is evaluated.
  3. Clear TPM state: tpm.msc → Clear TPM, reboot, then re-run the Company Portal check — this resolves attestation-timeout blocks on Snapdragon firmware.
  4. Verify Secure Boot is enabled in UEFI — some CA policies require it via the health signal, and it can switch off after firmware updates.
  5. Re-sync Intune (Settings > Accounts > Access work or school > Info > Sync) after each repair so fresh signals reach the compliance engine.

Fix 4: Fix the network, location, and risk signals

Sometimes the device is perfect and the block is contextual: where you are, what network you are on, or how new the device looks to the risk engine. These are the fastest checks here.

  1. If the block mentions location or network, connect via your organization’s VPN — many CA policies grant access only from compliant networks.
  2. Complete any MFA or Terms-of-Use prompt — risk-based policies often grant access after step-up authentication rather than blocking outright.
  3. Avoid rapid sign-in attempts from multiple locations while testing — each attempt feeds the risk engine and can escalate a challenge into a hard block.
  4. If you recently reset the device, give risk signals 24 hours to settle — a fresh device ID plus a new location is the classic false positive, and it decays on its own.
  5. Document each test’s network and location for IT — “blocked on home Wi-Fi, works on VPN” is a diagnosis, not a complaint.

Fix 5: Get IT to fix the policy side (admin actions)

When the device is compliant, joined, attested, and on the right network — and CA still blocks — the policy itself has an ARM-incompatible condition. This is an admin fix; the evidence from Fixes 1-4 makes it actionable.

  1. In the sign-in log, identify the policy and failing grant control — usual culprits: require compliant device with an x64-only item, or require Hybrid Entra joined on a cloud-only fleet.
  2. Check the compliance policy for x64-only assumptions in required apps and versions; create an ARM device group with ARM-native equivalents rather than exempting ARM from security.
  3. For stale device objects: delete the duplicate in Entra ID > Devices so CA evaluates the live record.
  4. Use What If in Conditional Access to simulate the device’s signals — it shows the failing condition without another round of user testing.
  5. As a temporary bridge, IT can scope a time-limited exclusion for affected ARM devices — with an expiry date, not an open-ended hole.

Fix 6: Rule out device-level breakage masquerading as a CA block

A few device problems mimic a Conditional Access block: apps that cannot reach authentication endpoints at all. Confirm the device can talk to Entra before concluding CA is at fault.

  1. Sign in to myapps.microsoft.com in a browser — if the browser flow fails identically, it is CA; if the browser works but the app does not, it is the app’s token cache or installation.
  2. Clear cached credentials via the app’s sign-out/reset first; only use Settings > Accounts > Access work or school > Disconnect with IT guidance.
  3. Update the device’s drivers — authentication and TLS need a healthy network stack, which on ARM means current OEM drivers. Our Qualcomm Adreno driver update guide for ARM covers that hygiene.
  4. Check date, time, and time zone — Kerberos and token validation fail outright on clock skew.
  5. If other AI features misbehave too, isolate platform issues separately — AI Toolkit NPU detection failures in VS Code or trouble exporting Copilot app chats are device-health clues, not CA evidence.

Closing

Conditional Access does not block ARM laptops for being ARM — it blocks a failed signal: compliance, join state, attestation, or context. Read the sign-in log, fix the failing signal, and escalate to IT with the exact policy and condition when the device is clean. The block lifts when the signals turn green.

Frequently asked questions

Why does Conditional Access block my ARM laptop but not my Intel one?
The usual difference is compliance state, not architecture: the ARM device is missing a required compliance policy, its TPM attestation failed, or it enrolled under a different device profile. Conditional Access evaluates signals, and one missing signal blocks the device.
What does 'your device needs to meet compliance' mean?
Intune evaluated the device against your organization’s compliance policy and found it failing — outdated OS build, missing encryption, no antivirus, or a failed health attestation. Open Company Portal to see the exact failing checks.
Can I bypass Conditional Access on my work laptop?
No legitimate bypass exists for users, and attempting one typically violates acceptable-use policy and triggers security alerts. The correct path is making the device compliant or asking IT for a scoped exclusion while you remediate.
Does Conditional Access treat ARM64 devices differently?
The policies themselves are architecture-neutral, but ARM devices trip different signals: TPM attestation timing, driver-based health checks, and app-based compliance (like requiring an x64-only agent) can all fail on ARM while passing on Intel.