How should organisations secure MFA self-enrollment when accounts have not yet registered a second factor?

Why unenrolled accounts need a narrower trust boundary

MFA self-enrollment is a privileged moment in the identity lifecycle because the account is transitioning from single-factor to stronger authentication. Until a second factor is registered, the account remains vulnerable to session hijack, password spraying, phishing, and helpdesk-assisted takeover. The right control choice is to constrain who can reach the enrollment flow, not merely to add more prompts once the user arrives. For background on risk-oriented identity governance, NIST AI Risk Management Framework is not directly about MFA, but it illustrates the broader principle of controlling high-risk transitions rather than trusting them by default.

What practitioners often miss is that the first factor is usually enough to become the attacker’s foothold if the enrollment step is treated as ordinary self-service. In practice, many security teams discover the weakness only after a compromised password is used to bind a new factor, rather than through intentional enrollment policy design.

How self-enrollment should be structured in practice

The safest pattern is to treat MFA enrollment as a gated administrative event, even when the user experience is self-service. That means the organisation decides which conditions are acceptable before a second factor exists, rather than relying on the unenrolled account’s password alone. Conditional access is the usual control point: allow registration only from trusted network locations, approved devices, or a managed onboarding path where the identity has already been verified. If the user is not yet enrolled, the organization should assume the session is higher risk than a normal login and apply tighter policy accordingly.

Temporary Access Passes are useful because they let a legitimate user complete first-time setup without turning password knowledge into long-lived access. They work best when they are short-lived, tightly scoped, and bound to a clear enrollment workflow. For identity assurance context, the registration step should align with the same discipline used in high-assurance identity proofing and recovery processes, because the control is really about proving the person before granting durable authentication capability.

• Restrict enrollment to approved devices or trusted locations.
• Use a time-limited bootstrap credential rather than a reusable exception.
• Separate first-factor login from factor registration approval where risk is higher.
• Log enrollment attempts as security events, not just user activity.

This guidance breaks down when organisations let recovery channels, legacy protocols, or broad device trust bypass the enrollment gate, because then the attacker only needs one weak path to register persistence.

Where enrollment policy becomes fragile

Tighter enrollment controls often increase onboarding friction, so organisations must balance account protection against helpdesk load and user delay. The tradeoff is real: if the policy is too strict, legitimate users get blocked during first use; if it is too loose, an attacker who has captured a password can bind their own factor and lock in access. The consensus position is clear that the enrollment step deserves stronger scrutiny than routine sign-in, but organisations differ on how much friction is acceptable for low-risk users versus privileged or high-impact accounts.

Edge cases appear where a user has no managed device, is off-network, or is joining through a contractor or break-glass process. In those cases, the right answer is usually not to weaken enrollment globally, but to provide an exception path with stronger verification and short validity. If the account is privileged, shared, or tied to sensitive systems, the enrollment path should be more restrictive than standard workforce onboarding. When self-enrollment is embedded in a broader recovery flow, teams should also ensure the same path cannot be reused to reset the account after compromise.

Risk and Threat Considerations

Unenrolled accounts create a narrow but high-value takeover window because the first successful login may be enough to establish a durable second factor. The main risk is not the absence of MFA itself, but the ability to convert temporary password access into persistent authenticated access through the enrollment flow.

Failure mechanism: An attacker who knows or resets the password can reach the registration page, add a factor they control, and then use that factor to keep access even after the original password is changed. Weak enrollment gating, permissive location rules, and overbroad recovery paths all make that mechanism easier.

Impact: The account can become permanently harder to evict than a simple password compromise, especially if it is tied to email, privileged applications, or downstream identity recovery. That turns a single-login incident into an authentication persistence problem.

Practitioner Guidance

What to prioritise: Treat first-time MFA registration as a controlled security workflow, not as ordinary self-service. The highest-value accounts should have the narrowest enrollment conditions because they also create the largest downstream blast radius if hijacked.

What to verify: Confirm that unenrolled accounts cannot use the same access path as fully enrolled users unless the session is already proven safe. Teams should test whether an attacker with only a password can reach factor registration from an unmanaged device, remote location, or recovery channel.

Decision rule: If the account can create or reset a second factor without a separate trust check, the design is too weak. If the user must pass a short-lived bootstrap process and the enrollment event is auditable, the control is closer to the right model.

Practitioner takeaway: The real security objective is not “let users enroll MFA,” but “prevent a stolen first factor from becoming persistent access.”

Related resources from NHI Mgmt Group

• How should organisations balance convenience and security when deciding where to store two-factor authentication codes for everyday accounts?
• How should healthcare organisations implement MFA without turning it into a box-ticking exercise?
• How should healthcare organisations secure PHI so they can meet HIPAA requirements?
• How should organisations design YubiKey recovery so they do not weaken phishing-resistant MFA?