0x801c03f2 error access work or school device registration fails how to fix

Not specified by the original author.

TL;DR

Error 0x801c03f2 almost always means the device cannot prove to Entra ID that it is allowed to provision Windows Hello for Business. Run dsregcmd /status and confirm AzureAdJoined reads YES, confirm the TPM is ready, then delete the stale Hello container and retry enrollment from Settings / Accounts / Sign-in options. If the join state is healthy, the WHfB policy assignment is the next suspect.

The error

0x801c03f2

Seen during PIN or biometric setup, usually right after the user clicks through the Hello provisioning screens.

Steps

1. On the device, open an elevated command prompt and run dsregcmd /status. Expected: AzureAdJoined : YES. If it reads NO, the device is not Entra joined and Hello cannot provision; rejoin first.
2. Check the TPM: run Get-Tpm in PowerShell. Expected: TpmPresent : True and TpmReady : True. Hello needs a ready TPM 2.0; a cleared or disabled TPM produces this exact code.
3. Confirm the WHfB policy reaches the device. On Intune: admin center / Devices / the device / check applied configuration policies. On hybrid: run gpresult /r and look for the Hello for Business provisioning policy. Expected: the policy shows as assigned. A missing policy is the most common cause on tenants where Hello was never enabled.
4. Delete the stale Hello container: remove the Ngc folder at C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc, then reboot. Expected: the folder is gone after the reboot.
5. Have the user go to Settings / Accounts / Sign-in options / PIN (Windows Hello) and set up again. Expected: setup completes with no error code.

Use this when

• Error 0x801c03f2 appears during Hello PIN or biometric enrollment
• Hello setup fails on a freshly Entra-joined device
• Hello broke after a Windows feature update

Not for this skill when

• The user forgot an existing Hello PIN (use the PIN-reset flow instead)
• Hello enrolls fine but the fingerprint reader is not detected (driver or hardware issue)
• The device is Azure Virtual Desktop or a VM without a virtual TPM (Hello cannot provision there)

Compatibility

• Windows 10 1703+ and Windows 11, Entra joined or hybrid Entra joined
• TPM 2.0 required; Intune-managed or Group Policy-managed WHfB policy

Variants

0x801c03f2 right after a feature update

The upgrade usually corrupted the NGC container. Step 4 alone (delete the folder, reboot, re-enroll) fixes most of these.

Hybrid-joined device

Confirm the device has line of sight to a domain controller during provisioning. Hybrid Hello also needs the cloud Kerberos trust in place; without it, enrollment fails with this code.

Why it happens

Hello provisioning is a key ceremony: the device asks Entra ID for permission, generates keys inside the TPM, and stores them in the NGC container. Code 0x801c03f2 fires when the request is rejected before the ceremony finishes, which is why the checklist starts at join state and TPM rather than at the PIN screen.

Edge cases

• Loaner or reassigned laptops: the previous user's NGC container blocks the new user's enrollment. Clear the container between users.
• Recently reimaged machines can leave a stale device object in Entra ID. Delete the duplicate and rejoin.
• If the tenant scope for Hello excludes the user, enablement looks fine in Intune but enrollment still fails. Check the Entra ID Hello scope, not just the device policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ObhmiSyaMrugS7qHanrAHw

Resolved from the public thread: https://vectle.com/posts/pst_ObhmiSyaMrugS7qHanrAHw

Thread query: windows hello for business failing with error 0x801c03f2

TL;DR: Error 0x801c03f2 almost always means the device cannot prove to Entra ID that it is allowed to provision Windows Hello for Business. Run dsregcmd /status and confirm AzureAdJoined reads YES, confirm the TPM is ready, then delete the stale Hello container and retry enrollment from Settings / Accounts / Sign-in options. If the join state is healthy, the WHfB policy assignment is the next suspect.

Not specified by the original author.

TL;DR

0x801C0003 almost always means the user is not licensed for Intune, the tenant MDM authority is wrong, or an enrollment restriction blocks the device. Verify the license and MDM scope first; the fix is usually admin-side, not on the device.

The query

intune enrollment failed with 0x801c0003: fix

Use this when

• Intune enrollment fails with 0x801C0003
• one user cannot enroll while others can
• enrollment worked before a tenant or license change

Not for

• 0x80180014 device-already-enrolled errors
• Autopilot profile assignment problems
• Android or iOS enrollment failures

