Error-code database

The redirect URI in the sign-in request does not match any redirect URI registered on the app — register the exact URI on the app registration.

The signed-in account does not exist in the tenant the app authenticated against — wrong account type, wrong tenant endpoint, or a guest who was never invited.

Entra ID searched the target tenant for the username and found nothing — typo, wrong tenant, deleted user, or a UPN/alias that isn't a sign-in name.

Entra smart lockout temporarily locked the account after repeated bad attempts — often a stale saved credential, or an actual password-spray.

The account's password has expired and must be changed before sign-in can complete — watch for hybrid setups where cloud and on-prem expiry disagree.

The account is disabled in Entra ID — re-enable it in the portal, or in hybrid setups check the on-prem account state and sync.

The app attempted silent authentication but Entra ID has no usable signed-in session — the app must fall back to an interactive sign-in.

Policy requires MFA for this sign-in and the session hasn't satisfied it — expected interactively, a configuration smell for background clients.

MFA is required but the user has no registered methods — they must complete security-info registration before this sign-in can succeed.

The app requires assignment and the signing-in user isn't assigned — add the user or group under the enterprise application, or disable assignment requirement.

Credential validation failed — usually a wrong password; repeated 50126 storms point at a stale saved credential or a password-spray attack.

Entra ID could not determine which tenant to authenticate against — the domain isn't registered in any tenant, or the tenant hint is mistyped.

The token or grant the client presented has been invalidated — password change, revoked sessions, or an expired grant. The user must sign in again.

A Conditional Access policy blocked this sign-in — the sign-in log's Conditional Access tab names the policy; fix policy, device or location.

The user or admin has not consented to the permissions the app requests — grant admin consent or let users consent where policy allows.

No app registration matches the client ID in this tenant — wrong client ID, wrong tenant/authority, or a single-tenant app used cross-tenant.

The client secret in the token request is wrong — most often an expired secret, or the secret's ID pasted instead of its value.

The token request carried no client credentials — enable 'Allow public client flows' for device-code/ROPC clients, or send the secret/assertion.

The refresh token sat unused past its inactivity window and is dead — the client must run an interactive sign-in to get a fresh grant.

The tenant identifier in the request does not resolve to any Entra tenant — check the tenant ID/domain in the authority URL for typos or staleness.

The SCEP request timed out before the server answered. Usually a slow or overloaded NDES server, or middleboxes delaying the request.

DNS lookup for the SCEP URL failed on the device. Common when an internal-only NDES hostname is put in a profile assigned to internet-based devices.

DNS resolved but the TCP connection to the SCEP endpoint failed — firewall, closed port, or the service simply is not listening.

TLS to the SCEP endpoint failed — untrusted, expired or mismatched server certificate, or the device clock is wrong.

Windows CNG returned 'Access denied' while creating or using the private key for the SCEP request — usually key container permissions or a TPM in a bad state.

Windows CNG could not find an object it needed during SCEP enrolment — commonly the root CA certificate the profile references, or a key that no longer exists.

The key container the SCEP client expected does not exist or cannot be opened — classic symptom of damaged TPM key storage or deleted machine keys.

The key storage provider cannot do what the SCEP profile asks — typically a TPM that does not support the requested key size or algorithm.

The cryptographic device (in practice, the TPM) is not ready, so the SCEP client cannot generate the key. Fix the TPM state, not the profile.

Logged by ScepInstallCertificateFailure when the device submitted its SCEP request but got no certificate back — the server rejected or mishandled it.

The device's MDM stack returned OMA-DM status 500 — an unexpected internal error while processing the setting. A generic device-side failure.

Generic Intune error: the device received the profile, tried to apply it, and failed. On SCEP profiles it usually means enrolment failed on-device.

The SCEP service refused the challenge in the device's request, so no certificate was issued. Usually connector, clock or replay problems.

Intune decided the SCEP profile does not apply to this device — platform, edition, assignment or dependency mismatch, not an enrolment failure.

The SCEP profile requires a TPM-attested key and the device could not produce a valid attestation — usually TPM capability or EK certificate issues.

Win32 error 1722 — the DCOM/RPC call to the CA never connected. Service stopped, firewall, DNS, or a CA that no longer exists.

Certificate chain validation failed because the CRL (or OCSP) endpoint could not be reached. The certificate may be fine — the revocation infrastructure is not.

The SCEP request's challenge password was refused — NDES passwords are single-use, expire after 60 minutes by default, and only a handful are cached at once.

AD CS will not start because it cannot verify its own CA certificate chain — almost always an expired parent CRL from an offline root CA.

Certificate enrolment failed because the client could not reach the CA over DCOM/RPC — CertSvc stopped, firewall, or missing DCOM permissions.

The enrolment client failed against every enrolment endpoint for its policy — usually the same RPC/permission problem as Event 13, or dead endpoints.

The NDES admin page will not issue a challenge — the requesting user needs Enroll permission on the configured templates, plus Windows authentication.

SCEP GET requests carry the whole PKCS message in the query string; default IIS and HTTP.SYS length limits reject them. Raise the limits on every NDES server.

NDES is running but throwing an internal error — typically broken template registry settings, missing RA certificates, or CA connectivity problems.

The NDES URL answers 503 — the IIS application pool behind /certsrv/mscep is stopped or crashing, so every SCEP enrolment in the estate fails at once.

When the Intune Certificate Connector is unhealthy, the NDES policy module rejects every SCEP request even though IIS and the CA are fine.

Windows shows a generic failure because the client refuses the RADIUS server's certificate — root not trusted or server-name validation mismatch.

NPS dropped the request because the sender's IP is not registered as a RADIUS client — new switch, changed management IP, or NAT in the path.

The request's Message-Authenticator failed validation — the shared secret differs between the NAS and NPS, so requests are silently discarded.

The Windows supplicant cannot find a certificate satisfying EAP-TLS requirements, so authentication never starts — check EKU, key, store and auth mode.

Authentication failed: the username didn't map to an account or the password was wrong — with EAP-TLS it often means a certificate identity mapping problem.

The client offered an EAP method the server could not process — EAP type mismatch between client profile and policy, or a broken server certificate.

NPS hit an internal error while running EAP — often server certificate problems or a TLS handshake that died mid-flight rather than a clean policy rejection.

The RADIUS message failed integrity verification — in practice, the shared secret configured on the NAS does not match the one configured in NPS.

NPS does not trust the CA that issued the client's certificate — the issuing chain is missing from the NPS server's certificate stores.

The TLS handshake inside EAP failed because client and server share no TLS version/cipher suite — typical after protocol hardening on either side.

The request passed connection request policy but matched no network policy's conditions — group membership, NAS port type or day/time conditions didn't line up.

The request failed at the first gate: no connection request policy matched, so NPS never evaluated network policies at all.

The AD account's dial-in Network Access Permission is set to deny, so NPS refused the connection regardless of policy — set it to allow or policy-controlled.

A network policy matched, but the client used an authentication method that policy does not allow — align the EAP method list with the client profile.

NPS rejected the request because the account name in the request does not resolve to any account — usually a username format, realm or wrong-domain problem.

NPS or the client could not retrieve revocation data for the peer certificate, so authentication fails with nothing revoked — a CRL reachability issue.