AADSTS error codes are the numeric and alphanumeric codes returned by Microsoft Entra authentication and token services when a sign-in, consent, or token request fails. They map specific identity and OAuth failure conditions, such as invalid credentials, tenant mismatch, consent issues, or conditional access blocks, and are used for troubleshooting and attack analysis.
What the codes tell you
AADSTS error codes are more than UI noise, they are the service’s way of naming a specific identity or token failure mode. In Entra ID, the code usually tells you whether the request failed at authentication, consent, tenant discovery, conditional access, or token issuance, which makes the code itself a diagnostic signal rather than a generic error.
Because the same request can fail for very different reasons, these codes help separate bad credentials from policy enforcement, misconfiguration, tenant mismatch, or blocked sign-in flows. That distinction matters because the response path changes depending on whether the issue is user input, tenant policy, application setup, or a security control working as intended.
Why they matter for troubleshooting
For operators and application owners, AADSTS codes reduce guesswork during incidents. A single failure may be caused by expired consent, a disabled account, a missing redirect URI, an invalid audience, or an access policy block, and the code can narrow the problem to the right layer before deeper investigation starts.
They are also useful because the same code can appear across interactive and non-interactive sign-in paths, so teams can correlate failures with sign-in logs, audit events, and application telemetry. The practical value is not the number itself, but the repeatable mapping from code to failure condition.
If you want a log-centric way to use these codes in investigation workflows, Entra ID Sign-In and Audit Log Detection Guide shows how AADSTS values fit into sign-in and audit analysis.
What they reveal about identity and token flow
AADSTS codes sit at the boundary between authentication, authorization, and token issuance. That means they often expose which part of the trust chain failed, for example credential validation, policy evaluation, consent grant, or token redemption, and they can help distinguish identity problems from application-side errors.
In OAuth and SSO flows, this diagnostic detail is especially important because a failure can occur after the user has already authenticated. A successful credential check does not guarantee token issuance, and a code may indicate that the request was blocked by consent policy, tenant rules, or claims requirements rather than by the login itself.
That distinction also explains why the same code can be useful for both support and security analysis. In a normal incident, it speeds triage; in a hostile environment, it can show where an attack or abuse attempt was interrupted.
How to read them in attack and defence analysis
AADSTS codes can surface signs of password spraying, tenant probing, consent abuse, device code phishing, and conditional access evasion attempts. When the same code repeats across many accounts or from unusual sources, it can indicate a patterned attempt rather than isolated user failure.
The codes are especially valuable when read alongside source IP, client app, sign-in type, and policy outcome. A blocked request can still be security-relevant because it shows what the attacker tried to do, which control stopped it, and whether the same method is still being attempted elsewhere.
For threat-context reading, Storm-2372 (device code phishing) threat actor profile illustrates how Entra ID authentication failures and Conditional Access blocks fit into a real phishing and token-abuse pattern.
How to use vendor guidance and authoritative references
AADSTS codes are diagnostic labels, not a complete explanation on their own. Microsoft’s own documentation remains the authoritative source for the exact meaning of each code, while logs and policy records provide the context needed to interpret why the failure occurred in your environment.
For defenders, the right workflow is to pair the code with the sign-in event, the application context, and the relevant policy decision, then confirm whether the failure is expected, misconfigured, or suspicious. Used that way, the code becomes a stable lookup key for both support and security operations.
For broader control alignment around authentication, access decisioning, and logging, NIST SP 800-53 Rev 5 Security and Privacy Controls, NIST SP 800-63 Digital Identity Guidelines, and MITRE ATT&CK Enterprise Matrix provide useful reference points for authentication controls, identity assurance, and attacker tradecraft.
Risk and Threat Considerations
AADSTS codes can expose more than routine sign-in failures, they can reveal whether an attacker is probing tenants, replaying bad credentials, abusing consent flows, or testing which policy controls are in place. Repeated or distributed failures often matter because they show live adversary interest, not just user error.
Failure mechanism: The code surfaces the exact point where the request failed, which can help defenders distinguish blocked abuse from successful compromise, but it can also help attackers iterate until they find a weaker path.
Impact: Unread or misread codes can delay containment, hide campaign patterns, and leave organisations blind to credential attacks, token misuse, or policy gaps that are already being exercised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | AADSTS codes are interpreted through sign-in and token event review. |
| IA-2 — Identification and Authentication (Organizational Users) | The codes describe failures in user authentication and sign-in processing. | |
| AC-7 — Unsuccessful Logon Attempts | Repeated AADSTS failures can indicate lockout, spraying, or blocked access attempts. | |
| Recommendation — Review sign-in failures and AADSTS patterns to identify anomalous authentication activity. Validate user authentication failures against the identity source and sign-in policy. Monitor repeated failed sign-ins and investigate patterns that suggest abuse or misconfiguration. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The term sits in the identity assurance and authentication error path. |
| Recommendation — Use identity assurance guidance to interpret where the authentication flow failed and what must be verified. | ||
| MITRE ATT&CK | Enterprise Matrix | AADSTS patterns often map to credential access, phishing, and authentication abuse techniques. |
| Recommendation — Map repeated AADSTS failure patterns to adversary techniques and hunt for adjacent attack activity. | ||
Practitioner Guidance
What to watch for: Treat recurring AADSTS values as investigation leads when they cluster by account, IP, client app, tenant, or time window. A single code is often mundane; a repeated pattern is what usually warrants deeper review.
Governance implication: Teams should standardise how these codes are logged, triaged, and mapped to ownership so that support, identity engineering, and security operations all interpret them the same way. That prevents silent drift between “known issue” and “active threat”.
Practitioner takeaway: Use the code to narrow the failure class, then validate the surrounding sign-in context before deciding whether the event is a configuration problem, a control block, or an attack signal.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org