Entra ID's MFA setup is driving me nuts. We pay for the license, but it lets users add their own personal phone numbers and authenticator apps for verification. This is a huge security hole.
I need to lock it down. How do you stop users from registering their own methods? I only want admins to control this. The portal settings are confusing and seem to push you toward letting users manage it. Is there a straightforward policy or setting to block this?
You need the registration campaign feature. It's in the legacy MFA portal, not the Entra auth methods page.
Create a new campaign, set it to block user registration. Push it to your groups. They'll get a message saying admins must register methods for them.
It's clunky but works. The new UX hides this intentionally because Microsoft wants users to self-serve.
slow pipelines make me cranky
Wait, this is exactly the setting I've been hunting for. So you're saying the control moved to the *legacy* portal? That explains why I couldn't find it.
If they're hiding it to push self-service, what's the long-term plan? Are they going to deprecate this campaign feature entirely?
We have a strict policy on approved methods only, so this could work. Thanks for the pointer.
Still learning.
Admin control only? Good luck. That "security hole" you're freaking out about is the feature.
If you lock this down, your help desk tickets for MFA resets will triple overnight. Users will start writing passwords on sticky notes just to avoid calling you.
Registration campaigns are deprecated for a reason. Microsoft isn't hiding it to be sneaky, they're phasing it out because it's a terrible user experience. You're fighting the platform.
That security hole is the whole point of MFA. If you control the methods, you become the single point of failure for resets. Now you're responsible for verifying every user's identity over the phone, a process arguably easier to social engineer than a stolen phone.
You're paying for a managed service but want to run it like an on-prem fortress. That mismatch is going to cost you more in admin overhead than any perceived security gain.
Your vendor is not your friend.
You're mixing up threat models. The security hole isn't a user's registered phone, it's an ungoverned method outside your visibility.
If the help desk reset process is weak enough to be social engineered, that's the process you fix. Letting users silently add personal methods you can't audit just creates a different shadow IT problem. The trade-off isn't just admin overhead vs security, it's about having an accurate inventory of auth factors for compliance.
Deprecating admin control doesn't solve the core issue, it just moves it.
Show me the query.
So the registration campaign in the legacy portal is the official way to do this? I've been looking in the new interface too and it's not there. That seems like a big oversight if they're planning to retire the legacy feature.
How are you handling it now? Does blocking user registration actually stop the prompts on their end, or do they just get errors?
> registration campaign in the legacy portal is the official way to do this?
It's the *current* way, not the official way. Official means supported long-term. Microsoft has been clear: legacy MFA portal is on the chopping block. Using a deprecated feature to fight the platform direction isn't a strategy, it's a time bomb.
> oversight if they're planning to retire the legacy feature
It's not an oversight. It's deliberate. They want self-service to be the only path. The old campaign settings exist because killing them before the new UX has equivalent controls would break too many orgs. But once the new auth methods policy fully catches up, that legacy portal is gone. You're betting your compliance on that gap closing slower than your audit cycle.
To answer your last question: yes, blocking user registration via the campaign actually stops the prompts. Users see an error saying their admin must register the method. So you're trading a self-service prompt for a help desk call that often ends with "just give me any phone number" anyway. If your help desk identity verification is solid, go for it. If not, you just moved the attack surface from a phone to a voice call.
Just my 2 cents