TL;DR: Unosecur says multi-factor authentication adds a second independent factor to login, blocking over 99.9% of automated account compromise attempts and reducing the impact of password theft, reuse, phishing and credential stuffing. The baseline still matters, but the real test is whether teams apply it consistently to privileged access and remote entry paths.
At a glance
What this is: This is an explanation of why MFA remains the baseline identity control, with the key finding that it materially reduces password-driven account compromise.
Why it matters: It matters because IAM teams still need a second factor on privileged and remote access paths, even when stronger controls are being layered on top.
By the numbers:
- MFA can block over 99.9% of automated account compromise attempts, according to the article.
👉 Read Unosecur's analysis of why multi-factor authentication still sets the identity baseline
Context
Multi-factor authentication is a login control that requires two or more independent factors, usually something you know, something you have, or something you are. The identity security gap it addresses is simple: a password alone is not a durable proof of identity, especially when theft, reuse, or phishing are in play.
For IAM programmes, MFA is the baseline control that changes the attack economics for human identities. It does not remove the need for privileged access governance, device trust, or session controls, but it closes the easy path that single-factor authentication leaves open.
Key questions
Q: How should security teams implement MFA for privileged accounts?
A: Security teams should require phishing-resistant MFA for privileged accounts, especially where remote administration or high-impact systems are involved. Use hardware-backed factors or FIDO2 where possible, remove SMS from elevated access paths, and pair MFA with conditional access and short session lifetimes. The control only works if it is enforced on every privileged route, including break-glass and vendor access.
Q: Why do passwords become far less dangerous when MFA is enforced?
A: Because a stolen or reused password is only one part of the login challenge. MFA forces the attacker to obtain a second, independent proof, which is usually harder to steal quietly at scale. That shifts attacks from silent credential abuse toward noisier social engineering or device-focused bypass attempts.
Q: What are the signs that MFA is being bypassed rather than actually protecting access?
A: Warning signs include repeated approval prompts, unexpected login attempts from unfamiliar locations, users reporting code interception, and continued compromise despite MFA being enabled. If accounts are still falling to phishing or session theft, the control may be present but not effective. That usually means the organisation is relying on weaker factors or poor user verification flows.
Q: What should teams do when a VPN or admin password is exposed and MFA was not enforced?
A: Treat the exposed credential as a live entry point until the affected accounts, sessions, and dependent access paths are reviewed and locked down. Reset or revoke the credential, confirm whether the account touched privileged systems, and then close the policy gap that allowed password-only access in the first place.
Technical breakdown
How MFA changes the authentication workflow
MFA inserts an additional verification step after the primary credential is checked. A password, PIN, or other first factor is validated first, then the system challenges for a second factor such as an authenticator app code, push approval, hardware token, or biometric unlock bound to a device. The session token is issued only when both checks succeed. That matters because the attacker must compromise two independent proofs, not just steal one credential. In practice, the second factor is strongest when it is resistant to replay, phishing, and remote interception.
Practical implication: Treat MFA as a sequencing control, not a bolt-on feature, and enforce it where the session is issued.
Why privileged and remote access need stronger MFA coverage
Privileged accounts and remote entry paths concentrate risk because they are the shortest route from identity compromise to broad system access. A leaked password, reused credential, or successful phishing attempt becomes far more dangerous when it can unlock VPN, admin, or cloud management sessions without another barrier. The article’s examples reflect a recurring pattern: the failure is rarely that attackers guess a password, but that the environment accepts a password as sufficient proof for high-impact access. MFA narrows that window and forces the attacker into a noisier path.
Practical implication: Prioritise MFA enforcement for admin, VPN, and other high-trust entry points before expanding elsewhere.
Where MFA still gets bypassed in practice
MFA is not a universal shield because attackers adapt to the control itself. Fatigue prompts, SMS interception, SIM swap abuse, and social engineering can all target the second factor rather than the password. Those bypasses do not make MFA irrelevant, but they show that factor quality matters. App-based or hardware-backed factors generally raise the bar more than SMS, and phishing-resistant methods reduce the chance that an attacker can relay a challenge in real time. The control fails when organisations treat all MFA methods as equivalent.
Practical implication: Differentiate between MFA methods and phase out weaker factors on the most sensitive accounts.
Threat narrative
Attacker objective: The attacker’s objective is to turn a stolen password into authenticated access that can be used for intrusion, privilege expansion, or fraud.
- Entry occurs when an attacker obtains a password through phishing, reuse, credential theft, or a leaked account source.
- Escalation succeeds when that password is accepted as sufficient proof for remote or privileged access because a second factor is missing.
- Impact follows when the attacker uses the authenticated session to reach internal systems, manage assets, or establish a foothold for broader compromise.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MFA remains the control that turns password compromise from a direct breach path into an incomplete attack. The article’s core point is not that passwords disappeared as a threat, but that second-factor verification still changes the attacker’s success rate dramatically. For identity programmes, the baseline problem is that too many access paths still behave as if a password is enough. Practitioners should treat MFA coverage as the minimum condition for trusted login.
Privileged access is where MFA policy becomes a governance issue, not just an authentication setting. Admin and remote entry paths carry disproportionate blast radius, so inconsistent enforcement there creates a structural gap even when MFA exists elsewhere. The important question is not whether MFA is enabled somewhere, but whether the highest-risk sessions are actually covered. That is where identity assurance is won or lost.
Weak MFA methods create a false sense of closure. SMS, push approval, and fatigue-prone workflows can all be attacked differently, which means the method choice shapes the residual risk. The article supports a simple conclusion: teams that treat every second factor as equivalent are overestimating their assurance level. The practitioner implication is to distinguish baseline MFA from phishing-resistant MFA.
Second-factor assurance debt: Many identity programmes still carry a gap between stated MFA policy and the quality of factors actually enforced on high-value accounts. That gap matters because the weakest approved factor often becomes the attacker’s easiest path. The field should stop measuring MFA as a binary checkbox and start measuring the assurance of the factor mix.
Access hardening is now inseparable from session-entry policy. The article reinforces a broader identity truth: once a session is issued, the organisation has already decided what level of identity proof it accepts. That makes authentication design a governance control, not just a user experience choice. Practitioners should align session entry rules with the value of the assets being reached.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Second-factor assurance debt: Many identity programmes still report MFA coverage as a yes-or-no control, but the real issue is whether the right factor protects the right session. Password-only remote access and weak second factors create a gap between stated policy and actual assurance, which is where attackers still win.
MFA should now be treated as the floor for identity assurance, not the endpoint. The next governance question is whether privileged access, customer login, and remote entry all use factors that can withstand phishing, interception, and replay attempts.
For practitioners
- Enforce MFA on privileged entry paths Require multi-factor authentication on administrative consoles, VPNs, and cloud control planes before broadening enforcement to lower-risk populations.
- Replace weaker second factors Move high-value accounts away from SMS and other interception-prone methods toward app-based or hardware-backed factors with stronger phishing resistance.
- Audit MFA coverage by session type Compare policy to reality for remote access, admin logins, and customer identity flows so that the accounts with the largest blast radius are not left behind.
Key takeaways
- MFA still matters because it interrupts the easiest password-driven intrusion paths and raises the cost of account takeover.
- Coverage quality matters as much as coverage count, especially for admin, VPN, and other high-trust sessions.
- The control only works as intended when weak factors are phased out and exceptions are not allowed to define the baseline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B — Authentication | MFA is the article's core authentication control for identity assurance. |
| Recommendation — Apply SP 800-63B to raise authentication assurance on high-risk sessions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on whether access is actually gated by the right authentication strength. |
| Recommendation — Map privileged access paths to PR.AA-05 and verify the assurance level matches the asset risk. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | MFA for employees and admins is directly governed by organisational authentication controls. |
| Recommendation — Enforce IA-2 on administrative and remote access workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article's examples show why account protections and enforcement consistency matter. |
| Recommendation — Use CIS-5 to standardise MFA enforcement across critical accounts. | ||
| OWASP ASVS | V6 — Authentication | The article is about the authentication layer and factor verification during login. |
| Recommendation — Use V6 to verify that authentication flows require more than a password. | ||
Key terms
- Multi-Factor Authentication: Multi-factor authentication requires two or more independent verification factors before access is granted. In practice, it reduces the chance that a stolen password alone will open a system, but it only works well when applied consistently across all high-risk access paths and identity types.
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Second Factor: A second factor is an additional proof of identity used after a password, such as a hardware key, authenticator app, or SMS code. In mature security programmes, the choice of second factor matters because not all methods resist phishing equally, and some can be bypassed or relayed.
- Privileged Access: Privileged access is any elevated entitlement that can change systems, data, or security settings. When privilege is excessive or poorly scoped, a single compromised identity can create outsized blast radius across environments.
What's in the full article
Unosecur's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how MFA validation happens during authentication
- Examples of common MFA methods, including app codes, push prompts, tokens, and biometrics
- Case studies showing where MFA was absent or weaker methods were bypassed
- The article's discussion of user friction and why adoption still matters
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 31, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org