IAM and identity governance teams should own the policy, while operations teams handle the technical delivery of enrolment and recovery workflows. The important point is accountability: second factors are identity assets, so they need lifecycle control, audit trails, and clear revocation procedures just like other access mechanisms.
Why This Matters for Security Teams
Automated MFA governance is not just an authentication operations task. It affects account recovery, fraud resistance, auditability, and the organisation’s ability to revoke access when identities change. If policy ownership is vague, teams often end up with inconsistent enrolment rules, weak exception handling, and no clear evidence trail for assurance reviews. That is why governance belongs with identity leadership, not as an ad hoc help desk function.
This is also where NHI lessons matter. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs treats lifecycle control as a security requirement, not a convenience feature, and that logic maps directly to MFA devices, factors, and recovery paths. The same operational discipline appears in the NIST Cybersecurity Framework 2.0, which emphasises governance, asset oversight, and access control as linked responsibilities rather than isolated tasks. In practice, many security teams discover MFA ownership gaps only after a recovery request, device loss, or role change has already created a blind spot.
How It Works in Practice
A workable model separates policy authority from operational execution. IAM or identity governance teams define who must use MFA, which factors are acceptable, when step-up is required, how recovery is approved, and how exceptions are time-bound. Operations teams then implement the enrolment workflow, device replacement, support escalation, and logging. This division keeps the control accountable while still allowing fast service delivery.
Good practice is to treat second factors as identity assets with their own lifecycle. That means enrolment, reassignment, suspension, recovery, and revocation should be governed with the same rigor as account provisioning. Where possible, the policy should be enforced centrally through the identity platform, with evidence sent into the broader control environment described in the Top 10 NHI Issues and related audit guidance. In mature environments, governance teams also define what “strong enough” means for different risk tiers, rather than assuming one MFA rule fits every population.
- Policy owners define approved factors, re-enrolment triggers, and recovery approval thresholds.
- Operations teams deliver workflows, integrations, user support, and exception processing.
- Security teams review logs, failed recovery attempts, and dormant factor cleanup.
- Audit teams verify revocation timing, evidence retention, and exception expiry.
For control design, this aligns well with identity-first guidance in NIST CSF 2.0, especially where access governance and detection need to work together. These controls tend to break down when consumer-style self-service recovery is allowed in high-risk environments because the organisation loses assurance over who actually re-bound the factor.
Common Variations and Edge Cases
Tighter MFA governance often increases support overhead, requiring organisations to balance stronger assurance against faster recovery and lower user friction. That tradeoff is especially visible in regulated industries, executive accounts, and contractor-heavy environments where recovery requests are frequent and the tolerance for downtime is low.
There is no universal standard for this yet, but current guidance suggests different ownership models for different risk tiers. High-risk populations usually need IAM-owned policy with security-approved recovery steps, while lower-risk internal user groups may tolerate more operational delegation. The key is that delegation does not mean abdication. Even when service desk staff execute the workflow, identity governance still needs control over approvals, time limits, and revocation rules.
Another common edge case is emergency access. If break-glass procedures bypass standard MFA, they should be separately owned, tested, and logged, with retrospective review after every use. The same principle applies when legacy systems cannot support modern factors cleanly. In those cases, organisations should document compensating controls and a migration plan rather than leaving exceptions in place indefinitely. NHIMG’s 2024 ESG Report: Managing Non-Human Identities underscores how quickly governance gaps become exposure points when lifecycle controls are weak. Ownership becomes unclear fastest in outsourced service desks and merger integrations, where process drift can outpace policy enforcement.
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 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identity governance and access assurance map directly to MFA policy ownership. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Factor lifecycle and revocation are identity asset controls for authentication. |
| NIST SP 800-63 | AAL2 | Assurance levels inform which MFA methods and recovery paths are acceptable. |
Assign MFA policy ownership, enforce approval paths, and verify factor lifecycle controls.
