Why does giving users control over adding authentication factors change the MFA operating model for identity teams?

User-controlled factor enrollment shifts MFA from a purely administrator-driven control to a shared governance model. That improves adoption, but it also requires tighter policy around which factors are allowed, how enrollment is verified, and when an account is considered upgraded. Identity teams need to treat factor choice as an access-control decision, not just a convenience feature.

How user-controlled factor enrollment changes the MFA operating model

When users can add their own authentication factors, MFA stops being a single administrator-led setup task and becomes a governed lifecycle. Identity teams have to decide which factors are permitted, how strong each factor is, and what proof is required before a new factor is trusted. That moves the control from static configuration into ongoing policy enforcement, monitoring, and exception handling.

The operating model changes because enrollment is now part of the access decision, not just an implementation detail. A user-added factor can strengthen resilience, but it can also create a new path for takeover if enrollment, recovery, or device binding is weak. That is why teams need clear rules for factor eligibility, step-up checks, and account state changes before higher trust is granted.

In practice, this also changes ownership. Help desk, identity operations, security, and application teams may all touch the workflow, but the identity team must own the trust boundary. Guidance such as NIST SP 800-63 Digital Identity Guidelines is useful here because it frames authenticator assurance and phishing-resistant enrollment as a policy problem, not only a product feature.

Why enrollment governance becomes the real control point

User-controlled enrollment expands the number of moments where the system must trust the person at the keyboard. That means enrollment verification, reauthentication, and recovery protections matter as much as sign-in. If an attacker can add a factor after stealing a password, the account may look “MFA protected” while still being practically vulnerable.

This is where factor policy becomes important. Teams usually need different treatment for SMS, authenticator apps, security keys, passkeys, and backup methods because each has different resistance to phishing, device theft, and session replay. NHIMG’s MFA Guide and Passwordless and Passkeys Guide both reflect the same operational point: enrollment policy must distinguish between factors that merely improve convenience and factors that materially raise assurance.

Once users can self-enroll, the identity team must also manage upgrade logic. For example, an account may begin with a weaker factor set, then move to a higher trust state only after stronger proof, device binding, or verified recovery. That transition is part of authorization and lifecycle governance, not just UX.

What changes for identity teams day to day

The main shift is from one-time provisioning to continuous governance. Teams need visibility into who enrolled what, when the enrollment happened, whether the device or factor was verified, and whether the factor should still be accepted after a risk event. This is why lifecycle controls such as review, rotation, offboarding, and recovery validation become more important when users control factor addition.

Identity teams also need to plan for abuse patterns that exploit the enrollment path itself. If an attacker can socially engineer a reset, trick a user into approving a device, or enroll a factor after a password compromise, MFA becomes a false sense of safety. NHIMG’s Workforce Identity Security Guide is relevant because it ties enrollment, recovery, and step-up authentication to the broader identity operating model.

That operating model should also treat exception handling as first-class work. High-risk roles, recently recovered accounts, and accounts with unusual enrollment history may need tighter controls than ordinary users. In other words, user choice can be allowed, but only inside a policy envelope that preserves assurance.

Risk and Threat Considerations

User-controlled enrollment increases the attack surface around recovery, device trust, and factor substitution. The danger is not only that an attacker bypasses MFA, but that they add a factor that later makes compromise persistent and hard to notice.

Failure mechanism: Weak enrollment verification, permissive recovery flows, or factor types with poor phishing resistance let an attacker turn a password compromise into durable account control by registering a new trusted factor.

Impact: The account may remain exposed even after the initial password is changed, because the attacker controls the second factor path, recovery path, or both.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Self-enrollment and authenticator assurance directly affect MFA trust levels.
Recommendation — Apply enrollment assurance and authenticator requirements before accepting a new factor.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Factor enrollment changes authenticator lifecycle, validation, and revocation needs.
	IA-2 — Identification and Authentication (Organizational Users)	User-controlled MFA enrollment changes how organizational users are authenticated and stepped up.
Recommendation — Control issuance, use, and lifecycle of authenticators added by users. Require stronger authentication before allowing factor changes.
ISO/IEC 27001:2022	A.5.15 — Access control	Factor choice is an access-control decision that must be governed.
Recommendation — Define and enforce access rules for permitted MFA factors.
CIS Controls v8	CIS-6 — Access Control Management	User-enrolled factors alter account access paths and control ownership.
Recommendation — Manage account access paths and review factor changes centrally.

Practitioner Guidance

What to prioritise: Treat enrollment and recovery as the highest-risk parts of the MFA journey. The first question is not whether users can add factors, but whether the new factor meaningfully improves assurance over the current recovery and sign-in path.

What to verify: Confirm that every self-service enrollment flow has a clear trust threshold, strong reauthentication, and auditable evidence of who approved the new factor. If an account can add a factor after only a password check, the operating model is too weak for anything but low-risk use cases.

Practitioner takeaway: User-controlled enrollment is acceptable only when identity teams can prove that factor addition, recovery, and trust upgrading are governed as security decisions, not convenience decisions.