CAA50021: The Admin Checklist (2026 Updated Guide)

Quick answer

CAA50021 is not a password problem, a network problem, or a cache problem — and no amount of clearing browser cookies or signing the user out and back in will fix it. CAA50021 is a device-registration failure between Windows and Microsoft Entra ID. The user’s device is failing to acquire (or is missing) the Primary Refresh Token that proves it’s a known, registered, compliant device on your tenant. The fix is on the device-state and Conditional Access side, not the identity side. The fastest way to confirm the actual cause is to run dsregcmd /status on the affected machine and read four specific lines.

Before you start

You’ll need at least the Conditional Access Administrator or Cloud Device Administrator role in Microsoft Entra to make changes. To diagnose, the Reports Reader role is enough. You’ll also need either physical or remote access to the affected user’s Windows device — most of the diagnosis happens there, not in your admin centre.

This is a Windows-specific error code in practice. CAA50021 can theoretically appear on any Microsoft Entra-aware client, but ~98% of real cases are Windows 10 or Windows 11 devices that have a broken or missing Entra device-registration state. macOS and mobile equivalents look different.

If you’re running an entirely cloud-only tenant with no Conditional Access requiring device compliance or hybrid join, you cannot meaningfully experience CAA50021 — there’s no policy enforcing the failed condition. If your users are getting CAA50021, you have a Conditional Access policy somewhere that requires a registered, compliant, or joined device. Knowing which policy is the first move.

What CAA50021 actually is

The “CAA” prefix refers to Continuous Access Authentication (technically Continuous Access Evaluation in current Microsoft terminology), which is the framework Entra uses to keep token decisions current. The 50021 sub-code specifically means the device’s MS-Organization-Access certificate could not be validated, or the device is not in a state that satisfies the policy that’s being evaluated.

Translated: there’s a Conditional Access policy on your tenant requiring “device must be hybrid-joined”, “device must be compliant”, or “device must be Entra-joined”, and the device the user is signing in from doesn’t satisfy it. Either the device isn’t actually registered, or it was registered and the certificate has been corrupted, expired, or deleted.

The user-side troubleshooting articles for CAA50021 will tell users to clear cookies and try again. That advice is wrong. The token-side state is fine; the device-side state is the problem, and only an admin can resolve it.

For the end-user-facing version of this error and what users themselves can try, see Microsoft 365 Error CAA50021.

The five-line diagnosis

Every CAA50021 case starts the same way. Get on the user’s affected Windows device, open Command Prompt as the user (not as administrator — this matters), and run:

dsregcmd /status

Read four specific lines from the output:

  1. AzureAdJoined — should be YES if you’re an Entra-joined tenant; YES or NO depending on join model if you’re hybrid.
  2. DomainJoined — YES if hybrid-joined to on-prem AD; NO if cloud-only.
  3. AzureAdPrt — should be YES. This is the line that almost always tells you what’s wrong. If it’s NO, the device cannot satisfy any Conditional Access policy that depends on device state, and CAA50021 will fire on every authentication.
  4. WamDefaultGUID and WamDefaultAuthority — should both be populated. If empty, the Web Account Manager isn’t initialised properly and Entra integration is broken at the OS level.

The most common state we see on real CAA50021 cases is AzureAdJoined: YES and AzureAdPrt: NO. The device thinks it’s joined, but it can’t acquire the Primary Refresh Token that proves it. The MS-Organization-Access certificate has gone stale, the device record in Entra has been deleted, or both.

The six causes, in likelihood order

Once you have the dsregcmd output, the cause is almost always one of these:

Cause 1: The device record was deleted in Entra ID, but still exists on the device

This happens when an admin (sometimes you, sometimes a colleague) deleted the device from Entra ID → Devices → All devices as part of cleanup or offboarding, but the user’s machine never received the deletion. The device’s MS-Organization-Access certificate still exists in Local Computer\Personal\Certificates, the device thinks it’s registered, but Entra has no record of it and rejects every token request.

Fix: On the user’s device, open certlm.msc (Local Computer Certificates), navigate to Personal → Certificates, find the certificate issued by MS-Organization-Access, and delete it. Then run dsregcmd /leave from an elevated command prompt, reboot, and have the user sign in again. The device will re-register cleanly. (If you’re hybrid-joined, the scheduled task Microsoft\Windows\Workplace Join\Automatic-Device-Join will re-register on next sign-in.)

Cause 2: Conditional Access requires “compliant device” but the device isn’t compliant in Intune

If your tenant uses Intune or another MDM and you have a Conditional Access policy granting access only to compliant devices, the device must be both enrolled in Intune AND meeting all your compliance policy rules. A device that’s enrolled but failing compliance (out of date, not encrypted, missing antivirus signal, whatever your policy checks) will fail Conditional Access with CAA50021 even if the user’s identity is fine.

