πŸ“‹ Microsoft Entra Documentation Changes

Daily summary for changes since May 17th 2026, 11:17 PM PDT

Report generated on May 18th 2026, 11:17 PM PDT

πŸ“Š Summary

29
Total Commits
0
New Files
10
Modified Files
0
Deleted Files
12
Contributors

πŸ“ Modified Documentation Files

Modified by Chetan Desai on May 18, 2026 7:22 PM
πŸ“– View on learn.microsoft.com
+19 / -14 lines changed
Commit: updated limitations
Changes:
Before
After
description: Learn how to troubleshoot user update issues with HR provisioning
ms.topic: troubleshooting
ai-usage: ai-assisted
ms.date: 04/07/2026
ms.reviewer: chmutali
---
 
**Applies to:**
* Workday to Microsoft Entra user provisioning
* SAP SuccessFactors to Microsoft Entra user provisioning
* API-driven provisioning Microsoft Entra ID
 
| Troubleshooting | Details |
|-- | -- |
| -- | -- |
| **Issue** | During incremental sync, there may be a delay of 12-18 hours in processing the termination event for workers located in the Asia Pacific and Australia/New Zealand regions. |
| **Cause** | The Workday Integration System User (ISU) accounts always retrieve data based on the Pacific time zone. The connector currently doesn't implement specialized query to process termination records specific to a time zone. |
| **Resolution** | There are two possible workarounds: |
 
1. Use provisioning on demand to process termination event of a specific user.
description: Learn how to troubleshoot user update issues with HR provisioning
ms.topic: troubleshooting
ai-usage: ai-assisted
ms.date: 05/18/2026
ms.reviewer: chmutali
---
 
**Applies to:**
* Workday to Microsoft Entra user provisioning
* SAP SuccessFactors to Microsoft Entra user provisioning
* API-driven provisioning to Microsoft Entra ID
 
| Troubleshooting | Details |
|-- | -- |
| -- | -- |
| **Issue** | During incremental sync, there may be a delay of 12-18 hours in processing the termination event for workers located in the Asia Pacific and Australia/New Zealand regions. |
| **Cause** | The Workday Integration System User (ISU) accounts always retrieve data based on the Pacific time zone. The connector currently doesn't implement specialized query to process termination records specific to a time zone. |
| **Resolution** | Use the termination lookahead query feature. For setup and configuration steps, see [Configure Workday termination lookahead query](configure-workday-termination-lookahead.md). |
 
## SuccessFactors termination processing delay
Modified by shlipsey3 on May 18, 2026 3:21 PM
πŸ“– View on learn.microsoft.com
+5 / -10 lines changed
Commit: pm-revisions
Changes:
Before
After
title: Conditional Access for Agent Identities in Microsoft Entra
description: Learn how Conditional Access for agent identities in Microsoft Entra ID extends Zero Trust principles to AI agents, ensuring secure access and governance.
ms.topic: concept-article
ms.date: 05/15/2026
ms.reviewer: yoelhor
ms.custom: msecd-doc-authoring-1012
ai-usage: ai-assisted
#customer-intent: As an identity administrator, I want to understand how Conditional Access policies apply to agent identities in Microsoft Entra ID, so that I can effectively manage and secure access for AI agents in my organization.
---
 
 
- **Assignments**: In an agent access flow, the access token is issued to the agent identity (the token subject), so you assign the policy to agent identities or their agent identity blueprint.
- **Target resources**: Select the resources the agent identity needs to access.
- **Conditions**: Conditions aren't currently supported for agent's user accounts because risk status can't be evaluated so no exceptions can be configured. The only supported policy for agent's user accounts is blocking access to all resources for all agent users
- **Access control**: Because this agent accesses resources with its own identity, there's no remediation and the only available option is blocking access.
 
## Agent's user account
 
### Agent's user account Conditional Access considerations
 
