Security teams can overestimate assurance and leave the real identity problem unresolved. MFA can reduce account takeover risk, but it does not guarantee that the enrolled user was the right person or that the login is tied to a trusted identity. If proofing, recovery, and transaction approval are weak, attackers can still gain access through fraud, social engineering, or stolen enrolments.
Why This Matters for Security Teams
When MFA is treated as a complete identity solution, organisations confuse a stronger login with a trusted identity lifecycle. MFA can reduce stolen-password abuse, but it does not solve identity proofing, enrolment integrity, recovery abuse, or transaction-level approval. Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that authentication is only one control family, not the full identity stack.
The gap becomes more visible when attackers exploit help desks, reset workflows, or enrolment channels instead of the login prompt itself. NHIMG research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is a useful reminder that identity failure is often broader than interactive sign-in. The same pattern appears in service and machine access, as covered in the Ultimate Guide to NHIs.
Security teams that equate MFA with trust usually miss the point that possession of a second factor is not the same as assurance of the right person, device, or session context. In practice, many security teams encounter identity compromise only after an attacker has already used a legitimate MFA flow to enter through recovery or enrolment abuse, rather than through intentional verification design.
How It Works in Practice
A complete identity system needs multiple layers: proofing, enrolment, authentication, authorisation, recovery, and audit. MFA strengthens one layer, but it does not validate that the original identity proofing was sound or that the enrolment device has not been transferred, cloned, or socially engineered away from the rightful holder. That is why guidance from ISO/IEC 27001:2022 Information Security Management and NIST both treat identity as a process, not a single factor.
In practice, teams should separate three questions:
- Was the identity proofed correctly before it was enrolled?
- Can recovery be abused to bypass the second factor?
- Is the transaction itself approved with enough context?
That is where fraud-resistant controls, step-up verification, device binding, and transaction signing matter. For high-risk actions, MFA at login should be followed by contextual approval, such as re-authentication for payout changes, privilege elevation, or new device enrollment. NHIMG analysis of real-world breach patterns in 52 NHI Breaches Analysis and the Top 10 NHI Issues shows that weak lifecycle controls, not just weak authentication, create durable exposure.
For NHI and agentic environments, the same logic applies more sharply: a token or challenge does not prove the workload is trustworthy if the secret was copied from code, CI/CD, or a compromised runtime. Strong identity programs pair MFA with short-lived credentials, workload identity, and explicit revocation paths. These controls tend to break down when organisations centralise access around a single SSO event because recovery, delegation, and downstream session reuse remain outside the original MFA decision.
Common Variations and Edge Cases
Tighter MFA often increases user friction and help-desk load, requiring organisations to balance assurance against recovery complexity and operational speed. That tradeoff is real, especially where contractors, legacy apps, or shared operational accounts still exist.
Best practice is evolving, but current guidance suggests that some environments need more than standard MFA to close the identity gap. For example, phishing-resistant factors improve resistance to credential theft, yet they still do not eliminate social engineering against support staff or privileged approvers. Likewise, step-up MFA for sensitive transactions helps only if the policy can distinguish routine access from high-risk actions at runtime.
Teams should also be careful not to overgeneralise human identity controls into machine or agent settings. A service account or agent may authenticate successfully but still have excessive privilege, long-lived secrets, or poor offboarding. NHIMG research in the Ultimate Guide to NHIs — What are Non-Human Identities shows why lifecycle governance matters as much as authentication. The practical lesson is that MFA is a gate, not a guarantee, and it fails most visibly where identity recovery, enrolment, and delegated access are weakly governed.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity assurance gaps often start with weak NHI enrollment and lifecycle controls. |
| OWASP Agentic AI Top 10 | A-03 | Agent and workload access needs runtime trust decisions beyond a login factor. |
| CSA MAESTRO | IDM-02 | MAESTRO stresses identity proofing and governance across agentic workflows. |
| NIST AI RMF | GOVERN | MFA alone does not address accountable identity governance for AI-enabled systems. |
| NIST CSF 2.0 | PR.AA-01 | Authenticating users is only one part of broader access assurance requirements. |
Use context-aware authorization and short-lived credentials for agent actions instead of static MFA assumptions.
Related resources from NHI Mgmt Group
- Why do password and SMS-based factors leave organisations exposed even when multi-factor authentication is enabled?
- What breaks when organisations treat PIV as only an authentication factor?
- What breaks when authentication starts with shared secrets instead of verified identity?
- What breaks when organisations treat SSO as complete access governance?