Fix: In Intune → Devices → All devices, find the device. Check its compliance state. If it’s Non-compliant, click in to see the failed rule. The most common ones are: Windows version below your minimum, BitLocker not enabled, Windows Defender real-time protection off, or device hasn’t checked in recently.

Cause 3: The device was Workplace-Joined or Entra-Registered but not properly Joined

Microsoft has three different “device states”: Entra-Joined (cloud-only domain-equivalent), Hybrid-Joined (registered to both on-prem AD and Entra), and Entra-Registered (BYOD personal device with limited integration). They are not interchangeable. If your Conditional Access policy says “require Entra-Joined device” and the user’s machine is Entra-Registered, every sign-in will fail CAA50021.

Fix: Decide whether the device is supposed to be Joined or Registered, and either enrol it properly (dsregcmd /join for cloud-only Entra Join is not a supported command — you go through Settings → Accounts → Access work or school → Connect → Join this device to Microsoft Entra) or relax the Conditional Access policy to accept Registered devices for that user/scenario.

Cause 4: Hybrid-join is broken because Entra Connect isn’t syncing computer objects

Hybrid join requires that the on-prem AD computer object syncs up to Entra. If your Entra Connect Sync rules don’t include the Computer object class, or if the computer is in an OU that’s excluded from sync, the device will register on the on-prem side but never appear in Entra ID. CAA50021 fires forever.

Fix: This is an Entra Connect configuration issue. Check that the OU containing the computer is included in your sync scope. Check the Synchronization Service Manager for sync errors specifically on Computer objects. The Microsoft Learn article on Configure hybrid Microsoft Entra join covers the configuration in detail.

Cause 5: The MS-Organization-Access certificate is corrupted or expired

The MS-Organization-Access certificate has a 10-year default lifetime, so genuine expiry is rare. Corruption is more common — usually after a Windows feature update, a third-party certificate-cleaning utility (don’t run those), or a profile migration tool. If dsregcmd /status shows AzureAdJoined: YES but AzureAdPrt: NO and there’s no other obvious cause, certificate state is the suspect.

Fix: Same as Cause 1 — delete the certificate from the certificate store, run dsregcmd /leave (admin), reboot, sign in again to re-register. This is the nuclear option that fixes a wide range of state-corruption issues.

Cause 6: A new Conditional Access policy was deployed that the existing device fleet doesn’t meet

Less a “cause” than a self-inflicted wound. Someone deploys a new CA policy requiring (say) a compliance state that the existing fleet hasn’t been brought up to yet, and Monday morning suddenly half the company can’t sign in. CAA50021 across a sudden cohort of users at the same time is the signature.

Fix: Roll back the policy, or — better — create a phased rollout. Conditional Access supports report-only mode and group-scoped enforcement for exactly this reason. Use them.

The Conditional Access audit step

Before doing anything else on a CAA50021 case, find the actual policy that’s blocking the sign-in. Don’t guess.

  • Go to Entra admin centre → Identity → Monitoring & health → Sign-in logs.
  • Filter by the affected username and Status = Failure.
  • Open the failed event.
  • Click the Conditional Access tab inside the event.

Every Conditional Access policy that was evaluated for the sign-in will be listed, with Result: Success or Result: Failure. The one showing Failure is your policy. Click into it to see exactly which Grant control failed (Require compliant device, Require hybrid join, Require multifactor authentication, etc.).

This is the difference between fixing CAA50021 in 15 minutes and chasing the wrong cause for two hours. Always read the sign-in log before changing anything.

When the cause is “the user has a brand-new laptop”

The most common scenario for fresh CAA50021 reports is exactly this: a new user, or an existing user with a new device, hasn’t been enrolled in Intune yet (or hasn’t completed the Autopilot flow yet), and they’re trying to sign in to Microsoft 365 before the device’s enrolment finishes. The device is in a transient state where it knows it’s supposed to be managed but isn’t yet, and Conditional Access is enforcing a state it can’t yet meet.

Fix: Either complete the enrolment (Autopilot, manual Intune enrolment via Settings → Accounts → Access work or school → Connect, or whatever your provisioning flow is) before expecting Microsoft 365 sign-in to work, or grant the user a Temporary Access Pass that bypasses device-state requirements for a limited window. Don’t disable the Conditional Access policy.

Fleet-wide CAA50021: when it’s not one user

If CAA50021 starts firing for a sudden cohort of users on the same morning, you almost certainly have one of three things going on, and the diagnosis path is different from the single-user case.

