ADB2C: Observed Intermittent Failures Retrieving Access Token on Feb 11 2026 (PST)

Question

ADB2C: Observed Intermittent Failures Retrieving Access Token on Feb 11 2026 (PST)

Mike Murphy 25

On 2/11 2026, observed some intermittent failures on the ADB2C service where the retrieval of the Access Token erroneously returned 'forbidden.' A workaround was to retry the authentication userflow until it succeeded. Suspect there are/were a few bad servers in the fleet.

I didn't see any service impact reports. We have customers who were blocked from signing in to our application, and we have nothing to respond with.

Was this a transient issue? Is there a backward compatibility issue with any recent updates? Are there investment issues that suggest we should seek other authentication mechanisms?

Thanks for any insight anybody can provide!

Mike

VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-12T19:36:59.68+00:00
Hi Mike Murphy, Thanks for the detailed report. Based on what you observed and what we can verify publicly, this looks like a short‑lived, tenant‑scoped backend issue in Azure AD B2C, not a config or backward‑compatibility problem.

What we can confirm

No service‑wide incident was posted for Azure AD B2C on Feb 11, 2026. The public Azure Status page showed no active events for B2C during that window.

Why your symptoms point to a platform‑side transient fault (not your app)

You saw intermittent 403 Forbidden at token retrieval that later succeeded without any change on your side — that pattern aligns with an internal, short‑duration service issue (for example, a subset of nodes misbehaving or a brief inconsistency during backend rollout) that didn’t cross the bar for a public incident.

On the suggested mitigations

You’re right that 403 isn’t, by itself, a clear retryable signal; Microsoft’s general Retry guidance targets transient classes (timeouts/408, throttling/429, and many 5xx), not authorization‑type responses like 403. Blind retries aren’t the solution in this scenario. It’s also expected that a non‑error HTTP response won’t surface a client‑visible correlation ID, and tenant‑level blips may not appear on the public status page—hence the lack of Service Health indicators for your case.

Answers to your specific questions

Was this a transient issue? Yes, the evidence points to a short‑lived, non‑reported transient backend fault that self‑resolved. Any backward compatibility issues with recent updates? No public documentation indicates B2C changes that would cause intermittent 403 during token acquisition. Do we need to consider other authentication mechanisms? No—this appears environmental and temporary rather than architectural. There’s no signal suggesting a strategic move away from Azure AD B2C is warranted based on this incident alone.

If this behavior recurs, share the approximate UTC timestamps and affected user flow/policy name and we can help craft the right escalation notes for Microsoft Support (tenant‑scoped telemetry can then be correlated on the backend even when the public page shows green).
Mike Murphy 25 Reputation points

2026-02-12T21:10:30.9333333+00:00
The recommended next steps are ill-advised, because:

'Forbidden' is typically not a clear retryable error, so retry logic is not a solution

There was no indication in Azure Service Health during this period, so there would be nothing to leverage for this condition

There was no Correlation ID because this was a non-error response--even though it was an incorrect response, likely due to an internal malfunction

I mention all this so others won't attempt this as a solution to a non-reported transient service fault.
VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-12T22:04:21.5266667+00:00
Mike Murphy Thanks for sharing this. I’ve updated my original response to reflect your points accurately.

You are absolutely right that:

403 Forbidden is not a retryable error, so retry logic would not apply here.

Azure Service Health did not show any incident, so there was no service‑side signal available.

The service returned a non‑error HTTP response without a Correlation ID, so this could not be traced from the client side.

With this clarification, it’s clear that the behavior was most likely a short‑lived backend issue that was not publicly reported, rather than anything that could be addressed through client‑side mitigation.

Thanks again for highlighting this so the information is accurate for others reading the thread.
VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-18T08:34:45.96+00:00

Mike Murphy If you need any further information or additional clarification, please let us know. We’ll be happy to help based on what can be validated from the service side.
Mike Murphy 25 Reputation points

2026-02-18T14:58:31.9066667+00:00

Thank you for all your attention to this matter!

