CWE-287: Improper Authentication is a weakness where a system does not properly verify a user, device, or process before granting access. It covers failures such as missing login checks, weak credential validation, or flawed session handling, and can let an attacker impersonate an identity or reach protected functions without valid authentication.
Authentication Failure Modes That Matter
CWE-287 describes a class of weakness, not a single bug pattern: the system accepts an actor before it has actually proven who or what that actor is. In practice, the failure may sit in login logic, API gatekeeping, session validation, device checks, or a secondary trust step that was assumed to be safe.
That matters because authentication is the first boundary that keeps protected functions from becoming publicly reachable. When it is incomplete or inconsistent, an attacker does not need to “break in” in the traditional sense, they can simply present themselves in a way the application mistakenly accepts.
Why Improper Authentication Becomes a Security Boundary Problem
improper authentication often appears when developers validate one part of the login flow but miss another, such as a forgotten endpoint, a replayable session token, or a weak fallback path. A common weakness pattern is CWE Top 25 Guide, which helps explain why authentication failures repeatedly rank among the most dangerous software weaknesses.
The issue is not limited to passwords. Systems can also fail by trusting stale sessions, comparing only partial credentials, accepting weak proof of identity, or allowing alternate names, default credentials, or missing login checks to reach the same protected action. When that happens, the application may still look “secured” from the outside while a path inside remains effectively open.
How Improper Authentication Shows Up in Real Systems
This weakness can emerge in web applications, APIs, administrative consoles, remote access portals, and service-to-service workflows. It is especially dangerous where a successful login unlocks high-value actions, because a single bypass can expose customer data, operational tooling, secrets, or privileged functions.
Authentication failures are also frequently tied to broader weakness chains, which is why a combined reference such as CVE, CWE and CPE Guide is useful when teams are tracing a real vulnerability from design weakness to product exposure. That mapping helps security teams distinguish the root cause from the specific exploit path.
In practice, improper authentication may be triggered by flawed session handling, weak credential validation, missing step-up checks for sensitive actions, or broken trust in client-supplied data. If the application treats a token, cookie, or header as proof without validating its integrity and context, the weakness can become a direct access bypass.
Security Consequences and Identity Impact
The main consequence is unauthorized access, but the downstream impact is usually broader than that. Once an attacker gets past the authentication boundary, they may impersonate users, access administrative functions, steal data, alter records, or pivot into adjacent systems through trusted sessions and over-privileged accounts.
Because the weakness undermines proof of identity, the identity impact can extend to session material, API credentials, and account recovery paths. If exploitation is suspected, organisations should assume that any session or secret exposed through the compromised flow may no longer be trustworthy and should be reviewed for misuse, theft, or replay.
Risk and Threat Considerations
Improper authentication is attractive to attackers because it reduces the cost of access: instead of stealing a credential or defeating MFA, the attacker targets the application’s trust decision itself. That creates risk across login, session, and privileged-action workflows, especially where a single missed validation step unlocks many downstream permissions.
Failure mechanism: The system accepts an actor based on incomplete, weak, or incorrectly ordered checks, allowing impersonation, session replay, or direct access to protected functions.
Impact: Exposure can include account takeover, unauthorized administrative actions, data theft, privilege escalation, and the need to invalidate sessions or rotate exposed secrets after compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | CWE-287 is an authentication weakness directly addressed by ASVS authentication requirements |
| Recommendation — Verify authentication flows, fallback paths, and step-up checks against ASVS V6 requirements. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Improper authentication for workforce or admin access maps to proving organizational user identity |
| IA-5 — Authenticator Management | Weak or mishandled credentials and session material are central failure modes in improper authentication | |
| IA-9 — Service Identification and Authentication | Improper authentication often affects APIs, workloads, and other non-human access paths | |
| Recommendation — Enforce IA-2 controls so organizational users are authenticated before privileged access is granted. Apply IA-5 to manage credential issuance, validation, rotation, and revocation consistently. Use IA-9 to authenticate services and machine-to-machine calls before protected actions execute. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and authentication weaknesses often surface through weak lifecycle control of user access |
| Recommendation — Harden account lifecycle and authentication-related administration under CIS Control 5. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Improper authentication can let an attacker operate with stolen or illegitimate access that the system accepts |
| Recommendation — Map authentication-bypass cases to T1078 and hunt for unexpected successful logons and privilege use. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | API authentication failures are a direct and specific manifestation of improper authentication |
| Recommendation — Test API login, token, and session handling for Broken Authentication before exposing sensitive endpoints. | ||
Practitioner Guidance
What to watch for: Treat this weakness as an application trust-boundary defect, not just a login bug. Review every path that grants access, especially alternate entry points, session resumption, password reset, API authentication, and any control that assumes a user is already known to be authenticated.
Practitioner takeaway: The safest test is simple, if a sensitive action can still succeed when authentication is removed, weakened, or replayed, the application has not really enforced authentication at that boundary.
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 October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org