A new Conditional Access policy was deployed. Check Entra → Conditional Access → Policies and sort by date modified. Anything new or recently modified that requires device compliance, hybrid join, or app-enforced restrictions is your suspect. Roll the policy back to report-only mode while you investigate, or scope it to a pilot group rather than All Users.

An Intune compliance policy was tightened. Compliance policy changes propagate quietly. If you raised the minimum Windows version, or changed a “warn” rule to a “block” rule, the entire fleet that doesn’t meet the new bar will start failing CAA50021 the next time their compliance state re-evaluates. Check Intune → Devices → Compliance policies for recent changes.

A bulk device cleanup was run in Entra. If someone deleted a batch of stale device records from Entra → Devices, every device whose record was deleted but whose certificate still lives on the local machine will now fail CAA50021 until the certificate is removed and re-registration completes. The fix here is the certificate-cleanup procedure from Cause 1 above, applied to every affected device — which is annoying but is the correct repair.

In all three fleet-wide scenarios, do not disable Conditional Access tenant-wide as a “quick fix”. Roll back the specific change that caused it.

When to escalate

If you’ve worked through the diagnostic and:

  • dsregcmd /status shows everything as YES,
  • The Conditional Access tab in the sign-in log shows the failing policy is one your device should satisfy,
  • The device is enrolled and shows compliant in Intune,
  • And the certificate is valid and present,

…then you have a genuine back-end inconsistency. Open a Microsoft 365 admin support ticket and include: the user’s UPN, the device ID from dsregcmd /status, the timestamp of a failed sign-in attempt in UTC, and the Correlation ID from the sign-in event. Microsoft tier-2 support can see Entra back-end state that you cannot. This is the case where escalating is worth your time.

Don’t do these things

  • Don’t tell the user to clear browser cookies. It does nothing for CAA50021.
  • Don’t tell the user to reset their password. Their password is fine. The device is the problem.
  • Don’t run third-party certificate cleaners. They will delete the certificate without doing the dsregcmd /leave and rejoin properly, leaving you with a worse state.
  • Don’t disable Conditional Access entirely “just to test”. The whole point of the policy is to deny access in exactly this scenario; disabling it is not a fix, it’s a security regression. If you genuinely need to grant exception access during diagnosis, use a temporary policy exclusion for the one user.
  • Microsoft 365 Error CAA50021 — the end-user-facing version of this same error, with what users themselves can try
  • Conditional Access Blocked Sign-In — when CA blocks for reasons other than device state
  • MFA Prompt Loop: admin-side causes — when Conditional Access is interacting badly with MFA

Official references

FAQ

Is CAA50021 always a device-state problem?

In our experience, ~95% of the time yes. The remaining 5% is unusual edge cases: federated identity providers in odd states, Conditional Access authentication context misconfigurations, and back-end Entra issues that warrant a support ticket. Start with the device.

Why does Microsoft’s user-facing error message tell users to clear cookies if that doesn’t help?

The user-facing message is a generic fallback for the entire CAA family of error codes. Some CAA errors genuinely are session-state issues that benefit from a fresh sign-in. CAA50021 isn’t one of them, but the message doesn’t differentiate.

Will deleting the MS-Organization-Access certificate cause data loss?

No. The certificate is regenerated on next sign-in after dsregcmd /leave and reboot. The user’s data, profile, mailbox, OneDrive — none of it is touched. The certificate is purely a device-identity artefact.

Can I prevent CAA50021 entirely by removing my device-compliance Conditional Access policy?

You can. You shouldn’t. The policy is what’s blocking unmanaged devices from accessing your tenant data — that’s its job. Removing it removes a security control. The right fix is to ensure the user’s device is genuinely compliant, not to remove the gate.

My user’s device shows AzureAdJoined: YES and AzureAdPrt: YES, but they still get CAA50021. What now?

Check the Conditional Access tab on the failed sign-in event. The failing grant control is something other than device state — most likely MFA, or session-frequency, or location. CAA50021 is a family of failures, not all of which are about the device certificate; the umbrella code can fire for related state issues too.

Why does this only happen to some users in my tenant?

Conditional Access policies are typically scoped to specific users, groups, or roles. The users hitting CAA50021 are inside the policy scope; the users who aren’t, aren’t. Check Assignments → Users and groups on the failing policy to see who’s in scope.

Is there a PowerShell way to detect which devices are at risk before they hit CAA50021?

Yes. The Get-MgDevice cmdlet (Microsoft Graph PowerShell SDK) can pull all devices and their join state. Cross-reference against your Conditional Access policy’s compliance requirements. This is the proactive approach for tenants of any meaningful size.

↑ Back to top