Enforcing a Second Factor in Entra ID: How to Secure Users Who Never Had One

If a user isn’t using a second factor, they’re a risk.

Many organizations still have legacy users in Entra ID (formerly Azure AD) who authenticate using only a username and password. Maybe they were onboarded before MFA became mandatory. Maybe they just slipped through the cracks.

Either way, the risk is real—and growing.

The good news? You can enforce a second factor in Entra ID even for users who haven’t registered one. Here’s how to close that gap.

Why This Matters

Passwords are notoriously weak—phishable, guessable, and frequently reused. Microsoft reports that accounts without MFA are 99.9% more likely to be compromised.

If your organization has adopted MFA policies for new users, but some older accounts still rely solely on password-based sign-ins, you’re only as secure as your weakest identity.

How Entra ID Helps You Catch Up

Entra ID allows you to enforce second factor registration retroactively using Conditional Access and Authentication Strengths or MFA Registration Policies.

Step-by-Step: Enforce MFA for Users Who Haven’t Registered

1. Identify Users Without a Second Factor

Use Entra ID’s MFA Registration Report to find users who haven’t set up any second factor (like phone, app, or FIDO2 key).

Azure Portal → Entra ID → Protection → Authentication Methods → Registration

2. Create a Conditional Access Policy

Target only the group of users lacking MFA. You can apply a temporary Conditional Access policy that requires MFA for sign-in.

  • Assignments: Target a dynamic group (e.g., users without registered MFA)
  • Cloud apps: All or critical apps (start small)
  • Grant controls: Require multi-factor authentication

3. Leverage ‘Registration Campaigns’ (Optional)

New in Entra ID: you can create campaigns to gently nudge users to register a second factor—without locking them out immediately.

4. Use Authentication Strengths for Granular Control

Want to allow only strong second factors (like FIDO2 or Microsoft Authenticator)? Entra ID lets you define Authentication Strengths, which can be used inside Conditional Access.

⚙️ What Happens to the User?

Once the policy is enforced:

  • Users without MFA are prompted to register at next sign-in.
  • They won’t be able to proceed without completing the second factor setup.

This includes users who previously never had MFA—Entra ID treats it as a real-time enforcement step, not just a one-time registration.

Extend This Protection to Legacy & On-Prem Apps

It’s not enough to secure just your cloud workloads. If your legacy or on-prem apps still rely on outdated authentication (e.g., LDAP or direct AD auth), you’re leaving a major security hole.

With Entra ID Application Proxy, SAML connectors, or identity federation, you can front-end legacy apps with modern authentication, including:

  • MFA and Conditional Access
  • Identity Protection and sign-in risk scoring
  • Centralized auditing and access reviews

Moving the authentication layer to Entra ID brings all apps—cloud or on-prem—under the same secure policy framework.

Pro Tips

  • Pilot First: Start with a small group to test the registration flow.
  • Communicate: Let users know what’s coming so they’re not caught off guard.
  • Secure Legacy Apps: Use Azure AD App Proxy or federation to Entra ID.
  • Monitor Logs: Track MFA registration and sign-in patterns to fine-tune enforcement.

Final Thoughts

It’s never too late to enforce stronger identity controls—even for users who never had a second factor. With Entra ID, you don’t need to re-onboard or manually fix each account. Just use the tools Microsoft provides to nudge, enforce, and protect.

And remember: centralizing authentication through Entra ID—across all apps—is foundational to a strong Zero Trust posture.