Accountability should sit with IAM, security architecture, and application owners together. IAM owns the authentication standard, security architecture defines the risk threshold, and application owners ensure their systems can support device-bound methods. If responsibility is fragmented, old MFA methods stay in place longer than they should.
Why This Matters for Security Teams
MFA modernisation is not just an authentication refresh. It is a governance decision that affects phishing resistance, help desk load, legacy app compatibility, and how quickly an organisation can retire weaker factors. When accountability is unclear, teams keep supporting SMS codes, shared fallback paths, and exception-based access long after the risk is understood. NIST’s control baseline for authentication and access enforcement makes this a program responsibility, not a one-time tooling choice, as reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls.
The same pattern shows up across identity sprawl. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks, which is a useful reminder that authentication decisions have direct operational and breach impact. If MFA modernisation is owned only by IAM, it can stall on application constraints; if it is owned only by app teams, it can drift into inconsistent standards.
In practice, many security teams discover MFA technical debt only after a legacy method is still in production during a phishing or account takeover event, rather than through intentional lifecycle governance.
How It Works in Practice
Accountability works best as a shared operating model with clear decision rights. IAM defines the approved authentication standard, security architecture sets the minimum assurance level, and application owners are responsible for implementation feasibility inside their systems. That structure avoids the common failure where teams agree MFA should be modernised, but no one owns the backlog, exception handling, or deprecation date for older methods.
Practically, the programme should treat MFA as a control migration. Start by inventorying where legacy methods are used, then classify applications by authentication capability, user risk, and business criticality. For higher-risk access paths, modern methods such as phishing-resistant authenticators and device-bound credentials should become the target state. Where an application cannot support the new method immediately, the exception should be time-bound, documented, and approved through security architecture, not left to local preference.
- IAM owns the authentication policy, method catalogue, and rollout standards.
- Security architecture defines acceptable assurance, exception criteria, and risk acceptance.
- Application owners deliver the code and integration changes required to support the standard.
- Business owners help sequence rollout for critical workflows and user groups.
Implementation should also include operational controls: user communications, recovery path redesign, test coverage, and metrics that show how many apps still depend on weaker MFA. The Top 10 NHI Issues research is relevant here because modernisation fails when weak credential handling is treated as a technology problem instead of a governance one. These controls tend to break down when a large estate of custom, mainframe, or third-party integrated applications cannot support device-bound methods without substantial refactoring.
Common Variations and Edge Cases
Tighter MFA modernisation often increases change-management overhead, requiring organisations to balance stronger phishing resistance against application complexity and user support burden. That tradeoff is real, especially in environments with regulated workflows, shared infrastructure, or outsourced application ownership.
There is no universal standard for this yet, but current guidance suggests that shared accountability should not mean shared ambiguity. In highly regulated sectors, risk acceptance may sit with a formal architecture review board. In SaaS-heavy environments, procurement and vendor management may need to enforce authentication requirements earlier in the lifecycle. In mergers or multi-tenant enterprises, different identity stacks can force a phased migration where one control standard is applied unevenly for a time, but the retirement date for weaker MFA still needs an owner.
Edge cases also appear when recovery factors are as weak as the original MFA method. If password resets, help desk overrides, or break-glass accounts bypass the new standard, the programme has modernised the front door while leaving the side entrance open. That is why accountability must include authentication recovery and exception governance, not only the primary login flow. The most effective programmes tie ownership to a dated migration plan and track progress until legacy MFA methods are formally disabled.
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 AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Authentication governance is part of managing access decisions and assurance. |
| NIST SP 800-63 | AAL2 | MFA modernisation should target assurance levels, not just factor count. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Weak credential lifecycle governance is a recurring NHI control failure. |
| NIST AI RMF | GOVERN | Modernising MFA needs explicit governance, ownership, and accountability. |
| NIST Zero Trust (SP 800-207) | SC-12 | Zero trust depends on stronger, continuously evaluated authentication. |
Assign MFA ownership to the identity control owner and map all methods to a single approved standard.
Related resources from NHI Mgmt Group
- Who is accountable when phishing-resistant MFA remains only partial across a financial estate?
- Who is accountable when business associates access ePHI without strong MFA?
- Why is SMS not a durable long-term MFA strategy for healthcare identity?
- Who should own adversarial testing findings in identity programmes?
