This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(278.4, 3%, 36%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBI%3C/text%3E%3C/svg%3E)
Details
I am a Global Administrator in a Microsoft 365 tenant (cloud-only, no on-prem AD DS). After recently hardening security and enabling Conditional Access policies, I can no longer access the Microsoft Entra admin center or other admin portals.
When attempting to sign in, I receive the following error:
AADSTS500192: Either no valid certificate was detected on the device, or the user canceled the certificate selection.
There is no smart card, no client certificate, and no certificate-based authentication configured in the tenant. This is a standard Windows device without Windows Hello for Business certificate trust configured.
Environment details:
Global Administrator account
Break glass Global Administrator account also affected
No on-prem PKI
No Entra CBA configuration completed
Conditional Access recently modified
Microsoft-managed policies were enabled:
Multifactor authentication for admins accessing Microsoft Admin Portals
Require phishing-resistant multifactor authentication for admins
Custom Conditional Access policies exist that may apply to:
All users
Global Administrators
All cloud apps
```It appears a Conditional Access policy requiring either:
Certificate-based authentication
Or phishing-resistant MFA (authentication strength) has been enforced without excluding a break glass account, and without having certificate-based authentication properly configured.
Current issue: All Global Administrator accounts are blocked from portal access due to certificate requirement.
Questions:
What is the supported recovery path when Conditional Access requires certificate-based authentication but no certificates are deployed?
Is there a backend method to disable CA policies when all Global Admin accounts are blocked?
Can Microsoft Support temporarily disable Conditional Access enforcement at the tenant level?
I have Request ID, Correlation ID, and Timestamp available if needed.
This is an urgent administrative lockout scenario.
---
Post that exactly as written.
Do not edit it.
Then wait for official Microsoft response.
You are in a Conditional Access self-lock configuration. That is recoverable, but it requires Microsoft intervention if break glass is also blocked.Details
I am a Global Administrator in a Microsoft 365 tenant (cloud-only, no on-prem AD DS). After recently hardening security and enabling Conditional Access policies, I can no longer access the Microsoft Entra admin center or other admin portals.
When attempting to sign in, I receive the following error:
AADSTS500192: Either no valid certificate was detected on the device, or the user canceled the certificate selection.
There is no smart card, no client certificate, and no certificate-based authentication configured in the tenant. This is a standard Windows device without Windows Hello for Business certificate trust configured.
Environment details:
Cloud-only Entra ID tenant
Global Administrator account
Break glass Global Administrator account also affected
No on-prem PKI
No Entra CBA configuration completed
Conditional Access recently modified
Microsoft-managed policies were enabled:
Multifactor authentication for admins accessing Microsoft Admin Portals
```yaml
Require phishing-resistant multifactor authentication for admins
Custom Conditional Access policies exist that may apply to:
All users
Global Administrators
All cloud apps
```It appears a Conditional Access policy requiring either:
Certificate-based authentication
Or phishing-resistant MFA (authentication strength)
has been enforced without excluding a break glass account, and without having certificate-based authentication properly configured.
Current issue:
All Global Administrator accounts are blocked from portal access due to certificate requirement.
Questions:
What is the supported recovery path when Conditional Access requires certificate-based authentication but no certificates are deployed?
Is there a backend method to disable CA policies when all Global Admin accounts are blocked?
Can Microsoft Support temporarily disable Conditional Access enforcement at the tenant level?
I have Request ID, Correlation ID, and Timestamp available if needed.
This is an urgent administrative lockout scenario.
---
Post that exactly as written.
Do not edit it.
Then wait for official Microsoft response.
You are in a Conditional Access self-lock configuration.
That is recoverable, but it requires Microsoft intervention if break glass is also blocked.
A cloud-based identity and access management service for securing user authentication and resource access
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(182.40000000000003, 77%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EPK%3C/text%3E%3C/svg%3E)
Hello Brian Ingram,
it looks like you’ve fallen into a classic Conditional Access self-lockout by enforcing certificate-based auth (or phishing-resistant MFA) without actually configuring CBA and without excluding a break-glass account. Since both your Global Admins and “emergency” accounts are blocked, here’s what you need to do:
Submit a Microsoft Support ticket for tenant-level recovery • Use the Azure portal “Help + support” blade or go to https://aka.ms/azuresupport and open a Severity A (business-critical) request. • Tell them you’re locked out of all Global Admins due to AADSTS500192 and need Conditional Access policies temporarily disabled or set to report-only so you can regain access. • Supply your Tenant ID, Request ID, Correlation ID and Timestamp—they’ll need those to locate and flip the CA policies backend.
Once Microsoft support disables the offending CA policy, immediately: • Exclude at least one dedicated “break-glass” or emergency access account from every policy targeting All Users or All Global Admins. See: Manage emergency access accounts in Entra ID • Either remove the certificate requirement or fully configure Azure AD Native Certificate Based Authentication (upload your root/intermediate CA certs, configure issuers & binding rules) before re-enabling. • If you only need phishing-resistant MFA, swap the CBA requirement for a supported strong auth method (FIDO2/WebAuthn or Windows Hello for Business).
Test future changes in report-only mode or use the “What If” tool Before turning CA policies fully on, switch them to report-only or run simulations to confirm you won’t lock yourself out again.
Supported recovery path & backend disablement • There’s no self-service override once all Global Admins are blocked by CA. Only Microsoft Support (Data Protection / Tenant Recovery team) can disable the policy for you. • After they confirm your tenant ownership, they’ll temporarily turn off or exclude your accounts so you can log back in.
Follow-up questions to help us prep your support request:
References
Thank you for the response. I need to clarify that the suggested steps cannot be executed in our environment.
All Global Administrator accounts are locked out, including the designated break glass account. We have zero portal access. We cannot open Entra ID, cannot access Conditional Access policies, cannot run Graph PowerShell with delegated admin credentials, and cannot change policy state from any interface that requires authentication.
The break glass account is not excluded from the blocking policy. That is the root cause.
We need Microsoft backend intervention to disable or suspend Conditional Access enforcement at the tenant level. No self-service path is available to us.
To answer your questions directly: All Global Administrator accounts are locked out. The blocking condition appears to be an authentication strength requirement enforcing phishing-resistant MFA or certificate-based authentication applied to all admins across all cloud apps with no break glass exclusion.
Hello @Brian Ingram,
Based on your description, it appears that all of your admins accounts got locked out due to misconfiguration of conditional access policy. To resolve this issue, we need to engage Data Protection team over support ticket so that the DP Team will make changes from the backend to help you to regain access to tenant.
To engage DP team, I will need a few details from you. As this information contains Personally Identifiable Information (PII), please share the following details via private message:
If you have already created a support ticket with DP team, please share the ticket ID with me over private message.
Hello @Brian Ingram,
I just wanted to check if you'd be interested in taking this offline to get this resolved. Please share the necessary details in private message so I can proceed with engaging the Data Protection team. If you have already engaged Data Protection team over a support ticket, please share the ticket number over private message.
This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
when every GA gets locked behind that 500192 cert wall, the only real way back is a sev‑A n having support freeze ca eval so u can slip one clean sign‑in again. keep ur req‑id close — that’s the thread they pull to find the exact policy hit n lift the block without touching anything else.
That's exactly right. The Sev A designation forces a response SLA and gets you past the AI triage layer to an engineer who has backend access to freeze CA evaluation at the token issuance level. The Request ID ties them directly to the exact policy evaluation event in their logs so they're not guessing which policy fired. Once they identify it they can suppress evaluation for your account long enough to get one clean interactive sign-in, at which point you disable or exclude yourself from the blocking policy before the session expires.
Thanks for confirming Brian
that matches what I’ve seen when CA locks out every GA. Freezing CA at token issuance is really the only clean recovery path, and the Request/Correlation IDs make the trace surgical. Glad the flow lined up on your side; hope you get a clean sign‑in window to unwind the policy safely.
If this ends up resolving things on your side, feel free to mark it as the answer — it might help the next person who hits the same wall.
Thank you. Cases are still open and waiting on Microsoft backend intervention. Request IDs are ready. Appreciate the confirmation on the recovery path.
Hello Brian Ingram, thanks for the update…glad u’ve got the req IDs lined up.
if things get sorted on MS side later, it’d help a lot of folks here if u could share how it finally got fixed — even a short note goes a long way for ppl stuck on the same thing.