Legacy MFA often proves only that someone knows a secret or controls a device. Those factors can be stolen, replayed, approved by mistake, or phished. Without an inherent user signal, the system cannot reliably distinguish the legitimate user from an attacker who has captured credentials, coerced approval, or hijacked the second factor.
Why This Matters for Security Teams
Legacy MFA is often treated as proof of user identity, but it is usually only proof that a factor was presented. That distinction matters because phishing kits, push fatigue, session theft, and device compromise all let an attacker satisfy the control without being the enrolled user. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls frames authentication as one part of access assurance, not a standalone guarantee of human presence.
Security teams often overestimate MFA strength when the factor is not bound to the user’s inherent traits, current context, or cryptographic device state. That gap becomes visible in real incidents where a stolen session or approved prompt is enough to move laterally. The lesson from DeepSeek breach and the Microsoft Midnight Blizzard breach is that identity assurance fails fast once an attacker has a usable factor or path around it.
In practice, many security teams discover that MFA has validated access after the account has already been used for something the real user never intended.
How It Works in Practice
To prove the authenticating person is the enrolled user, organisations need stronger identity evidence than a password plus second factor. Current guidance suggests combining MFA with phishing-resistant authentication, device binding, and risk-based checks that evaluate whether the attempt fits the enrolled user’s normal environment. The most reliable patterns use cryptographic proof from a hardware-backed authenticator, not just an approval prompt or one-time code.
Practitioners usually separate the problem into three layers:
- Something the user knows, such as a password, which is easiest to steal.
- Something the user has, such as a device or security key, which is stronger but still vulnerable if the session or device is hijacked.
- Something that ties the action to the enrolled user and trusted device at runtime, such as phishing-resistant MFA, step-up verification, or continuous risk scoring.
That last layer is where many legacy methods fall short. Push-based approvals can be accepted under pressure, OTPs can be intercepted, and SMS can be redirected. Stronger assurance usually comes from FIDO2 or passkey-based flows, device attestation, and policy decisions that inspect context before granting access. This is why NHI-oriented programmes increasingly treat secrets, sessions, and authenticators as separate attack surfaces rather than one control plane. The account may still be “authenticated,” but that does not mean the enrolled user is the actor behind the request. NHI research on DeepSeek breach shows how quickly exposed credentials can turn into unauthorized access, while broader secrets research such as The State of Secrets in AppSec highlights how often compensating controls are expected to carry more assurance than they can deliver.
These controls tend to break down in environments that still rely on shared devices, legacy VPNs, or helpdesk-driven MFA resets because the asserted identity is only as strong as the recovery path.
Common Variations and Edge Cases
Tighter authentication often increases user friction and support overhead, requiring organisations to balance stronger identity proof against recovery complexity. That tradeoff is especially sharp in high-turnover workforces, contractor-heavy environments, and operational teams that cannot tolerate repeated reauthentication during a shift.
There is no universal standard for this yet, but best practice is evolving toward phishing-resistant MFA, device-bound credentials, and conditional access that can step up or deny based on context. Legacy MFA can still be useful as a baseline, yet it should not be mistaken for proof of personhood. In some regulated environments, auditors accept MFA as control evidence even when the implementation is weak, so teams need to document the actual assurance level rather than the label on the login screen.
Edge cases include shared kiosks, call-centre logins, privileged break-glass accounts, and remote support sessions. In those situations, the control question changes from “Did a factor validate?” to “Can the system prove the right person, on the right device, for the right action, at the right time?” That is the direction NHI governance is moving, but legacy MFA alone cannot close the gap.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and authentication assurance are central to this MFA question. |
| NIST SP 800-63 | AAL2 | AAL levels define how much assurance MFA actually provides. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust requires continuous verification beyond a one-time MFA event. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity proofing gaps and secret-based access are core NHI risks. |
| NIST AI RMF | AI systems amplify identity and session abuse risks when assurance is weak. |
Reduce reliance on reusable secrets and bind access to stronger, non-transferable identity signals.
