Conditional Access blocking Security Info Registration (mysignins.microsoft.com) with BadRequest error

Question

Hi everyone,

I'm facing an issue with Azure AD (Entra ID) where users are unable to complete the Security Info Registration (MFA/SSPR setup) process.

After resetting a user's password, upon login they are prompted to "Keep your account secure". However, instead of proceeding with MFA setup, they receive the following error:

• Error**:** BadRequest
• URL: https://mysignins.microsoft.com/register
• Message: "This might be due to timeout or something else. Please try again or contact your admin."

I have my CA policy created for this group and in that group is my test user.

I have a policy configured as follows:

• Assignments:
  • Users: Targeted users (test user included)
  • Cloud apps: All cloud apps
• Grant control: Block access
• Exclusions (Cloud apps):
  • Windows 365
  • Azure Virtual Desktop
  • Azure Windows VM Sign-In
  • Microsoft App Access Panel

MY questions is:

1. Are there any additional cloud apps or endpoints required to allow:
   • mysignins.microsoft.com
2. Could another hidden Conditional Access policy or Security Defaults be interfering?

Note: I have configured two CA policy, one for Block with this excluded apps and one with included this app that a wrote up there.

Thanks!

Dragan Gataric

Answer 1

Dragan Gataric

Thank you for your reply.

1) Why your “What If” tool can’t find Register security information

In your screenshot, the Target resource → Select target type dropdown is set to Cloud apps. In that mode, User actions won’t appear.

Microsoft documents that Target resources can be applications/services OR user actions (for example, “Register security information”).

For your reference: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-cloud-apps?tabs=powershell

What to do

Go to Entra admin center → Protection → Conditional Access → What If.

Under Target resource, change Select target type from Cloud apps to User actions.

Then select Register security information.

If you follow those exact steps, the option should appear because it’s the documented way to target combined registration

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-registration-mfa-sspr-combined

2) The correct Conditional Access design for MFA/SSPR registration

Recommended: A dedicated policy targeting the User action

Microsoft’s guidance for securing security info registration is to create a policy that targets User actions → Register security information, then apply the grant control you want (MFA/auth strength, trusted locations, etc.).

Create/confirm this policy (baseline)

Assignments → Users: your test group (plus exclusions for break-glass accounts).

Target resources: User actions → Register security information

Grant: typically Require multifactor authentication (or an authentication strength).

(Optional but common) Locations: exclude trusted locations or require registration only from trusted locations.

Docs:-

https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-registration-mfa-sspr-combined

3) Fix your “Block all cloud apps” policy so it stops breaking registration

Because your block policy targets “All cloud apps” + Block access, it can still collide with registration redirects and token issuance that happen as part of the combined flow. Internally, the registration flow relies on Conditional Access evaluation for the registration “action” and can require specific claims to proceed; blocking broadly often results in the type of generic failure you’re seeing.

Safer pattern

Keep your Block all cloud apps policy, but exclude your test users while you validate the registration policy. (Use a temporary exclusion group.)

Turn the block policy Report-only during testing so you can see the impact without hard blocks. Microsoft recommends phased rollout/testing for CA changes.

Ensure you have the dedicated User action: Register security information policy enabled

https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access

https://supportability.visualstudio.com/AzureAD/_wiki/wikis/AzureAD/184085/Azure-AD-Conditional-Access-for-Credential-Registration

4) Use Sign-in logs the right way (your screenshot is showing “Windows 365 Portal”)

Your sign-in log screenshot shows Application: Windows 365 Portal. That may not be the actual registration event for mysignins.microsoft.com/register — it could be a related sign-in (or a different step) rather than the registration “user action” evaluation. The right approach is to find the failed event at the time of the BadRequest and open the Conditional Access tab for that event.

Microsoft’s troubleshooting doc confirms:

You can drill into the event and see which policy applied/failed.

53003 = BlockedByConditionalAccess is a common error for CA blocks.

Use Sign-in diagnostic from the event when needed.

What to do

Entra admin center → Sign-in logs.

Filter by the affected user and the failure time.

Open the relevant failed sign-in and go to the Conditional Access tab.

