Entra External ID: Safari macOS signup returns AADSTS50021 after email OTP, before password creation

Hello,

Has anyone encountered an initial email/password signup failure specifically in Safari on macOS with Microsoft Entra External ID?

We use an external tenant with sign-up/sign-in user flows configured for email and password authentication.

Expected behavior

A new user selects Sign up, enters their email address, validates the email OTP, and then creates their password.

Actual behavior in Safari macOS

1. Start in a fresh browser session.
2. Select Sign up and enter a new email address.
3. Enter the email OTP and click Next.
4. Entra immediately redirects to the application's redirect URI, without displaying the password-creation form.

If I repeat the signup process in the same browser context, it can then display the password fields normally.

This also occurs when testing through the Entra portal's Run user flow feature, and has been observed in both DEV and PROD.

Browser comparison

• Safari on my Mac: reproduces the issue.
• Safari on a colleague's Mac: also reproduces it.
• Chrome on macOS: works in our tests, including Incognito.
• Safari on iOS: works in our tests.

For the recorded comparison:

• macOS 27.2, build 26B5091g
• Safari 27.2, build 22625.2.5.11.1
• Chrome 154.0.8037.92

Captured failure

Safari returned the following error in the redirect URI:

AADSTS50021: This is a self-service sign-up request in CIAM tenant

Timestamp: 2026-09-30 18:54:39Z

Trace ID: cfd7826a-1b91-4345-a6f3-28ba2b330800

Correlation ID: 8e936dc4-abc5-4846-8798-6624afca71e5

The matching Microsoft Graph signup audit event shows:

• signUpStage: credentialValidation
• status.errorCode: 50021

The Chrome comparison reached “Add details”, with “Password” and “Re-enter password” fields. Its matching event shows:

• signUpStage: credentialValidation
• status.errorCode: 1002013
• Additional details describe an expected interruption during local-account signup.
• Correlation ID: e7767f56-2421-409c-86ad-dbd3426a575e

Additional observations

After the OTP POST, Safari loaded a DetectBrowserCapabilities_Core script, while Chrome loaded an attribute-collection-fabric script and displayed the password form.

Chrome's authorization URL already contained sso_reload=true when recording started; Safari's did not. Recording began at the OTP screen, so we have not captured how this difference originated.

Our configuration includes custom authentication extensions for attribute submission and token issuance. We have not established whether they contribute to this issue.

Is this a known Safari/WebKit compatibility issue, or could a user-flow setting or browser-session initialization cause this behavior?

What diagnostics or supported workaround would you recommend?

Thank you.