AADSTS50196 on security-info registration when amr_values=ngcmfa is required but no usable method exists

Question

Looking for guidance on a security-info registration behavior in Entra ID.

Admin accounts in a tenant are prompted with "Let's keep your account secure" at sign-in. The registration flow loops and terminates with AADSTS50196 LoopDetected. The Authenticator challenge is never reached. Reproduced across multiple devices, browsers, private sessions, and networks. Non-admin users sign in normally, so this appears to be service-side rather than client-side.

Inspecting the authorize request from My Sign-Ins, it is issued with amr_values=ngcmfa and an essential acrs claim of urn:user:registersecurityinfo. That appears to require fresh MFA as a precondition for registering an MFA method, which an account with no usable method cannot satisfy.

Questions:

1. Under what conditions does the registration flow require ngcmfa rather than allowing the interrupt registration path? Does an existing but unusable registered method cause this?
2. Does a Conditional Access policy targeting the Register security information user action produce this same deadlock, and how is that distinguished in sign-in logs?
3. Is a Temporary Access Pass the supported remediation for this state, and does TAP satisfy the ngcmfa requirement?
4. If the Authentication methods policy has only one method enabled tenant-wide while admin sign-in requires two, does that reproduce this exact behavior?

There is an open support case on this. Happy to share tenant and correlation identifiers privately with a moderator rather than posting them here.

Answer 1

Hello Sean Green,

Greetings! Thanks for raising this question in the Q&A forum.

This is a known deadlock pattern in the Register Security Info flow, and it lines up with how the registersecurityinfo user action interacts with the Authentication Methods policy and Conditional Access. Here is what is happening and how each of your four questions maps to the underlying mechanics.

Why ngcmfa is required instead of the normal interrupt path. The registersecurityinfo action is treated by Entra as a sensitive operation, and if the account's current Authentication Methods policy or an applicable Conditional Access grant control requires a strong or specific authentication strength before registration is allowed, the authorize request is issued with amr_values=ngcmfa as an essential claim rather than falling back to the softer interrupt registration path. An existing but unusable registered method (for example a method the tenant has since disabled at the policy level, or a method tied to a device the admin no longer has) does not get treated as satisfying this, because the token service only accepts currently policy-permitted methods for the ngcmfa claim, not whatever the user happens to already have configured. This produces exactly the loop you are seeing: the service demands fresh strong authentication to reach the registration page, but the only method the account can present is not accepted as satisfying that authentication, so the flow cycles until it terminates with AADSTS50196 LoopDetected.

Whether Conditional Access targeting Register security information produces the same deadlock. Yes, this is one of the most common causes. A Conditional Access policy scoped to the "Register security information" user action, combined with a grant control requiring an authentication strength (particularly phishing-resistant MFA) that the account has no way to satisfy yet, creates the identical loop. In sign-in logs this is distinguishable from a pure Authentication Methods policy issue by checking the Conditional Access tab on the failed sign-in event. If a named CA policy shows as applied with a "Grant" requirement tied to authentication strength, that confirms CA is the trigger. If no CA policy is listed as applied and the block still traces to the registersecurityinfo acrs claim, the cause sits in the Authentication Methods policy itself rather than CA.

Whether TAP is the supported remediation and whether it satisfies ngcmfa. Yes. A Temporary Access Pass is explicitly designed as the supported bridge for this exact scenario, since it satisfies the strong authentication requirement and is recognized as an MFA-equivalent method for the purpose of completing registration of a new authenticator. TAP is accepted as satisfying the ngcmfa claim precisely because it is intended to onboard passwordless and phishing-resistant methods when no existing usable method is available.

Whether a single-method Authentication Methods policy combined with a two-method admin sign-in requirement reproduces this. Yes, this is a very plausible independent trigger. If the tenant-wide Authentication Methods policy currently has only one method enabled, but the applicable Conditional Access authentication strength or per-role requirement for admin accounts demands two distinct methods, an admin who only has the single enabled method registered has no way to satisfy the second-factor requirement through self-service, and the registration attempt loops for the same structural reason as in question 1. Checking whether admin sign-ins specifically enforce a stricter authentication strength than the general tenant policy will confirm this.

Given you already have an open support case with correlation IDs, the fastest resolution path is for a Global Administrator to issue a TAP to the affected admin accounts through Entra ID, Users, Authentication methods, Add authentication method, Temporary Access Pass, then have the admin use that TAP to complete registration of a policy-compliant method. If the affected accounts are themselves the only admins able to issue a TAP, this becomes a sole-admin style lockout and needs to go through Microsoft support for a TAP to be issued on the backend.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.