AADSTS500207 "The account type can't be used for the resource you're trying to access" — Credential Management API, External ID (CIAM) tenant

Goal: I'm setting up Passkey (FIDO2) support for customer sign-in on a Power Pages portal, using Microsoft Entra External ID (CIAM) as the identity provider. Current authentication is email + password as the primary method, with email one-time passcode (OTP) as the MFA/second factor. I want customers to be able to register and use a passkey as a phishing-resistant alternative to password + OTP, following Microsoft's documented approach for this (Credential Management API + a custom self-service page, since External ID doesn't provide a built-in hosted registration screen for customer accounts).

Problem: Every attempt to acquire a token for the passkey API from my custom page fails with AADSTS500207, even with a properly configured setup — details below.

Summary

Building a customer-facing passkey self-service registration page (Power Pages + Entra External ID, per Microsoft's own documented pattern for this scenario). Every delegated token request against the Credential Management API resource fails with AADSTS500207, regardless of account type, creation method, or consent state. Extensive elimination (detailed below) rules out every client-side and account-side cause I have access to fix.

Environment

• Tenant type: Microsoft Entra External ID (CIAM), external tenant
• Frontend/calling app: single-tenant app registration (signInAudience: AzureADMyOrg) — confirmed this is the required configuration for CIAM per Microsoft's own guidance
• Resource being called: Microsoft's own first-party Credential Management API (service principal Me-CredentialProfileManagement) — we only hold a service principal reference in our tenant, not an editable App Registration, since it's Microsoft-owned
• Resource's signInAudience: AzureADandPersonalMicrosoftAccount (confirmed via Graph query on the service principal)
• Auth library: MSAL.js v3.7.1 (self-hosted, browser-direct SPA flow — no backend involved in this token request)
• Documented reference implementation: Microsoft's own "Sign in with passkeys" article for external tenants (learn.microsoft.com/entra/external-id/customers/how-to-sign-in-with-passkey), Step 3: "Build a passkey management experience for your application ... Use the FIDO2 provisioning APIs." The article explicitly confirms there is no out-of-box/hosted registration experience for external tenants — this API + custom UI is the only documented self-service path.

The failing request

GET https://{your-tenant}.ciamlogin.com/{tenant-id}/oauth2/v2.0/authorize
  ?client_id={frontend-app-client-id}
  &scope=api%3A%2F%2F{credential-mgmt-api-app-id}%2FMe.UserAuthenticationMethod.Passkey.ReadWrite%20openid%20profile%20offline_access
  &redirect_uri=https%3A%2F%2F{our-site}%2FPasskey-Management-Page%2F
  &response_mode=fragment
  &response_type=code
  &prompt=none (or popup, same result either way)
  &code_challenge=...&code_challenge_method=S256

Response:

error=invalid_request
&error_description=AADSTS500207: The account type can't be used for the resource you're trying to access.

What's been eliminated

• ✅ Redirect URI — exact match confirmed against the SPA platform entry on the app registration
• ✅ Authority format — includes /v2.0 suffix per CIAM requirement
• ✅ Scope string — copied directly from the resource's own oauth2PermissionScopes array, byte-for-byte
• ✅ Delegated permission granted + admin-consented — the passkey ReadWrite scope (Delegated) shows "Granted" on the frontend app registration
• ✅ Frontend app registration audience — confirmed single-tenant (AzureADMyOrg), which is the mandatory configuration for any CIAM app registration
• ✅ Account type — tested three ways, same result every time:
  1. Account manually created via Entra admin center "New user" (userType: Member, UPN-based identity) — fails
     1. Account created via Graph API POST /users with explicit identities: [{signInType: "emailAddress", issuer: "{tenant}.onmicrosoft.com", ...}] — confirmed genuine local identity (auto-generated UPN pattern {guid}@{tenant}.onmicrosoft.com matches Microsoft's documented local-account creation pattern) — still fails
        1. Account created through the site's actual live self-service sign-up flow (real end-to-end customer registration path, isSignUpAllowed: true temporarily enabled) — genuinely production-equivalent local account — still fails
        • ✅ MFA — Conditional Access policy confirmed: Require MFA, targeting All users, policy enabled (not report-only); email OTP completed successfully before each test
        • ✅ User flow / app association — confirmed the frontend app is attached to an existing sign-up/sign-in user flow (verified via the "Run user flow" test panel, which also confirmed the Reply URL matches production sign-in)
        • ✅ Passkey (FIDO2) authentication method policy — confirmed enabled, targeting All users, with passkey profiles assigned and "Allow self-service set up" = Yes

What hasn't been eliminated (can't fix ourselves)

The resource's signInAudience: AzureADandPersonalMicrosoftAccount. Independent research surfaced a documented pattern (unrelated project's troubleshooting writeup) describing this exact error occurring when a called resource/backend app isn't configured single-tenant, with the fix being to reconfigure that resource's audience. In our case the resource is Microsoft's own first-party API — we have no access to its App Registration object (only a service principal reference exists in our tenant), so this fix isn't something we can apply ourselves even if it is the correct diagnosis.

Separately confirmed, likely-unrelated bug

Also encountered a known, Microsoft-acknowledged bug where local Member accounts get incorrectly routed through MSA/personal-account federation when isSignUpAllowed: false is set on the user flow — this matches a Microsoft Q&A thread with an engineer-confirmed root cause and a fix "scheduled to roll out." We don't believe this explains the 500207 itself, since the error reproduces identically with isSignUpAllowed: true and a genuine self-service-registered local account — but flagging it in case it's a contributing factor or of interest to anyone else hitting similar CIAM sign-in oddities.

Question for the community

Is AADSTS500207 expected/known when requesting a delegated token for the Credential Management API's custom scope from a genuine CIAM local account, given the resource's AzureADandPersonalMicrosoftAccount audience? Is there a tenant-level or app-registration-level setting on our side that resolves this, or is this a platform-side gap between the documented capability and current enforcement? Any confirmed working end-to-end example (tenant type + resource + exact scope string) would be hugely helpful to compare configurations against.Goal: I'm setting up Passkey (FIDO2) support for customer sign-in on a Power Pages portal, using Microsoft Entra External ID (CIAM) as the identity provider. Current authentication is email + password as the primary method, with email one-time passcode (OTP) as the MFA/second factor. I want customers to be able to register and use a passkey as a phishing-resistant alternative to password + OTP, following Microsoft's documented approach for this (Credential Management API + a custom self-service page, since External ID doesn't provide a built-in hosted registration screen for customer accounts).

Problem: Every attempt to acquire a token for the passkey API from my custom page fails with AADSTS500207, even with a properly configured setup — details below.

Summary

Building a customer-facing passkey self-service registration page (Power Pages + Entra External ID, per Microsoft's own documented pattern for this scenario). Every delegated token request against the Credential Management API resource fails with AADSTS500207, regardless of account type, creation method, or consent state. Extensive elimination (detailed below) rules out every client-side and account-side cause I have access to fix.

Environment

• Tenant type: Microsoft Entra External ID (CIAM), external tenant
• Frontend/calling app: single-tenant app registration (signInAudience: AzureADMyOrg) — confirmed this is the required configuration for CIAM per Microsoft's own guidance
• Resource being called: Microsoft's own first-party Credential Management API (service principal Me-CredentialProfileManagement) — we only hold a service principal reference in our tenant, not an editable App Registration, since it's Microsoft-owned
• Resource's signInAudience: AzureADandPersonalMicrosoftAccount (confirmed via Graph query on the service principal)
• Auth library: MSAL.js v3.7.1 (self-hosted, browser-direct SPA flow — no backend involved in this token request)
• Documented reference implementation: Microsoft's own "Sign in with passkeys" article for external tenants (learn.microsoft.com/entra/external-id/customers/how-to-sign-in-with-passkey), Step 3: "Build a passkey management experience for your application ... Use the FIDO2 provisioning APIs." The article explicitly confirms there is no out-of-box/hosted registration experience for external tenants — this API + custom UI is the only documented self-service path.

The failing request

GET https://{your-tenant}.ciamlogin.com/{tenant-id}/oauth2/v2.0/authorize
  ?client_id={frontend-app-client-id}
  &scope=api%3A%2F%2F{credential-mgmt-api-app-id}%2FMe.UserAuthenticationMethod.Passkey.ReadWrite%20openid%20profile%20offline_access
  &redirect_uri=https%3A%2F%2F{our-site}%2FPasskey-Management-Page%2F
  &response_mode=fragment
  &response_type=code
  &prompt=none (or popup, same result either way)
  &code_challenge=...&code_challenge_method=S256

Response:

error=invalid_request
&error_description=AADSTS500207: The account type can't be used for the resource you're trying to access.

What's been eliminated

• ✅ Redirect URI — exact match confirmed against the SPA platform entry on the app registration
• ✅ Authority format — includes /v2.0 suffix per CIAM requirement
• ✅ Scope string — copied directly from the resource's own oauth2PermissionScopes array, byte-for-byte
• ✅ Delegated permission granted + admin-consented — the passkey ReadWrite scope (Delegated) shows "Granted" on the frontend app registration
• ✅ Frontend app registration audience — confirmed single-tenant (AzureADMyOrg), which is the mandatory configuration for any CIAM app registration
• ✅ Account type — tested three ways, same result every time:
  1. Account manually created via Entra admin center "New user" (userType: Member, UPN-based identity) — fails
     1. Account created via Graph API POST /users with explicit identities: [{signInType: "emailAddress", issuer: "{tenant}.onmicrosoft.com", ...}] — confirmed genuine local identity (auto-generated UPN pattern {guid}@{tenant}.onmicrosoft.com matches Microsoft's documented local-account creation pattern) — still fails
        1. Account created through the site's actual live self-service sign-up flow (real end-to-end customer registration path, isSignUpAllowed: true temporarily enabled) — genuinely production-equivalent local account — still fails
        • ✅ MFA — Conditional Access policy confirmed: Require MFA, targeting All users, policy enabled (not report-only); email OTP completed successfully before each test
        • ✅ User flow / app association — confirmed the frontend app is attached to an existing sign-up/sign-in user flow (verified via the "Run user flow" test panel, which also confirmed the Reply URL matches production sign-in)
        • ✅ Passkey (FIDO2) authentication method policy — confirmed enabled, targeting All users, with passkey profiles assigned and "Allow self-service set up" = Yes

What hasn't been eliminated (can't fix ourselves)

The resource's signInAudience: AzureADandPersonalMicrosoftAccount. Independent research surfaced a documented pattern (unrelated project's troubleshooting writeup) describing this exact error occurring when a called resource/backend app isn't configured single-tenant, with the fix being to reconfigure that resource's audience. In our case the resource is Microsoft's own first-party API — we have no access to its App Registration object (only a service principal reference exists in our tenant), so this fix isn't something we can apply ourselves even if it is the correct diagnosis.

Separately confirmed, likely-unrelated bug

Also encountered a known, Microsoft-acknowledged bug where local Member accounts get incorrectly routed through MSA/personal-account federation when isSignUpAllowed: false is set on the user flow — this matches a Microsoft Q&A thread with an engineer-confirmed root cause and a fix "scheduled to roll out." We don't believe this explains the 500207 itself, since the error reproduces identically with isSignUpAllowed: true and a genuine self-service-registered local account — but flagging it in case it's a contributing factor or of interest to anyone else hitting similar CIAM sign-in oddities.

Question for the community

Is AADSTS500207 expected/known when requesting a delegated token for the Credential Management API's custom scope from a genuine CIAM local account, given the resource's AzureADandPersonalMicrosoftAccount audience? Is there a tenant-level or app-registration-level setting on our side that resolves this, or is this a platform-side gap between the documented capability and current enforcement? Any confirmed working end-to-end example (tenant type + resource + exact scope string) would be hugely helpful to compare configurations against.