MFA registration does not move with the user — plan for the lockout
You migrate a user object into the new tenant and assume they can sign in. Then MFA prompts them, they have no method registered on this side, and they cannot reach the page that would let them register one. That loop is the single most common way a tenant cutover turns into a helpdesk flood.
New to cloud? CAMPUX is a free, build-first course. Start here →
This one is part of the Azure tenant-to-tenant migration guide, and it is the detail people skip until it bites them on switch day. Here is the fact that everything else hangs on: a user's registered authentication methods — Microsoft Authenticator, phone numbers, FIDO2 passkeys — live inside the tenant where they were registered. They do not come along when you move the account to a different tenant. The identity may look the same to the person, but as far as the target tenant is concerned, this user has registered nothing.
Why the methods stay behind
Registered methods are objects attached to the user in a specific directory. Move the user to a new tenant and you get a new user object, governed by that tenant's own Authentication methods policy — the setting that decides which methods anyone is even allowed to register there. None of the old registrations carry across. There is no supported button that copies someone's Authenticator enrollment or their phone factor from the source tenant into the target. Microsoft's own guidance treats target-tenant registration as a fresh action the user performs, not something the migration tooling does for you. So the honest planning assumption is simple: on the target side, everyone starts from zero registered methods.
On the target side, every migrated user starts with zero registered methods.
The chicken-and-egg lockout
Now put that fact next to a normal security posture. The target tenant has a Conditional Access policy that requires MFA to sign in — as it should. The migrated user shows up, enters their password, and the system asks for a second factor. They have none registered here. And they cannot get to the security info page to register one, because reaching that page requires passing the very MFA prompt they cannot answer. The requirement and the fix sit on opposite sides of the same locked door. Multiply that by a few hundred people at 9 a.m. on cutover day and you have a queue that no helpdesk staffs for.
The trap is worse because it is invisible in testing. A pilot user you set up by hand already has a method registered, so they sail through. It is only the bulk-migrated population — the ones nobody touched individually — who hit the wall. You do not discover it until the volume is real.
Temporary Access Pass is the bootstrap
The way out is a Temporary Access Pass (TAP): a time-limited passcode an admin issues to the user in the target tenant. Microsoft describes it as exactly this — a pass a user signs in with to onboard other authentication methods, and a recovery path when someone has lost or never had a strong method. The user enters the TAP, it satisfies the MFA requirement long enough to get them onto the security info page, and from there they register Microsoft Authenticator or a passkey the normal way. The circular dependency is broken because the TAP is the one credential that both counts as MFA and can be handed to someone who has nothing else.
Two settings decide how smooth this is. A TAP can be one-time or multi-use, and it has a lifetime you set in policy (Microsoft's default is one hour, configurable from ten minutes up to thirty days). A one-time pass forces the passwordless registration to finish within ten minutes of sign-in — fine for a supervised setup, tight for a distracted user reading an email. Many migration teams enable a multi-use pass with a lifetime that spans the workday, so a person can start, get interrupted, and come back without a fresh code.
A TAP only works if the target tenant is set up for it. An Authentication Policy Administrator has to enable Temporary Access Pass in the Authentication methods policy and scope it to the migrating users — a pass created for someone outside that scope simply will not sign them in. Then an Authentication Administrator (or Privileged Authentication Administrator, for admin accounts) generates the passes. Order matters: switch the policy on first, confirm the scope, then create passes. Get that backwards and every early pass fails for a reason that looks like a bug.
Timing and comms so switch day holds
The failure mode is a flood, so the fix is spreading the load and telling people what to expect. Do not surprise anyone. Send the re-registration instructions and a short screenshot walkthrough before cutover, so the first time a user sees the flow is not the first time they hear of it. Stage the passes rather than dumping the whole company in at once — migrate and onboard in waves, and generate each wave's passes close to when those users will actually sign in, since a pass burns its lifetime from the moment it becomes valid. Keep the helpdesk stocked with the ability to issue a replacement pass on the spot, because some people will fumble the first one. And decide up front how you deliver the code: a pass sent to the old mailbox is useless if the mailbox moved too, so many teams hand codes out through a manager or a separate channel the user can still reach.
The takeaway
Registered MFA methods are tenant-bound and do not migrate — treat every user as unregistered on the target side. The predictable consequence is a lockout wherever MFA is required before a method exists, and the standard answer is a Temporary Access Pass: enable it in the target's Authentication methods policy, scope it, issue passes in waves, and tell users how to re-register before they need to. Do that and switch day is a series of two-minute self-service registrations. Skip it and it is a queue at the helpdesk that starts the moment you flip the switch.
Questions people also ask
Do MFA methods transfer between tenants in a migration?
No. A user's registered methods — Microsoft Authenticator, phone numbers, FIDO2 passkeys — are bound to the tenant they were registered in. They are not copied when you move a user object to a new tenant. The person has to register fresh in the target tenant, and until they do, the target has no method it can prompt them for.
What is a Temporary Access Pass used for in a tenant migration?
A Temporary Access Pass is a time-limited passcode an admin issues in the target tenant. The migrated user signs in with it once, which satisfies the MFA requirement long enough to reach the security info page and register a real method like Authenticator or a passkey. It is the standard way to break the lockout where MFA is required but nothing is registered yet.
Why do users get locked out after a tenant migration?
Because the target tenant's Conditional Access requires MFA, but the migrated user has no method registered there yet. The system asks for a second factor, the user has nothing to answer with, and they cannot reach the registration page without passing the same MFA prompt. That circular dependency is the lockout, and it is entirely predictable if you plan for it.
Can a Temporary Access Pass register Microsoft Authenticator and passkeys?
Yes. Microsoft documents signing in with a TAP to onboard passwordless methods, including registering Microsoft Authenticator and passkeys (FIDO2) directly. A one-time TAP requires the passwordless registration to finish within ten minutes of sign-in; a multi-use TAP does not carry that ten-minute limit, which is why many teams prefer multi-use passes on switch day.
Who can issue a Temporary Access Pass?
An Authentication Administrator can create a TAP for members, and a Privileged Authentication Administrator can create one for admins and members. Before any pass works, an Authentication Policy Administrator has to enable Temporary Access Pass in the target tenant's Authentication methods policy and scope it to the users who need it. Enable the policy first, then issue passes.