Identify policies with result Failure and confirm which one is enforcing Block.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access

5) Could Security Defaults be interfering?

Usually, Security Defaults and Conditional Access aren’t meant to run together — Microsoft states you can’t enable security defaults if you have Conditional Access policies enabled, and vice-versa. So in most tenants, if CA policies are active, Security Defaults should already be off (or not enable-able).

Still, it’s worth checking Entra ID → Properties → Manage security defaults, but don’t expect it to be simultaneously enforcing if CA is active

https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-secure-sign-in?view=o365-worldwide

Answer 2

mysignins.microsoft.com uses the “Register security information” user action, not a specific cloud app. A broad Block access policy on All cloud apps can interfere with this flow unless it is explicitly excluded or a dedicated “Register security information” policy is configured correctly.

Use the following checks and adjustments:

1. Verify which Conditional Access policy is blocking the registration
   1. Sign in to the Microsoft Entra admin center as at least a Reports Reader.
   2. Go to Entra ID > Monitoring & health > Sign-in logs.
   3. Filter for the affected user and time of the failure. Add the Conditional Access filter and scope it to failures.
   4. Open the failed sign-in event and select the Conditional Access tab to see exactly which policy (or policies) applied and whether they resulted in a block.
   5. Use More Details and Troubleshooting and support to confirm the reason (for example, BlockedByConditionalAccess).
   6. If needed, click the policy name from the sign-in event to open its configuration directly for review/editing.
   This confirms whether the “Block access” policy or another policy is causing the BadRequest experience.
2. Check for policies targeting the “Register security information” user action
   1. In Entra ID > Conditional Access > Policies, open each policy that might affect registration.
   2. Under Target resources, check if User actions is configured with Register security information.
   3. If a policy targets Register security information and has Grant set to Block access, it will block the MFA/SSPR registration page regardless of cloud app exclusions.
   4. Adjust as needed:
      • For securing registration, use a dedicated policy that targets Register security information and grants access with controls like Require multifactor authentication, instead of blocking.
      • Ensure any broad Block access policies do not include the Register security information user action.
   Reference behavior for this user action is described in the User actions section of Conditional Access.
3. Confirm that the “Block access” policy is not unintentionally catching registration Since the current policy:
   • Targets All cloud apps with Block access, and
   • Only excludes specific apps (Windows 365, AVD, Azure Windows VM Sign-In, Microsoft App Access Panel),
   any sign-in or token request not matching those exclusions can be blocked, including the security info registration flow. Actions:
   • Temporarily set the policy’s Enable policy toggle to Report-only or No to validate whether the error disappears (as described in the “Problems with Conditional Access policies” section).
   • If confirmed, either:
     • Narrow the policy’s Cloud apps to only the apps that truly need to be blocked, or
     • Add a separate policy that explicitly allows the Register security information user action with appropriate controls, and ensure the blocking policy does not conflict.
4. Check for other Conditional Access policies or Security Defaults
   • In Entra ID > Conditional Access > Policies, review all policies for:
     • Assignments that include the affected user.
     • Cloud apps = All cloud apps or user actions.
     • Grant = Block access.
   • Use the sign-in event’s Conditional Access tab to see the full list of evaluated policies and which ones actually applied.
   • If locked out by a misconfigured policy and no other admin can sign in, follow the documented guidance to have another admin disable the policy or open a support request so Microsoft can adjust the blocking policies.
5. Recommended pattern for securing security info registration
   • Create a dedicated policy that:
     • Targets User actions > Register security information.
     • Applies to the required users.
     • Uses Grant controls like Require multifactor authentication instead of Block access.
   • Optionally, for guest users, use a policy that targets All guest and external users and Register security information, and then restrict locations (for example, block registration from outside trusted locations) as shown in the guest user registration example.

This approach ensures mysingins.microsoft.com registration flows are allowed and controlled, while other access remains governed by the broader Conditional Access policies.

---

References:

• Troubleshoot sign-in problems with Conditional Access
• Conditional Access: Target resources
• Protect security info registration with Conditional Access policy
• Plan a Conditional Access deployment
• Problems signing in to a Microsoft application