What breaks when organisations rely on MFA alone for digital interactions?

Why This Matters for Security Teams

MFA is still useful, but it is only one checkpoint in a longer identity and transaction chain. Once a session is issued, an attacker can replay tokens, steal cookies, intercept mobile push approvals, or abuse an already-authenticated workflow to move from login to high-impact action. That gap matters because modern environments blend humans, service accounts, API keys, and automation, so “authenticated once” does not mean “safe until done.” NHI Mgmt Group research shows that 80% of identity breaches involved compromised non-human identities, which reinforces the point that access is often abused after the initial prompt, not before it. Guidance in NIST Cybersecurity Framework 2.0 and real-world incident patterns in the Microsoft Midnight Blizzard breach both show that assurance has to extend to the session, device, workload, and action being approved. In practice, many security teams encounter the weakness only after a legitimate login has already been used to approve the wrong transaction.

How It Works in Practice

The practical fix is to treat authentication and authorisation as separate, continuously evaluated steps. MFA can establish who or what is presenting credentials, but the system still needs to verify whether the current session, device posture, location, risk score, and requested action match policy. That is especially important for JIT credentials, ephemeral secrets, and autonomous workloads, because the value of the credential changes once it is in motion. Static RBAC often cannot express this context, which is why intent-based and real-time policy evaluation are gaining traction for both humans and agents. For workload identities, cryptographic proof should be tied to the workload itself, not just to a password or push prompt.

Common controls include session binding, step-up checks for sensitive actions, token lifetimes that match task duration, and explicit approval gates for fund transfer, admin changes, or secret export. For agentic or automated workflows, current guidance suggests combining workload identity with policy-as-code so each action is checked at request time, rather than trusting the original login forever. The CI/CD pipeline exploitation case study is a useful reminder that valid pipeline credentials can become a privileged attack path when governance ends at sign-in. OWASP guidance for NIST Cybersecurity Framework 2.0 style access governance aligns with this model when it is paired with strong lifecycle controls and short-lived secrets. These controls tend to break down in high-friction mobile approvals and legacy apps because the application cannot re-evaluate trust after the first MFA prompt.

• Bind high-risk actions to a fresh policy check, not the original login.
• Use short-lived tokens and revoke them when the task ends.
• Require re-authentication for step-up actions like payments, key export, or privilege changes.
• Apply continuous session monitoring for unusual device, IP, or workflow behaviour.

Common Variations and Edge Cases

Tighter transaction controls often increase user friction and integration overhead, so organisations have to balance assurance against operational speed. That tradeoff is real, especially when customer-facing apps, branch systems, or third-party tools cannot support modern session binding or continuous evaluation. Best practice is evolving here, and there is no universal standard for every workflow.

In lower-risk flows, MFA plus session controls may be enough, but high-value actions need stronger separation between authentication and authorisation. For agents and automation, Emerald Whale breach illustrates how valid access can be repurposed when privileges are too broad and secrets live too long. NHI Mgmt Group data also shows that 91.6% of secrets remain valid five days after notification, which is why long-lived credentials are a poor fit for dynamic interactions. The key exception is when a workflow is offline, air-gapped, or deeply embedded in a legacy transaction system; in those cases, compensating controls such as transaction signing, step-up approval, and tight PAM oversight become more important than MFA alone. The NIST Cybersecurity Framework 2.0 remains useful as a baseline, but it must be translated into session- and action-level controls to be effective.

Related resources from NHI Mgmt Group

• Should organisations rely on detection alone for secrets management?
• Should organisations rely on SSO and MFA as their main identity controls?
• What breaks when organisations rely on legacy DLP for AI workflows?
• What breaks when teams rely on periodic access certification alone?