Who should own risk-based MFA when the application does not change?

Why This Matters for Security Teams

Risk-based MFA looks simple at the application layer, but ownership becomes ambiguous when the app itself never changes and the challenge is enforced upstream at the identity provider, reverse proxy, or access gateway. That split matters because policy changes, failure handling, and user experience all live outside the codebase. Current guidance suggests the accountable team should be the one that can prove the challenge decision, test the control end to end, and respond when risk scoring or conditional access logic fails. The control surface is often larger than the application team realises, especially where NIST Cybersecurity Framework 2.0 and identity operations are separated. This is not just an admin issue. NHI Management Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 71% of NHIs are not rotated within recommended time frames, which reflects how often identity controls drift when ownership is unclear. The same pattern appears in MFA governance: if no one owns policy enforcement, exceptions accumulate silently. In practice, many security teams discover that “the app owner” is the wrong owner only after risk-based prompts stop firing consistently or a bypass path has already been abused.

How It Works in Practice

Risk-based MFA should be treated as an identity control with distributed responsibilities, not a feature owned solely by the application team. The team that owns authentication policy and edge enforcement should define when step-up is triggered, what signals are evaluated, and how failures are logged. The application team may still need to validate redirects, session handling, and account recovery flows, but it should not be the only accountable group. A practical operating model usually includes:

• Identity or IAM engineering owns conditional access policy, tuning, and enforcement points.
• Security operations owns monitoring for bypasses, false negatives, and anomalous challenge failure rates.
• Application owners validate user journeys, business exceptions, and downstream session state.
• Risk or GRC defines acceptable challenge thresholds and approval paths for policy changes.

That division aligns with what NHI Management Group highlights in the Ultimate Guide to NHIs: identity controls fail when governance is fragmented across teams that each see only part of the lifecycle. It also fits the broader pattern in the Top 10 NHI Issues, where visibility and revocation gaps become operational risks once ownership is unclear. Operationally, the control should be tested from the edge inward. Teams should confirm that risk signals trigger challenge at the correct layer, that an exception in one app does not become a global bypass, and that logs capture who changed the policy and why. Where organisations use federation, the step-up decision may sit entirely outside the app, which means the app owner cannot fully observe or repair broken challenge logic. These controls tend to break down in federated SSO environments with multiple gateways and shared policy sets because no single team owns the full decision path.

Common Variations and Edge Cases

Tighter risk-based MFA ownership often increases coordination overhead, requiring organisations to balance faster app delivery against stronger control assurance. That tradeoff is real, especially when multiple business units share the same identity stack. There is no universal standard for this yet, but current guidance suggests the most effective model is shared accountability with a single policy owner, not diffuse responsibility. Edge cases matter:

• For legacy applications, the app team may have no code changes at all, so ownership shifts almost entirely to IAM and edge operations.
• For customer-facing portals, product teams may influence UX, but they should not override security policy without formal approval.
• For high-risk environments, MFA policy may be tied to device posture, geo-risk, or session risk, which means changes must be tested like production controls, not treated as simple configuration.
• For third-party identity providers, the owning team must still monitor outages, misroutes, and bypass paths even when configuration lives in an external console.

The right question is not who “uses” MFA, but who can safely change it, validate it, and prove it works under stress. That is why ownership should sit with the authentication and enforcement function, while application teams remain consulted rather than exclusively accountable. For broader identity governance context, the 2024 ESG Report: Managing Non-Human Identities shows how often organisations underestimate identity control failures until compromise is already underway. When the application never changes, ownership still has to.

Related resources from NHI Mgmt Group

• Who should own risk appetite decisions in identity and security programmes?
• Who should own SMS pumping risk in an organisation?
• Who should own identity risk decisions in a digital marketplace?
• Who should own governance when crypto risk spans compliance, fraud, and IAM?