They work because authentication success is often treated as the end of the control, not the beginning of identity oversight. Once an attacker has a valid session, excessive privilege, dormant access or weak monitoring determines how far they can go. The security issue is governance after login, not login alone.
Why stolen credentials still open doors in mature environments
stolen credentials keep working because many environments still trust the first successful login too much. If a session is valid, the platform may treat it as proof enough, even when the access path came from phishing, password reuse, token theft, or mfa fatigue. Mature controls can still fail when identity governance, privilege boundaries, and session monitoring lag behind authentication.
Why MFA fatigue succeeds after the password is already gone
MFA fatigue is effective when the control is designed to stop initial sign-in, but not to challenge repeated approval behaviour or suspicious post-login activity. Attackers exploit human attention, notification overload, and exception handling. In practice, the weakness is often not the MFA factor itself, but the surrounding recovery, enrolment, and escalation paths that remain too permissive.
That is why Workforce Identity Security Guide places phishing-resistant MFA, recovery hardening, and session theft prevention in the same operating model.
What mature environments miss after authentication succeeds
The real control gap is usually post-authentication governance. Excessive privilege, dormant accounts, weak conditional access, unmanaged sessions, and poor alerting allow an attacker to turn one valid login into broad reach. Mature programs often measure sign-in success, but not what the user or session can actually do once inside.
That pattern shows up in incidents like Uber breach 2022, where MFA fatigue and credential theft opened the path to internal tools, and in Change Healthcare breach 2024, where a single remote-access login without MFA had outsized consequences.
It also shows up when valid credentials are enough to bypass perimeter assumptions, as in SonicWall SSL VPN account compromises 2025 and Colonial Pipeline ransomware attack.
Risk and Threat Considerations
Once attackers have valid credentials or a coerced MFA approval, they often do not need to break authentication again. They can exploit standing privilege, session persistence, dormant access, and weak detection to move laterally or extract data while looking like a normal user.
Failure mechanism: The environment assumes successful sign-in equals trusted access, so compromised accounts keep the same permissions, session scope, and recovery options as legitimate ones. Reused passwords, long-lived sessions, and poor review of access rights make that assumption durable.
Impact: A single stolen identity can become persistent access, privilege escalation, or broad data exposure, especially where remote access, admin tooling, or service integrations are reachable from the same account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address 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 | IA-5 — Authenticator Management | Covers credential lifecycle and rotation after theft or fatigue-driven compromise. |
| IA-2 — Identification and Authentication (Organizational Users) | Applies to user sign-in controls that MFA fatigue attempts try to bypass. | |
| AC-6 — Least Privilege | Limits what a valid session can do after authentication succeeds. | |
| Recommendation — Rotate, revoke, and reissue compromised authenticators quickly. Require strong user authentication with phishing-resistant methods where possible. Reduce standing access so stolen credentials cannot reach high-impact actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Maps to excessive permissions that increase blast radius after credential theft. |
| NHI-07 — Long-Lived Secrets | Addresses durable credentials and tokens that remain useful after compromise. | |
| NHI-10 — Human Use of NHI | Helps when human workflows misuse non-human access paths or shared secrets. | |
| Recommendation — Remove unnecessary privilege from non-human and service access paths. Shorten secret lifetime and rotate exposed credentials promptly. Prevent people from handling or reusing machine credentials outside approved workflows. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Covers phishing-resistant authentication and replay-resistant identity assurance. |
| Recommendation — Use phishing-resistant authenticators and stronger assurance for high-risk access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Relevant where stolen tokens or weak sign-in controls let attackers act as legitimate users. |
| Recommendation — Harden API authentication and reject replayable or stolen tokens. | ||
Practitioner Guidance
What to prioritise: Treat post-login control as a first-class security problem. Focus on session controls, privilege minimisation, and rapid revocation for stale or suspicious access before spending more effort on adding another login prompt.
What to verify: Confirm that valid sessions are bounded by risk signals, that dormant accounts are removed or disabled, and that high-impact actions require step-up checks or separate authorization even after primary authentication succeeds.
Common mistake: Teams often report MFA adoption as if it closes the case. It does not, unless recovery flows, help-desk resets, session theft, and privileged access paths are also constrained.
Practitioner takeaway: The control objective is not just to stop bad sign-ins, but to prevent a bad sign-in from becoming durable authority.