Entra External ID (CIAM) custom domain — OIDC discovery `issuer` field not updating to custom domain after 3+ days

Question

Entra External ID (CIAM) custom domain — OIDC discovery `issuer` field not updating to custom domain after 3+ days

Brad-3588 40

Service: Microsoft Entra External ID (CIAM)

Feature: Custom URL domain for CIAM tenant

Summary:

I enabled a custom URL domain on a CIAM (External ID) tenant. DNS (CNAME to Azure Front Door) and TLS (Azure Managed Certificate) have been live and resolving correctly since activation. The OIDC discovery document is reachable at the custom domain and three of its four key fields have already updated to reflect it — but the issuer field has not, after more than 3 days.

Discovery doc URL pattern:

`https://

Brad-3588 40 Reputation points

2026-07-22T08:59:51.2333333+00:00
Thanks again for the detailed guidance — the cache test and request-ID capture were both really useful next steps.

I see this thread is under Priority Community Support (PCS). My understanding from the PCS documentation is that when an issue can't be resolved through the Q&A platform, the engineer handling it will escalate and create a support ticket on the customer's behalf. It's now been 22 hours since your last response, and I haven't been contacted to open a formal ticket yet.

Could you clarify the process from here? Specifically:

Does the PCS escalation to a formal support ticket happen automatically, or is there something further I need to do to trigger it?

Roughly what timeline should I expect to be contacted, given this has already been confirmed as a backend/tenant configuration issue rather than something resolvable on the community side?

Happy to provide anything further that would help move this along — the request-ID/timestamp pairs and full discovery document details are ready whenever needed.
Michele Ariis 7,315 Reputation points MVP Volunteer Moderator

2026-07-22T09:45:05.38+00:00

Hi Brad; you are correct that PCS provides escalation to a formal support ticket when an issue requires backend investigation; however, the escalation is not triggered automatically by a community answer and, as an MVP and Volunteer Moderator, I cannot create or initiate the ticket myself.

A Microsoft support engineer assigned to the PCS thread needs to review the case and start the escalation; the documented initial response target is within eight business hours, but Microsoft does not publish a separate guaranteed timeline for creating the support ticket; since you have already provided enough evidence that this requires tenant-side investigation, I will flag the thread for Microsoft review.

Please keep the request IDs, UTC timestamps and discovery document details ready; once the ticket is created, the support engineer should contact you directly for that information.
Brad-3588 40 Reputation points

2026-07-22T09:50:11.67+00:00

Thanks for the clarification on how the escalation actually works — that's helpful to understand, and I appreciate you flagging the thread for Microsoft review given you can't initiate the ticket yourself as a moderator.

I'll keep the request IDs, UTC timestamps, and full discovery document details ready and will watch for direct contact from the support engineer once the ticket is created. Really appreciate the time you've put into this — the caching test and the framing around it being a tenant-side/backend issue rather than DNS or Front Door has been valuable regardless of how the formal ticket timeline shakes out.
Sindhuja Dasari 2,115 Reputation points Microsoft External Staff Moderator

2026-07-22T12:28:12.0566667+00:00

Hello @Brad-3588

Thank you for reaching out to Microsoft Q&A community.

I have initiated a private message with you. Please provide required details
Brad-3588 40 Reputation points

2026-07-22T12:54:24.29+00:00

@Sindhuja Dasari
Thanks for your response. I haven't been able to locate the private message — I don't see it on the Q&A board, and I've also checked both my email and the Azure Portal for a service request with no luck.

Could you point me to where the private message should appear? Once I can access it, I'll provide the additional details right away.

Answer accepted by question author

Saravana Kumar D 170 Microsoft External Staff Moderator

Hello @Brad-3588

Based on your confirmation and the findings from the Microsoft Entra External ID product team, this behavior is expected and works by design.

The team confirmed that the OIDC issuer for a CIAM tenant remains tied to the tenant identity and continues to use the Microsoft-managed issuer endpoint, even after a custom URL domain has been successfully configured.

In other words, seeing the issuer continue to reference the tenant's Microsoft-managed issuer endpoint is expected.

The custom domain only affects user-facing endpoints such as the authorization endpoint, token endpoint, logout endpoint, and the browser sign-in experience. It does not change the issuer value returned in the OpenID Connect discovery document.

As a result, the following state is the expected final outcome:

Discovery document is accessible through the custom domain.
Authorization, token, and logout endpoints use the custom domain.
The issuer continues to reference the tenant's Microsoft-managed issuer endpoint.

This is not related to propagation delays, a backend issue, or a tenant configuration problem, and no additional action is required on the tenant.

For applications consuming the metadata, we recommend trusting the issuer returned by the discovery document and avoiding validation logic that requires the issuer host to match the custom domain host.

For customers using MSAL.js with a custom domain and encountering ClientAuthError: endpoints_resolution_error, ensure that both the custom domain and the corresponding issuer host returned by the metadata endpoint are included in the knownAuthorities configuration. This allows MSAL to trust the issuer returned by the metadata endpoint.

Thank you.

0 comments

2 additional answers

Your answer

Brad-3588 40 Reputation points

2026-07-22T08:59:51.2333333+00:00

Thanks again for the detailed guidance — the cache test and request-ID capture were both really useful next steps.

I see this thread is under Priority Community Support (PCS). My understanding from the PCS documentation is that when an issue can't be resolved through the Q&A platform, the engineer handling it will escalate and create a support ticket on the customer's behalf. It's now been 22 hours since your last response, and I haven't been contacted to open a formal ticket yet.

Could you clarify the process from here? Specifically:

Does the PCS escalation to a formal support ticket happen automatically, or is there something further I need to do to trigger it?

Roughly what timeline should I expect to be contacted, given this has already been confirmed as a backend/tenant configuration issue rather than something resolvable on the community side?

Happy to provide anything further that would help move this along — the request-ID/timestamp pairs and full discovery document details are ready whenever needed.
Michele Ariis 7,315 Reputation points MVP Volunteer Moderator

2026-07-22T09:45:05.38+00:00

Hi Brad; you are correct that PCS provides escalation to a formal support ticket when an issue requires backend investigation; however, the escalation is not triggered automatically by a community answer and, as an MVP and Volunteer Moderator, I cannot create or initiate the ticket myself.

A Microsoft support engineer assigned to the PCS thread needs to review the case and start the escalation; the documented initial response target is within eight business hours, but Microsoft does not publish a separate guaranteed timeline for creating the support ticket; since you have already provided enough evidence that this requires tenant-side investigation, I will flag the thread for Microsoft review.

Please keep the request IDs, UTC timestamps and discovery document details ready; once the ticket is created, the support engineer should contact you directly for that information.
Brad-3588 40 Reputation points

2026-07-22T09:50:11.67+00:00

Thanks for the clarification on how the escalation actually works — that's helpful to understand, and I appreciate you flagging the thread for Microsoft review given you can't initiate the ticket yourself as a moderator.

I'll keep the request IDs, UTC timestamps, and full discovery document details ready and will watch for direct contact from the support engineer once the ticket is created. Really appreciate the time you've put into this — the caching test and the framing around it being a tenant-side/backend issue rather than DNS or Front Door has been valuable regardless of how the formal ticket timeline shakes out.
Sindhuja Dasari 2,115 Reputation points Microsoft External Staff Moderator

2026-07-22T12:28:12.0566667+00:00

Hello @Brad-3588

Thank you for reaching out to Microsoft Q&A community.

I have initiated a private message with you. Please provide required details
Brad-3588 40 Reputation points

2026-07-22T12:54:24.29+00:00

@Sindhuja Dasari
Thanks for your response. I haven't been able to locate the private message — I don't see it on the Q&A board, and I've also checked both my email and the Azure Portal for a service request with no luck.

Could you point me to where the private message should appear? Once I can access it, I'll provide the additional details right away.

Answer 1

Michele Ariis 7,315 MVP Volunteer Moderator

Hi Brad; after more than three days, with DNS, TLS and the other discovery endpoints already updated, I would not consider this a normal propagation delay; it looks more like the custom domain activation has only been partially applied on the backend.

The issuer value must remain consistent with the authority used by the client; otherwise MSAL correctly rejects the metadata during endpoint discovery; Microsoft describes the custom URL domain as replacing the default ciamlogin.com host for the authentication endpoints, so having only the issuer still referencing the default domain appears inconsistent with the expected configuration.

I am not aware of any documented way to view the propagation status or manually trigger a refresh for the issuer metadata; I would first test the discovery document without any local or CDN cache, for example from another network and with a unique query string, and confirm that Azure Front Door is not caching the metadata response.

If the issuer still points to ciamlogin.com, I think a support case is the correct next step; include the tenant ID, custom domain, activation time, full discovery document, response headers and correlation details from the MSAL failure; keeping production temporarily configured with the default authority also seems like the safest workaround, rather than disabling issuer validation.

Brad-3588 40 Reputation points

2026-07-21T10:42:54.4733333+00:00

Thanks for the quick and thorough reply — really helpful.

I re-tested the discovery document with a cache-busting query string and no-cache headers to rule out a stale CDN copy before going further. The response headers confirm this is a live, uncached response straight from the origin:
X-Cache: CONFIG_NOCACHE

x-ms-ests-server: 2.1.24860.5 - NCUS ProdSlices

x-ms-request-id: <unique-per-request-id>

X-Cache: CONFIG_NOCACHE shows Front Door isn't caching this response, and x-ms-ests-server shows it's being generated live by the ESTS auth service each time. issuer is unchanged — still pointing at the default <tenant-id>.ciamlogin.com host.

So this does look like it's on the backend/tenant-config side rather than a caching artifact, as you suspected. Appreciate the pointer — saved me from chasing a caching red herring.
Michele Ariis 7,315 Reputation points MVP Volunteer Moderator

2026-07-21T12:33:45.7266667+00:00

Thanks for confirming and for sharing the response headers; that rules out the caching side quite clearly and points to the tenant configuration or ESTS backend.

At this stage I would open a Microsoft support case and include one or two recent x-ms-request-id values together with the exact UTC timestamp of each request; that should allow the engineering team to trace the requests on their side.

I would also mention that the custom domain has been active for more than three days, that all the other discovery endpoints are already returning the custom domain and that only the issuer value is still using ciamlogin.com; this should help them understand that it is a partial backend configuration issue rather than a DNS or Front Door problem.

Keeping production on the default authority until the issuer is corrected is definitely the safest approach; thanks again for posting the additional details, they will also be useful for anyone else running into the same issue.

Answer 2

Resolved — the issuer staying on ciamlogin.com is by design, not a propagation bug.

Microsoft's Entra External ID product team confirmed this via support case the OIDC issuer for a

CIAM tenant is tied to the tenant, not the hostname. It will always be

https://{tenantId}.ciamlogin.com/{tenantId}/v2.0, regardless of any custom URL domain. A custom domain only changes the

user-facing endpoints (authorization_endpoint, token_endpoint, end_session_endpoint, and the browser address bar) — it

does not, and never will, change the issuer.

So the state I described — 3 of 4 discovery fields on the custom domain, issuer still on ciamlogin.com — is the

correct, intended end state, not partial propagation. There is nothing to wait for and nothing to fix on the

tenant/backend side. (Thanks to @Michele Ariis and @Sindhuja Dasari for the help getting this escalated.)

What this means for relying parties (the actual fix):

Your app must accept the ciamlogin.com issuer. A discovery-based library reads it from the metadata automatically — so

do not hard-code the custom domain as the expected issuer, and don't validate issuer == authority host.

If you're on MSAL.js and hitting ClientAuthError: endpoints_resolution_error with a custom domain, the specific fix is

to add the tenant's ciamlogin GUID issuer host to knownAuthorities. As of @azure/msal-browser ≥ 5.11 (PR #8595, "Rule

5"), the issuer host is trusted only if it's listed there:

const pca = new PublicClientApplication({

auth: {

  clientId: "<client-id>",

  // custom domain in the path uses the tenant ID (GUID), per the custom-URL-domain docs

  authority: "https://login.contoso.com/<tenant-id>",

  knownAuthorities: [

    "login.contoso.com",           // your custom domain host

    "<tenant-id>.ciamlogin.com"    // the ciamlogin issuer host every token actually carries

  ]

}
```  });

  The default *.ciamlogin.com authority works without the extra entry because it's a built-in trusted Microsoft host; a

  custom domain host is not, so the ciamlogin issuer host must be listed explicitly.

Saravana Kumar D 170 Reputation points Microsoft External Staff Moderator

2026-08-17T08:59:44.95+00:00

Hello Brad,

Greetings!

Thank you for the detailed update and for sharing the resolution from the product team. I understand that the ciamlogin.com issuer behavior is by design, and no further backend action is required.

As you've confirmed that the issue is resolved we are proceeding with closing the case.

Thank you.