title: Conditional Access for Agent Identities in Microsoft Entra
description: Learn how Conditional Access for agent identities in Microsoft Entra ID extends Zero Trust principles to AI agents, ensuring secure access and governance.
ms.topic: concept-article
ms.date: 05/18/2026
ms.reviewer: yoelhor
ms.custom: msecd-doc-authoring-1012
ai-usage: ai-assisted
reviewer: kvenkit
#customer-intent: As an identity administrator, I want to understand how Conditional Access policies apply to agent identities in Microsoft Entra ID, so that I can effectively manage and secure access for AI agents in my organization.
---
 
 
- **Assignments**: In an agent access flow, the access token is issued to the agent identity (the token subject), so you assign the policy to agent identities or their agent identity blueprint.
- **Target resources**: Select the resources the agent identity needs to access.
- **Conditions**: Configure whether the agent identity is at risk. For more information, see [ID Protection for agents](../../id-protection/concept-risky-agents.md).
- **Access control**: Because this agent accesses resources with its own identity, there's no remediation and the only available option is blocking access.
 
## Agent's user account
 
### Agent's user account Conditional Access considerations
Modified by Alexander Pavlovsky on May 18, 2026 6:33 PM
πŸ“– View on learn.microsoft.com
+12 / -1 lines changed
Commit: Update known limitations for GSA and EFP
Changes:
Before
After
For usage in US Government community (GCC) cloud, known limitations/disclaimers include:
 
- Non Federal Information Processing Standard (FIPS) 140-2 certified: Note that while the GSA service is FedRAMP High accredited, it is not yet FIPS 140-2 certified. Microsoft is actively working toward achieving FIPS accreditation/certification, and this process is currently underway. Customers should consider this status when evaluating compliance requirements. FIPS 140-2 is a US government standard that defines FedRAMP minimum security requirements for cryptographic modules in products and systems. For more information, see [Federal Information Processing Standard (FIPS) 140](/azure/compliance/offerings/offering-fips-140-2).
- Data Residency Requirements: Customers should carefully consider data residency requirements when evaluating the GSA solution for their needs. When using GSA, there is a possibility that your data (up to and including customer content) may be Transport Layer Security (TLS) terminated and processed outside the United States esp. in cases where the users access GSA while traveling outside of the USA and its territories. Additionally, data may also be TLS terminated and processed outside of the USA when GSA routes traffic through the nearest available edge location, which may be outside USA borders depending on several factors. Factors for TLS termination and processing outside the US may include but not limited to: user’s physical location, proximity to edge locations, network latency, service availability, performance considerations, customer configurations and so on. As an example, a user near a USA border with a non-USA region may connect to a non-USA edge, where data inspection and policy enforcement take place.
 
 
 
 
 
 
 
 
 
 
 
 
For usage in US Government community (GCC) cloud, known limitations/disclaimers include:
 
- Non Federal Information Processing Standard (FIPS) 140-2 certified: Note that while the GSA service is FedRAMP High accredited, it is not yet FIPS 140-2 certified. Microsoft is actively working toward achieving FIPS accreditation/certification, and this process is currently underway. Customers should consider this status when evaluating compliance requirements. FIPS 140-2 is a US government standard that defines FedRAMP minimum security requirements for cryptographic modules in products and systems. For more information, see [Federal Information Processing Standard (FIPS) 140](/azure/compliance/offerings/offering-fips-140-2).
- Data Residency Requirements: Customers should carefully consider data residency requirements when evaluating the GSA solution for their needs. When using GSA, there is a possibility that your data (up to and including customer content) may be Transport Layer Security (TLS) terminated and processed outside the United States esp. in cases where the users access GSA while traveling outside of the USA and its territories. Additionally, data may also be TLS terminated and processed outside of the USA when GSA routes traffic through the nearest available edge location, which may be outside USA borders depending on several factors. Factors for TLS termination and processing outside the US may include but not limited to: user’s physical location, proximity to edge locations, network latency, service availability, performance considerations, customer configurations and so on. As an example, a user near a USA border with a non-USA region may connect to a non-USA edge, where data inspection and policy enforcement take place.
 