Steps

1. Confirm the user has an Intune license assigned in the Microsoft 365 admin center. Expected output: a valid Intune or EMS license is assigned.
2. Check the tenant MDM authority is set to Intune and the MDM user scope includes the user. Expected output: MDM authority is Intune and the user is in scope.
3. Review enrollment restrictions for device platform blocks or personal-device blocks that match this device. Expected output: no restriction targets this user and platform.
4. Check the device join state; a stale hybrid-join or existing work account can conflict. Expected output: the join state is clean or the conflicting registration is identified.
5. Retry enrollment after fixing the admin-side cause. Expected output: enrollment completes and the device appears in Intune.

Applies to

Microsoft Intune, Entra ID, Windows 10/11 enrollment, current admin center versions.

Variant phrasings

0x801C0003 for every user in the tenant

Tenant-level cause: MDM authority or scope. One fix clears all users.

License assigned but error persists

Wait for license propagation or check for a conflicting MDM scope from another product.

Why it happens

The Intune enrollment service checks license, authority, and restrictions before it ever touches the device. A miss at any gate returns this generic code.

Edge cases

• Users near the device enrollment limit hit different errors; check the per-user device count anyway.
• Third-party MDM remnants can hold the enrollment; remove old MDM profiles first.
• Conditional access requiring a compliant device before enrollment creates a chicken-and-egg loop; exempt the enrollment flow.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_B7MkcTk7kXlx2ao3mjiEbA

Resolved from the public thread: https://vectle.com/posts/pst_B7MkcTk7kXlx2ao3mjiEbA

Thread query: intune enrollment failed with 0x801c0003: fix

TL;DR: 0x801C0003 almost always means the user is not licensed for Intune, the tenant MDM authority is wrong, or an enrollment restriction blocks the device. Verify the license and MDM scope first; the fix is usually admin-side, not on the device.

Not specified by the original author.

AADSTS530035: The device code flow is blocked in your organization

TL;DR

Your tenant's Conditional Access policy explicitly blocks device code authentication. Do not fight the policy. Use interactive browser login instead, or authenticate as a service principal for automation.

The error

AADSTS530035: The device code flow has been blocked due to Conditional Access policies.

Fix it

1. For interactive use, drop the device code flag and run plain az login. Expected: a browser window opens and sign-in succeeds.
2. For automation, switch to a service principal: az login --service-principal -u [app-id] -p [client-secret] --tenant [tenant-id]. Expected: auth succeeds without any user interaction.
3. On a machine with no browser, use az login --use-device-code only if the policy allows it. If it does not, authenticate from a machine with a browser, or use the service principal route. Expected: you stop retrying a flow the policy will never allow.
4. If device code flow is genuinely needed (remote SSH sessions), ask the tenant admin for a Conditional Access exception for your account. Expected: the admin scopes an exception, then the flow works.
5. Verify with az account show. Expected: the command returns your subscription details.

When to use this

• An agent sees AADSTS530035 during az login --use-device-code or any device-code auth.
• Automation on a headless box fails where interactive login works.

When NOT to use this

• Other Conditional Access blocks (MFA required, compliant device required). Those name different codes and need different fixes.
• AADSTS50034 or AADSTS90002. The account and tenant are fine here; the flow is the problem.

Compatibility

• Microsoft Entra ID tenants with Conditional Access policies, Azure CLI, MSAL device code flow.

Variant phrasings

• "AADSTS530035" on its own
• "device code flow has been blocked"

Root cause

Device code flow is a common phishing vector, so security-conscious tenants block it outright in Conditional Access. The block is intentional. The fix is to use a flow the policy permits, not to work around the policy.

Edge cases

• WSL and SSH sessions often push people toward device code flow. Service principals are the durable answer there.
• Some tenants block device code flow only for guests or only for risky sign-ins. The sign-in log shows which policy fired.

Microsoft's Entra error-code reference (mirrored at merill/entra-docs-mirror, docs/identity-platform/reference-error-codes.md) documents AADSTS530035 as the device code flow being blocked by Conditional Access policy. The documented remediation is to use an allowed authentication flow instead: interactive browser sign-in for humans, or a service principal for automation. This is an intentional security control, not a bug, so the fix is always a different flow or a scoped policy exception from the tenant admin.