Another point I want to emphasize is that our customers were impacted by this transient outage. And specifically that impact was the inability to sign into our application. (Kind of a big deal, don't you think?)

Not sure it is a good idea to wait around for another outage in order to craft escalation notes. How about merely forwarding this report? It is just a report, not actionable by itself. There is a good chance we were not the only ones impacted. If the ADB2C Team does not receive timely feedback, how can they improve if they are left unaware?

If there is any negative pushback on submitting reports such as this, please have them contact me. I would be interested in them explaining to me their rational (because there is none.)
VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-18T20:26:55.5766667+00:00

Mike Murphy Thank you for taking the time to articulate this so clearly and for the candid feedback. You’re absolutely right to emphasize the impact here. An inability for customers to sign in, even if transient, is a significant service disruption, and that impact shouldn’t be minimized simply because it was short‑lived or not broadly reported.

Your point about not waiting for another occurrence is well taken. Feedback like this is valuable precisely because it highlights real customer impact that may not surface through automated health signals or public incident thresholds. While the report itself may not be directly actionable in isolation, it still serves an important purpose in raising awareness, identifying patterns, and improving service resilience.

I agree that timely feedback is essential for continuous improvement, and I appreciate you calling that out explicitly. Reports such as this help ensure that customer impact isn’t overlooked simply because it didn’t meet the criteria for a public incident posting.

Thank you again for sharing this perspective it’s constructive, and it’s noted. If there’s anything further you’d like to add or clarify for the benefit of others reviewing this thread, please don’t hesitate to do so.

1 answer

Your answer

Mike Murphy 25 Reputation points

2026-02-12T21:10:30.9333333+00:00

The recommended next steps are ill-advised, because:

'Forbidden' is typically not a clear retryable error, so retry logic is not a solution

There was no indication in Azure Service Health during this period, so there would be nothing to leverage for this condition

There was no Correlation ID because this was a non-error response--even though it was an incorrect response, likely due to an internal malfunction

I mention all this so others won't attempt this as a solution to a non-reported transient service fault.
VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-12T22:04:21.5266667+00:00

Mike Murphy Thanks for sharing this. I’ve updated my original response to reflect your points accurately.

You are absolutely right that:

403 Forbidden is not a retryable error, so retry logic would not apply here.

Azure Service Health did not show any incident, so there was no service‑side signal available.

The service returned a non‑error HTTP response without a Correlation ID, so this could not be traced from the client side.

With this clarification, it’s clear that the behavior was most likely a short‑lived backend issue that was not publicly reported, rather than anything that could be addressed through client‑side mitigation.

Thanks again for highlighting this so the information is accurate for others reading the thread.
VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-18T08:34:45.96+00:00

Mike Murphy If you need any further information or additional clarification, please let us know. We’ll be happy to help based on what can be validated from the service side.
Mike Murphy 25 Reputation points

2026-02-18T14:58:31.9066667+00:00

Thank you for all your attention to this matter!

Another point I want to emphasize is that our customers were impacted by this transient outage. And specifically that impact was the inability to sign into our application. (Kind of a big deal, don't you think?)

Not sure it is a good idea to wait around for another outage in order to craft escalation notes. How about merely forwarding this report? It is just a report, not actionable by itself. There is a good chance we were not the only ones impacted. If the ADB2C Team does not receive timely feedback, how can they improve if they are left unaware?

If there is any negative pushback on submitting reports such as this, please have them contact me. I would be interested in them explaining to me their rational (because there is none.)
VEMULA SRISAI 9,265 Reputation points Microsoft External Staff Moderator

2026-02-18T20:26:55.5766667+00:00

Mike Murphy Thank you for taking the time to articulate this so clearly and for the candid feedback. You’re absolutely right to emphasize the impact here. An inability for customers to sign in, even if transient, is a significant service disruption, and that impact shouldn’t be minimized simply because it was short‑lived or not broadly reported.

Your point about not waiting for another occurrence is well taken. Feedback like this is valuable precisely because it highlights real customer impact that may not surface through automated health signals or public incident thresholds. While the report itself may not be directly actionable in isolation, it still serves an important purpose in raising awareness, identifying patterns, and improving service resilience.

I agree that timely feedback is essential for continuous improvement, and I appreciate you calling that out explicitly. Reports such as this help ensure that customer impact isn’t overlooked simply because it didn’t meet the criteria for a public incident posting.

Thank you again for sharing this perspective it’s constructive, and it’s noted. If there’s anything further you’d like to add or clarify for the benefit of others reviewing this thread, please don’t hesitate to do so.

Answer 1

Intermittent failures in retrieving access tokens can occur due to various reasons, including server issues or misconfigurations. While I cannot confirm specific incidents or provide real-time service impact reports, it is essential to ensure that your application handles such errors gracefully. Implementing retry logic, as you mentioned, is a common practice to mitigate transient issues.

Regarding backward compatibility or recent updates, the context does not provide specific information about changes that might have affected token retrieval processes on the date you mentioned. However, it is always advisable to stay updated with the latest documentation and announcements from Azure AD B2C to understand any potential impacts on your application.

If you are experiencing consistent issues, it may be worth investigating alternative authentication mechanisms or configurations that could enhance reliability, especially if your current setup is leading to significant user disruptions.

References:

Share via

ADB2C: Observed Intermittent Failures Retrieving Access Token on Feb 11 2026 (PST)

1 answer

Your answer