## Explicit Forward Proxy (preview) limitations
Known limitations for Explicit Forward Proxy (preview) include:
- TLS inspection is mandatory for EFP. TLSi bypass policies are ignored when user is connecting using the EFP network channel.
- EFP PAC file hosting is limited to EFP-generated default recommended PAC file.
- You must use EFP PAC file hosting to apply user-aware policies. If you host your own PAC files, baseline security profile will apply.
- **All internet apps with Global Secure Access** resource in Conditional Access does not include **GSA-ExplicitForwardProxy** resource. If you use the **All internet apps with Global Secure Access** for security profile assignment, you must create a separate policy targeting **GSA-ExplicitForwardProxy** as the resource and specifying the Global Secure Access profile to be used on the **Session** tab of Conditional Access policy.
- If you apply Conditional Access Policy requiring Compliant Network to be satisfied for All Apps, you must exclude the **GSA-ExplicitForwardProxy** resource from that policy. EFP requires Entra ID authentication prior to the connection - Entra ID traffic must always be excluded from proxy automatic configuration (PAC) files. Because Entra ID traffic is not going through EFP, Compliant Network check will fail, unless the **GSA-ExplicitForwardProxy** principal is excluded from the policy.
- On MacOS, coexistence of GSA client and EFP settings are not supported due to client certificate issues.
- Microsoft Office 365 traffic should not be tunneled to EFP. EFP-hosted PAC file excludes Office 365 destinations. Office 365 traffic is defined in the [Microsoft365 IP and FQDN list](https://aka.ms/m365iplist)
- EFP supports Microsoft Entra Internet Access traffic type. Private Access and Microsoft Traffic are not supported when users configure EFP.
 
Modified by Janice Ricketts on May 18, 2026 8:02 PM
πŸ“– View on learn.microsoft.com
+10 / -2 lines changed
Commit: Enhance connector load balancing section with routing options
Changes:
Before
After
 
## Connector load balancing
 
When you add multiple connectors to a connector group, the group selects which connector handles each request.
 
### Random
 
Random is the default traffic routing method. New requests for a Global Secure Access application are distributed across the available connectors in the assigned connector group.
 
You can change the traffic routing behavior per Global Secure Access application. For more information about traffic routing options and when to use them, see [How to configure per-app access using Global Secure Access applications](how-to-configure-per-app-access.md#configure-traffic-routing-for-the-app). For Microsoft Graph details, see [onPremisesPublishing resource type](/graph/api/resources/onpremisespublishing?view=graph-rest-beta&preserve-view=true).
 
## Sample configurations
 
 
 
 
 
 
 
 
 
## Connector load balancing
 
When you add multiple connectors to a connector group, the group selects which connector handles each request. Routing options include Random (default) and Session persistence.
 
You can change the traffic routing behavior per Global Secure Access application. For more information about traffic routing options and when to use them, see [How to configure per-app access using Global Secure Access applications](how-to-configure-per-app-access.md#configure-traffic-routing-for-the-app). For Microsoft Graph details, see [onPremisesPublishing resource type](/graph/api/resources/onpremisespublishing?view=graph-rest-beta&preserve-view=true).
 
### Random
 
Random is the default traffic routing method. New requests for a Global Secure Access application are distributed across the available connectors in the assigned connector group.
 
### Session persistence
 
Session persistence, also called session affinity, consistently routes every request from a given user and device to the same connector within a group for the duration of a session. This approach is useful for applications that rely on connector egress IP for authentication and access control lists (ACLs). It ensures continuity and reduces the need for repeated authentication or data retrieval.
 
> [!TIP]
> Session persistence only works with Microsoft Entra Private Access applications, not Microsoft Entra application proxy applications.
 
 
## Sample configurations
+5 / -5 lines changed
Commit: incorporating feedback
Changes:
Before
After
 
### Limitations
 
- After you start agents, you can't stop or pause them. They might take a few minutes to run.
- For policy consolidation, each agent run evaluates 40 similar policy pairs.
- We recommend running the agent from the Microsoft Entra admin center.
- Scanning is limited to a 24-hour period.
- You can't customize or overrise suggestions from the agent.
- The agent can review up to 300 users and 150 applications in a single run.
 
## How it works
1. The agent creates a new policy in report-only mode or provides the suggestion to modify a policy, including any logic in the custom instructions.
 
> [!NOTE]
> Security Copilot requires the provisioning of at least one SCU in your tenant. That SCU is billed each month, even if you don't consume any SCUs. Turning off the agent doesn't stop the monthly billing for the SCU.
 
The policy suggestions from the agent include:
 
 
:::image type="content" source="media/conditional-access-agent-optimization/start-agent.png" alt-text="Screenshot that shows the button for starting an agent on the Conditional Access Optimization Agent pane." lightbox="media/conditional-access-agent-optimization/start-agent.png":::
 
### Limitations
 
- After the agent starts, you can't stop or pause the run. It might take a few minutes to run.
- For policy consolidation, each agent run evaluates 40 similar policy pairs.
- We recommend running the agent from the Microsoft Entra admin center.
- Scanning is limited to a 24-hour period.
- You can't customize or override suggestions from the agent.
- The agent can review up to 300 users and 150 applications in a single run.
 
## How it works
1. The agent creates a new policy in report-only mode or provides the suggestion to modify a policy, including any logic in the custom instructions.
 
> [!NOTE]
> Security Copilot requires that at least one SCU is provisioned in your tenant. That SCU is billed each month, even if you don't consume any SCUs. Turning off the agent doesn't stop the monthly billing for the SCU.
 
The policy suggestions from the agent include:
 
 
:::image type="content" source="media/conditional-access-agent-optimization/start-agent.png" alt-text="Screenshot that shows the button for starting an agent on the Conditional Access Optimization Agent pane." lightbox="media/conditional-access-agent-optimization/start-agent.png":::
Modified by Regan Downer on May 18, 2026 4:13 PM
πŸ“– View on learn.microsoft.com
+2 / -2 lines changed
Commit: Apply suggestions from code review
Changes:
Before
After
| Compliance Administrator | Knowledge Administrator | Teams Communications Administrator |
| Compliance Data Administrator | License Administrator | Teams Devices Administrator |
| Conditional Access Administrator | Lifecycle Workflows Administrator | User Administrator |
| Customer LockBox Access Approver | Mailbox Administrator | Virtual Visits Administrator |
| Desktop Analytics Administrator | Microsoft Entra Joined Device Local Administrator | Viva Goals Administrator |
| Device Administrators | Microsoft Hardware Warranty Administrator | Viva Pulse Administrator |
| Directory Synchronization Accounts | Microsoft365 Migration Administrator | Windows365 Administrator |
| Directory Writers | Modern Commerce Administrator | Windows Update Deployment Administrator |
| Domain Name Administrator | Network Administrator | Yammer Administrator |
 
| Compliance Administrator | Knowledge Administrator | Teams Communications Administrator |
| Compliance Data Administrator | License Administrator | Teams Devices Administrator |
| Conditional Access Administrator | Lifecycle Workflows Administrator | User Administrator |
| Customer Lockbox Access Approver | Mailbox Administrator | Virtual Visits Administrator |
| Desktop Analytics Administrator | Microsoft Entra Joined Device Local Administrator | Viva Goals Administrator |
| Device Administrators | Microsoft Hardware Warranty Administrator | Viva Pulse Administrator |
| Directory Synchronization Accounts | Microsoft 365 Migration Administrator | Windows365 Administrator |
| Directory Writers | Modern Commerce Administrator | Windows Update Deployment Administrator |
| Domain Name Administrator | Network Administrator | Yammer Administrator |
 
Modified by Vimala Ranganathan on May 18, 2026 3:38 PM
πŸ“– View on learn.microsoft.com
+2 / -2 lines changed
Commit: Fix PR review issues: remove single-step numbering, update screenshot
Changes:
Before
After
 
To enable domainless federation for a new SAML IdP, follow these steps:
 
1. On the **New SAML/WS-Fed IdP** page, select **Domainless**. Selecting **Domainless** enforces no domain check of the user's email address.
 
:::image type="content" source="media/direct-federation/new-saml-wsfed-idp-domainless.png" alt-text="Screenshot showing the SAML/WS-Fed identity provider list with the domainless configuration." lightbox="media/direct-federation/new-saml-wsfed-idp-domainless.png":::
 
 
The following known issue is being actively addressed and this section will be updated after the fix is available.
 
1. The IdP configuration gets deleted if an invalid domain name is entered even when the IdP config is not saved.
 
## How to update the certificate or configuration details
 
 
To enable domainless federation for a new SAML IdP, follow these steps:
 
- On the **New SAML/WS-Fed IdP** page, select **Domainless**. Selecting **Domainless** enforces no domain check of the user's email address.
 
:::image type="content" source="media/direct-federation/new-saml-wsfed-idp-domainless.png" alt-text="Screenshot showing the SAML/WS-Fed identity provider list with the domainless configuration." lightbox="media/direct-federation/new-saml-wsfed-idp-domainless.png":::
 
 
The following known issue is being actively addressed and this section will be updated after the fix is available.
 
- The IdP configuration gets deleted if an invalid domain name is entered even when the IdP config is not saved.
 
## How to update the certificate or configuration details
 
+1 / -1 lines changed
Commit: Update domain_hint issuer format wording for clarity
Changes:
Before
After
|---------|-------|
| **Display name** | A name your users see during sign-in, for example *Sign in with Contoso*. |
| **Well-known endpoint** | `https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration` |
| **OpenID Issuer URI** | `https://login.microsoftonline.com/<tenant-ID>/v2.0`, where `<tenant-ID>` is the directory (tenant) ID of the Microsoft Entra ID tenant. If using `domain_hint` for IdP acceleration, use the domain-based issuer format `https://login.microsoftonline.com/<Primary domain name of WF tenant>/v2.0` rather than tenant ID. |
| **Client ID** | The application (client) ID from the app registration you created in the Microsoft Entra ID tenant. |
| **Client Authentication** | `client_secret` |
| **Client Secret** | The client secret value you recorded from the app registration. |
|---------|-------|
| **Display name** | A name your users see during sign-in, for example *Sign in with Contoso*. |
| **Well-known endpoint** | `https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration` |
| **OpenID Issuer URI** | `https://login.microsoftonline.com/<tenant-ID>/v2.0`, where `<tenant-ID>` is the directory (tenant) ID of the Microsoft Entra ID tenant. If using `domain_hint` for IdP acceleration, use the domain-based issuer format `https://login.microsoftonline.com/<domain-name>/v2.0` rather than tenant ID, where `<domain-name>` is the primary domain name of the Microsoft Entra ID tenant. |
| **Client ID** | The application (client) ID from the app registration you created in the Microsoft Entra ID tenant. |
| **Client Authentication** | `client_secret` |
| **Client Secret** | The client secret value you recorded from the app registration. |
+1 / -1 lines changed
Commit: Update note for OIDC EMU single-tenant limitation
Changes:
Before
After
Add GitHub Enterprise Managed User (OIDC) from the Microsoft Entra application gallery to start managing provisioning to GitHub Enterprise Managed User (OIDC). If you have previously setup GitHub Enterprise Managed User (OIDC) for SSO, you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](~/identity/enterprise-apps/add-application-portal.md).
 
> [!NOTE]
> If you need another instance of the application then you can consent to GitHub Enterprise Managed User (OIDC) - ghe.com and please work with GitHub account team to enable this feature for your instance.
 
## Step 4: Define who is in scope for provisioning
 
Add GitHub Enterprise Managed User (OIDC) from the Microsoft Entra application gallery to start managing provisioning to GitHub Enterprise Managed User (OIDC). If you have previously setup GitHub Enterprise Managed User (OIDC) for SSO, you can use the same application. However it's recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](~/identity/enterprise-apps/add-application-portal.md).
 
> [!NOTE]
> Each Entra ID tenant can support only one OIDC integration with Enterprise Managed Users. If you want to connect Entra ID to more than one enterprise on GitHub, use SAML instead. See [Configuring SAML single sign-on for Enterprise Managed Users](https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/using-enterprise-managed-users-for-iam/configuring-saml-single-sign-on-for-enterprise-managed-users)
 
## Step 4: Define who is in scope for provisioning
 
+1 / -1 lines changed
Commit: Update concept-certificate-based-authentication-certificate-revocation-list.md
Changes:
Before
After
| **AADSTS500183: Certificate has been revoked. Please contact your administrator** | An Authentication attempt failed because the client device presented a certificate that was revoked by the issuing CA. | The certificate used for authentication is found in the Certificate Revocation List (CRL) or flagged as revoked by the CA. | - Tenant Administrator should ensure the new certificate is correctly provisioned and trusted by Microsoft Entra ID.<br/>- Verify that the CRLs and delta CRLs published by your CA are up to date and accessible for the devices. |
| **AADSTS2205011: The downloaded Certificate Revocation List (CRL) isn't in a valid ASN.1 encoding format. Please contact your administrator.** | CRL file fetched by Microsoft Entra isn't correctly encoded following the Abstract Syntax Notation One (ASN.1) Distinguished Encoding Rules (DER) standard, which is required for parsing and validating the CRL data. | - The CRL file is corrupted or truncated during publication or transmission.<br/>- The CRL was generated or encoded incorrectly by the CA and doesn't conform to ASN.1 DER standards.<br/>- File format conversions (such as improper base64/PEM encoding) corrupted the CRL data. | - Manually download the CRL and inspect it with tools like openssl or specialized ASN.1 parsers to confirm if it's corrupted or malformed.<br/>- Regenerate and republish the CRL from the CA ensuring compliance with ASN.1 DER encoding standards.<br/>- Ensure the CA software or tools generating CRLs comply with RFC 5280 and correctly encode CRLs in ASN.1 DER format.<br/> |
| **AADSTS2205012: The attempt to download the Certificate Revocation List (CRL) from '{uri}' during the interactive sign-in has timed out. We're trying to download again. Please try again in a few minutes.** | Microsoft Entra ID couldn't retrieve the CRL file within the expected time from the specified URL. | - Microsoft Entra ID services can't reach the CRL distribution point due to network outages, firewall restrictions, or DNS failures.<br/>- The server hosting the CRL is down, overloaded, or not responding in a timely manner.<br/>- Large CRLs take longer to download, potentially causing timeouts.<br/> | - Use delta CRLs to keep CRL file sizes smaller and refresh more frequently to reduce download time.<br/>- Publish or refresh CRLs during off-peak hours to reduce server load and improve response times.<br/>- Monitor and maintain high availability and performance of the CRL hosting servers.<br/> |
| **AADSTS2205013: Certificate Revocation List (CRL) download is currently in progress. Please try again in a few minutes.** | Happens when multiple authentication attempts simultaneously trigger CRL downloads, and the system is still processing the current CRL retrieval. | - When a CRL expires or is about to expire, multiple users signing in concurrently can cause simultaneous attempts to download the fresh CRL.<br/>- Microsoft Entra ID applies a locking mechanism to prevent concurrent downloads of the same CRL to reduce load and potential race conditions.This causes some authentication requests to be temporarily denied with this retry message.<br/>- Large user populations or heavy sign-in bursts can increase the frequency of this error. | - Allow a few minutes for the ongoing CRL download to finish before retrying sign-in.<br/>- Ensure CRLs are published and updated regularly before expiry to reduce forced re-downloads. |
| **AADSTS2205014:The attempt to download the Certificate Revocation List (CRL) from '{uri}' during the interactive sign-in has exceeded the maximum allowed size ({size} bytes). The CRL is being provisioned with CRL's service download limit, please try again in a few minutes.** | The CRL file Microsoft Entra ID tried to download is larger than the size limit set by the service. Microsoft Entra will try to download in background with higher limits. | - The CRL file published by the CA is too large, often due to a high number of revoked certificates.<br/>- Large CRLs can occur if revoked certificates aren't cleaned up or if the CA keeps long expiration periods for revocation data.<br/>- Large CRL sizes increase download times and resource consumption during certificate-based authentication. | - Remove stale or expired revoked certificates from the CA database.<br/>- Shorten CRL validity periods and increase publishing frequency to keep CRL sizes manageable.<br/>- Implement delta CRLs to distribute only incremental revocation information and reduce bandwidth. |
| **AADSTS2205015: The Certificate Revocation List (CRL) failed signature validation. The expected SubjectKeyIdentifier {expectedSKI} doesn't match CRL's AuthorityKeyIdentifier {crlAK}. Please contact your administrator.** | The cryptographic signature on the CRL couldn't be validated because the CRL was signed by a certificate whose Subject Key Identifier (SKI) doesn't match the Authority Key Identifier (AKI) expected by Microsoft Entra ID. | - The CA certificate used to sign the CRL changed but the new SKI wasn't updated or synchronized in the trusted certificates list.<br/>- The CRL is outdated or mismatched due to misconfiguration in the PKI hierarchy.<br/>- Incorrect or missing intermediate CA certificates in the trusted certificate list.<br/>- CRL signing certificate might not have the appropriate key usage for signing CRLs. | - Check the Subject Key Identifier (SKI) of the CA certificate signing the CRL matches the Authority Key Identifier (AKI) in the CRL.<br/>- Confirm the signing CA certificate is uploaded and trusted in Microsoft Entra ID.<br/>- Validate that the CA certificate used to sign the CRL has the appropriate key usage flags enabled (such as CRL signing) and verify the certificate chain is intact and unbroken.<br/>- Upload or update the correct root and intermediate CA certificates in Microsoft Entra ID’s trusted certificate authorities list and ensure the certificate used to sign the CRL is included and correctly configured. |
| **AADSTS7000214: Certificate has been revoked.** | Certificate has been revoked. | - Certificate listed in CRL | - Replace revoked certificate<br>- Investigate revocation reason with CA<br>- Monitor certificate lifecycle and renewal |
| **AADSTS500183: Certificate has been revoked. Please contact your administrator** | An Authentication attempt failed because the client device presented a certificate that was revoked by the issuing CA. | The certificate used for authentication is found in the Certificate Revocation List (CRL) or flagged as revoked by the CA. | - Tenant Administrator should ensure the new certificate is correctly provisioned and trusted by Microsoft Entra ID.<br/>- Verify that the CRLs and delta CRLs published by your CA are up to date and accessible for the devices. |
| **AADSTS2205011: The downloaded Certificate Revocation List (CRL) isn't in a valid ASN.1 encoding format. Please contact your administrator.** | CRL file fetched by Microsoft Entra isn't correctly encoded following the Abstract Syntax Notation One (ASN.1) Distinguished Encoding Rules (DER) standard, which is required for parsing and validating the CRL data. | - The CRL file is corrupted or truncated during publication or transmission.<br/>- The CRL was generated or encoded incorrectly by the CA and doesn't conform to ASN.1 DER standards.<br/>- File format conversions (such as improper base64/PEM encoding) corrupted the CRL data. | - Manually download the CRL and inspect it with tools like openssl or specialized ASN.1 parsers to confirm if it's corrupted or malformed.<br/>- Regenerate and republish the CRL from the CA ensuring compliance with ASN.1 DER encoding standards.<br/>- Ensure the CA software or tools generating CRLs comply with RFC 5280 and correctly encode CRLs in ASN.1 DER format.<br/> |
| **AADSTS2205012: The attempt to download the Certificate Revocation List (CRL) from '{uri}' during the interactive sign-in has timed out. We're trying to download again. Please try again in a few minutes.** | Microsoft Entra ID couldn't retrieve the CRL file within the expected time from the specified URL. | - Microsoft Entra ID services can't reach the CRL distribution point due to network outages, firewall restrictions, or DNS failures.<br/>- The server hosting the CRL is down, overloaded, or not responding in a timely manner.<br/>- Large CRLs take longer to download, potentially causing timeouts.<br/> | - Use delta CRLs to keep CRL file sizes smaller and refresh more frequently to reduce download time.<br/>- Publish or refresh CRLs during off-peak hours to reduce server load and improve response times.<br/>- Monitor and maintain high availability and performance of the CRL hosting servers.<br/> |
| **AADSTS2205013: Certificate Revocation List (CRL) download is currently in progress. Please try again in a few minutes.** | Happens when multiple authentication attempts simultaneously trigger CRL downloads, and the system is still processing the current CRL retrieval. | - When a CRL expires or is about to expire, multiple users signing in concurrently can cause simultaneous attempts to download the fresh CRL.<br/>- Microsoft Entra ID applies a locking mechanism to prevent concurrent downloads of the same CRL to reduce load and potential race conditions. This causes some authentication requests to be temporarily denied with this retry message.<br/>- Large user populations or heavy sign-in bursts can increase the frequency of this error. | - Allow a few minutes for the ongoing CRL download to finish before retrying sign-in.<br/>- Ensure CRLs are published and updated regularly before expiry to reduce forced re-downloads. |
| **AADSTS2205014:The attempt to download the Certificate Revocation List (CRL) from '{uri}' during the interactive sign-in has exceeded the maximum allowed size ({size} bytes). The CRL is being provisioned with CRL's service download limit, please try again in a few minutes.** | The CRL file Microsoft Entra ID tried to download is larger than the size limit set by the service. Microsoft Entra will try to download in background with higher limits. | - The CRL file published by the CA is too large, often due to a high number of revoked certificates.<br/>- Large CRLs can occur if revoked certificates aren't cleaned up or if the CA keeps long expiration periods for revocation data.<br/>- Large CRL sizes increase download times and resource consumption during certificate-based authentication. | - Remove stale or expired revoked certificates from the CA database.<br/>- Shorten CRL validity periods and increase publishing frequency to keep CRL sizes manageable.<br/>- Implement delta CRLs to distribute only incremental revocation information and reduce bandwidth. |
| **AADSTS2205015: The Certificate Revocation List (CRL) failed signature validation. The expected SubjectKeyIdentifier {expectedSKI} doesn't match CRL's AuthorityKeyIdentifier {crlAK}. Please contact your administrator.** | The cryptographic signature on the CRL couldn't be validated because the CRL was signed by a certificate whose Subject Key Identifier (SKI) doesn't match the Authority Key Identifier (AKI) expected by Microsoft Entra ID. | - The CA certificate used to sign the CRL changed but the new SKI wasn't updated or synchronized in the trusted certificates list.<br/>- The CRL is outdated or mismatched due to misconfiguration in the PKI hierarchy.<br/>- Incorrect or missing intermediate CA certificates in the trusted certificate list.<br/>- CRL signing certificate might not have the appropriate key usage for signing CRLs. | - Check the Subject Key Identifier (SKI) of the CA certificate signing the CRL matches the Authority Key Identifier (AKI) in the CRL.<br/>- Confirm the signing CA certificate is uploaded and trusted in Microsoft Entra ID.<br/>- Validate that the CA certificate used to sign the CRL has the appropriate key usage flags enabled (such as CRL signing) and verify the certificate chain is intact and unbroken.<br/>- Upload or update the correct root and intermediate CA certificates in Microsoft Entra ID’s trusted certificate authorities list and ensure the certificate used to sign the CRL is included and correctly configured. |
| **AADSTS7000214: Certificate has been revoked.** | Certificate has been revoked. | - Certificate listed in CRL | - Replace revoked certificate<br>- Investigate revocation reason with CA<br>- Monitor certificate lifecycle and renewal |