Who should own customer MFA policy in a large organisation?

Why This Matters for Security Teams

Customer MFA policy is not just a login setting. It shapes how accounts are enrolled, challenged, recovered, and monitored across the full customer journey. When ownership sits too close to a single product team, MFA often becomes inconsistent across channels, regions, and risk tiers. When it sits too far from the business, it becomes rigid, user-hostile, and full of exceptions. The practical answer is a governance model that treats MFA as a shared security control with clear decision rights, not as a feature toggle. That aligns with the NIST Cybersecurity Framework 2.0 emphasis on governance and risk ownership, and with NHIMG guidance on lifecycle control in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. The issue is not only policy design, but auditability, consistent enforcement, and fast response when fraud patterns change. In practice, many organisations discover ownership gaps only after inconsistent MFA enrolment or recovery logic has already been exploited.

How It Works in Practice

The strongest operating model is usually central policy ownership with distributed implementation. Identity and security governance should own the standard: required MFA methods, risk-based step-up rules, recovery controls, assurance levels, and exception criteria. Product, fraud, support, legal, and customer experience teams should influence the policy where user friction, fraud typologies, or regulatory obligations differ by segment or region. That separation keeps the control coherent while still reflecting real customer journeys. A practical ownership model often includes:

• A central identity governance team defining the baseline MFA standard and approved assurance methods.
• Fraud and risk teams feeding signals that determine when stronger step-up is required.
• Product teams implementing the policy in apps, portals, and recovery flows.
• Customer support owning escalation paths, with limited authority to override only under documented conditions.
• Security operations monitoring enrolment drift, bypasses, and recovery abuse.

This is where NHIMG guidance on Lifecycle Processes for Managing NHIs is useful even in a customer-authentication discussion: lifecycle discipline matters whenever credentials, recovery channels, or device bindings are created, changed, or revoked. MFA policy should be documented as policy-as-standard, then implemented through product-specific controls with measurable review cycles. NIST also frames this well in terms of governance, protective controls, and accountability rather than ad hoc feature ownership, especially in the NIST Cybersecurity Framework 2.0. Where organisations get this wrong is letting app teams individually redefine enrolment, recovery, and bypass logic, which creates uneven assurance and a patchwork of exceptions that security cannot reliably audit.

Common Variations and Edge Cases

Tighter central ownership often increases delivery friction, so organisations must balance consistency against product autonomy and customer experience. There is no universal standard for this yet, but current guidance suggests the policy should be central while the implementation can be local if controls remain measurable and reviewable. That distinction matters in large organisations with multiple business lines, acquired brands, or regional legal constraints. A few edge cases change the operating model:

• High-fraud consumer platforms may give fraud teams stronger influence over step-up triggers, but not final policy ownership.
• Regulated sectors may require legal or compliance approval for recovery methods, especially where fallback channels create identity proofing risk.
• Acquired businesses often inherit divergent MFA logic; central governance should standardise minimum controls before migration.
• Legacy channels may not support modern phishing-resistant MFA, so roadmap planning matters as much as policy wording.

NHIMG’s research on the Top 10 NHI Issues is a useful reminder that fragmented ownership almost always leads to inconsistent control enforcement and poor visibility. For organisations with repeated recovery abuse or account-takeover pressure, the right question is not who owns MFA screens, but who owns the risk decision and who can prove the policy is enforced. If that line is blurred, the control quickly turns into a local product preference rather than an enterprise security standard.

Related resources from NHI Mgmt Group

• Who should own cloud guardrail policy decisions in a large organisation?
• Why do collaboration tools create such a large secrets risk?
• Who should own tenant-level SSO and MFA policy?
• Who should own device risk policy in an organisation?