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

Why self-enrollment needs a tighter trust boundary

MFA registration is not just an admin convenience step, it is an account-security control point. When an account has no second factor yet, whoever reaches enrollment first can often bind a factor that will be trusted later. The practical problem is not the login itself, but the moment access is converted into durable trust.

That is why the enrollment path should be treated as a privileged workflow, not a normal user journey. Enrollment should be constrained to conditions the organisation can reasonably trust, such as managed devices, approved network locations, or a controlled setup process, so the first factor alone does not become a standing invitation to persist.

For organisations building the control, the important design choice is whether self-enrollment is open to any authenticated session or only to sessions that already satisfy stronger trust checks. The safer pattern is to make initial registration conditional, because unenrolled accounts are especially attractive to attackers who want to add their own factor and then preserve access even after the password is reset.

How to reduce the chance of attacker-led factor enrollment

The core defence is to separate first-time registration from ordinary sign-in and to require stronger assurance before a new factor can be added. In practice, that means using conditional access to gate enrollment and requiring a controlled bootstrap mechanism, such as a Temporary Access Pass, when a user has not yet registered a second factor.

That bootstrap step matters because it gives the organisation a way to complete setup without turning unenrolled accounts into a broad attack surface. A Temporary Access Pass can be issued, limited, and revoked, which is more defensible than letting any successful password login immediately create a durable second factor.

The same logic applies to recovery and exception handling. If help desk processes or backchannel approvals can bypass the normal enrollment rule, they become part of the attack surface. The safer model is to keep the enrollment decision tied to policy, device trust, and location trust, rather than to ad hoc support discretion.

NHIMG’s MFA Guide is useful here because it covers MFA enrollment, bypass paths, and phishing-resistant rollout choices in one place.

What breaks when unenrolled accounts are treated as low risk

The main failure mode is persistent account takeover. If an attacker learns or steals a password and can reach enrollment without additional checks, they can register their own factor, survive password changes, and keep logging in as the legitimate user. The account then looks enrolled and healthy even though the trust relationship has been hijacked.

Another common failure is over-trusting recovery workflows. If the organisation allows MFA registration from unmanaged devices, unknown geographies, or loosely controlled onboarding steps, an attacker can use the weakest moment in the lifecycle to establish durable access. That is why initial setup deserves the same scrutiny as privileged access changes.

This risk is not theoretical. Microsoft Midnight Blizzard breach and Colonial Pipeline ransomware attack both show how weak or unused access paths can become durable entry points when authentication controls are not enforced tightly enough.

Risk and Threat Considerations

Unenrolled accounts create a narrow but high-value window for adversaries. If the first successful login can be turned into factor enrollment, the attacker does not need to keep stealing passwords, they only need one opportunity to establish a trusted factor and then blend in as the legitimate user.

Failure mechanism: The organisation permits MFA registration from a session that is not sufficiently trusted, so the attacker can bind their own factor before the real user completes enrollment or notices the compromise.

Impact: The account can remain accessible after password resets, support interventions, or ordinary fraud checks, which raises the likelihood of persistent compromise and follow-on access to internal systems or sensitive data.

Practitioner Guidance

What to verify: Confirm that enrollment is blocked unless the session meets a defined trust policy, and test the exact paths users can take before they are fully enrolled. The usual weak spots are first login, password reset, help desk recovery, and any legacy authentication path that still reaches the identity platform.

Decision rule: If an account is not yet enrolled in MFA, treat any successful password-only session as insufficient for unrestricted factor registration. Use a temporary bootstrap credential, a managed device requirement, or a location-based rule before allowing the user to add a second factor.

Practitioner takeaway: The goal is not simply to get every account enrolled, but to ensure that the act of enrollment itself cannot be used as an attacker’s persistence mechanism.

Related resources from NHI Mgmt Group

• Self-Enrollment
• Why does MFA self-enrollment create risk for accounts that do not yet have a second factor?
• Why do MFA implementations still fail even when a second factor is enabled?
• What breaks when attackers can add temporary access or modify MFA enrollment on compromised accounts?