The MFA registration loop, and the credential that breaks it

A new starter signs in and is told they have to register an authentication method before continuing. They go to register one, and Conditional Access blocks them because they have not completed multifactor authentication. Neither side gives way, and no amount of clearing cache, reinstalling the authenticator or resetting the password changes anything, because nothing is broken.

The registration experience is treated as a target in Conditional Access, so a policy written to require MFA everywhere requires it for the act of setting up MFA. That is the whole problem, and understanding it is what makes the fix obvious rather than lucky.

Why the policy blocks the page that would satisfy it

In Conditional Access, security information registration is not a cloud app. It is a user action, named Register security information, and it can be targeted like anything else. That design is deliberate and useful, because it lets an organisation say that registering a credential is a sensitive act that should only happen from a trusted network or a compliant device.

The failure comes from the broad policy rather than the specific one. A policy that requires multifactor authentication for all resources catches the registration action along with everything else, and a user with no registered method cannot satisfy it. Existing users are unaffected, which is why this almost always surfaces with a new starter or with somebody whose methods have just been reset.

Getting the person in today

The intended way out is a Temporary Access Pass. It is a time-limited credential an administrator issues, and the reason it resolves this specific problem is that it satisfies the Conditional Access multifactor requirement in its own right. The user signs in with it, reaches the registration page because the policy is now satisfied, and sets up their real method.

1. Confirm Temporary Access Pass is enabled as an authentication method in the tenant. It is a policy in its own right and is not on by default.
2. Issue a pass for the affected user from the Entra admin centre, and note the lifetime and whether it is single use.
3. Have the user sign in with the pass and go straight to their security information to register a permanent method.

   Do this while you are on the phone to them. A single-use pass consumed on the wrong page means issuing another one.

4. Confirm the permanent method works by having them sign in again without the pass before you close the ticket.

What changed on 6 July 2026

Worth knowing if your policies were written before then and have not been revisited. Until 6 July 2026, Windows Hello for Business and macOS Platform SSO credential registration did not evaluate policies targeting the registration user action. Those flows now do.

In practice that means a policy scoped to Register security information now applies to users enrolling Windows Hello for Business or Platform SSO credentials, and they have to satisfy its grant controls, whether that is an authentication strength, a trusted location or a specific method, before enrolment completes. A policy that was written narrowly and tested only against the combined registration page has a wider effect now than it did when it was signed off.

The nuance to keep hold of is that multifactor authentication was already required by default to register passwordless credentials, regardless of whether any policy existed. The change is not that a requirement appeared. It is that your policy's controls now apply to those enrolment flows too.

Writing the policy so this stops happening

The durable fix is a dedicated policy for the registration action rather than letting a catch-all policy cover it. Microsoft's reference approach requires multifactor authentication for registration attempted from anywhere other than a trusted location, and excludes trusted locations. That gives you a controlled registration experience without a closed loop, because the trusted-network path stays open for people who have nothing registered yet.

Two details in the construction are easy to get wrong. Users have to be enabled for the combined registration experience for the user action to behave as documented. And if your organisation uses external authentication methods, those are currently incompatible with authentication strength, so the grant control has to be the plain multifactor requirement instead. Choosing authentication strength in that environment produces a policy that blocks people for reasons that look nothing like the cause.

Deploy it in report-only mode first, read what it would have done, and only then turn it on. For a policy whose failure mode is preventing people from obtaining credentials, report-only is not caution, it is the only way to see the blast radius before it exists.

Accounts that have to be excluded

Independent of this particular loop, and the reason a bad policy is recoverable rather than terminal.

• Emergency access or break-glass accounts. If every administrator is locked out by a misconfiguration, this is what gets you back in. Excluded from the policy, credentials held securely, and tested occasionally so you find out it works before you need it.
• Service accounts. Non-interactive accounts not tied to a person, which fail in confusing ways under interactive policies. Where they exist in scripts, managed identities are the better answer than an exclusion.
• Guest and external users, for registration policies specifically, since the Temporary Access Pass remedy is not available to them.

One thing worth being precise about, because it is a common misreading: calls made by service principals are not blocked by Conditional Access policies scoped to users. Policies for workload identities are a separate feature. Excluding service accounts is about interactive sign-ins, not about application calls that were never in scope.