MODIFIED docs/identity/authentication/how-to-mfa-registration-campaign.md

Modified by Paula Thurman on Jun 11, 2026 9:26 PM
📖 View on learn.microsoft.com

+138 / -149 lines changed

Commit: [AQ] edit pass: Security info registration (#13295)

Changes:

Before

After

---
title: Run a registration campaign to set up passkey or Microsoft Authenticator
description: Learn how to run a registration campaign in Microsoft Entra ID to nudge users toward passkeys or Microsoft Authenticator for stronger sign-in security.
ms.topic: how-to
ms.date: 05/20/2026
#Customer intent: As an identity administrator, I want to encourage users to set up a passkey or Microsoft Authenticator in Microsoft Entra ID to improve and secure user sign-in events.
---
 
# Run a registration campaign to set up passkey or Microsoft Authenticator
 
You can nudge users to set up a passkey or Microsoft Authenticator during sign-in. Users go through their regular sign-in, perform multifactor authentication as usual, and then get prompted to set up the targeted authentication method. You can include or exclude users or groups to control who gets nudged, and create targeted campaigns to move users from less secure authentication methods to passkeys or Authenticator.
 
Registration campaigns support two authentication methods:
 
- **Passkey (FIDO2)** — Nudge users to register a passkey, which includes both synced passkeys and device-bound passkeys.
- **Microsoft Authenticator** — Nudge users to download and set up the Authenticator app for push notifications.
 
> [!NOTE]
> A registration campaign can only target one authentication method at a time. You can't run campaigns for both Microsoft Authenticator and passkeys simultaneously in the same tenant.
 

---
title: Run a Registration Campaign to Set Up a Passkey or Microsoft Authenticator
description: Learn how to run a registration campaign in Microsoft Entra ID to nudge users toward passkeys or Microsoft Authenticator for stronger sign-in security.
ms.topic: how-to
ms.date: 05/20/2026
#Customer intent: As an identity administrator, I want to encourage users to set up a passkey or Microsoft Authenticator in Microsoft Entra ID to improve and secure user sign-in events.
---
 
# Run a registration campaign to set up a passkey or Microsoft Authenticator
 
You can nudge users to set up a passkey or Microsoft Authenticator during sign-in. Users go through their regular sign-in, perform multifactor authentication (MFA) as usual, and are then prompted to set up the targeted authentication method. You can include or exclude users or groups to control who gets nudged and create targeted campaigns to move users from less secure authentication methods to passkeys or Authenticator.
 
Registration campaigns support two authentication methods:
 
- **Passkey (FIDO2)**: Nudges users to register a passkey, which includes both synced passkeys and device-bound passkeys.
- **Authenticator**: Nudges users to download and set up Authenticator for push notifications.
 
A registration campaign can target only one authentication method at a time. You can't run campaigns for both Authenticator and passkeys simultaneously in the same tenant.
 
You can also define how many days a user can postpone, or "snooze," the nudge. If a user taps **Skip for now** to postpone setup, they get nudged again on the next MFA attempt after the snooze duration elapses. You can decide whether the user can snooze indefinitely or up to three times (after which registration is required).

MODIFIED docs/security-copilot/conditional-access-agent-optimization-knowledge-base.md

Modified by shlipsey3 on Jun 11, 2026 4:27 PM
📖 View on learn.microsoft.com

+68 / -11 lines changed

Commit: ca-agent-kb-updates (#13441)

Changes:

Before

After

---
title: Conditional Access Optimization Agent knowledge base (Preview)
description: Learn how Knowledge Bases help the Conditional Access Optimization Agent create tailored policy recommendations based on your organization's unique standards.
#customer intent: As an IT admin, I want to upload organizational Conditional Access standards to a Knowledge Base so that the Conditional Access Optimization Agent can generate recommendations aligned with my organization's policies.
author: shlipsey3
ms.author: sarahlipsey
reviewer: jodahl
ms.date: 05/22/2026
ms.topic: how-to
ms.service: entra-id
ms.subservice: conditional-access
---
 
# Conditional Access Optimization Agent knowledge base (Preview)
 
Organizations that use Conditional Access policies to protect access to resources should establish standards and patterns to stay organized. For example, having a consistent naming convention can keep you organized and prevent policy overlap or gaps. The Conditional Access Optimization Agent can use a document from your organization that maps out these standards so that agent reasons with context using the patterns that you design.
 
- Different user personas require distinct policy sets, such as admins, workforce users, and contractors
- Policy naming standards are enforced
- Breakglass accounts must be consistently excluded

---
title: Conditional Access Optimization Agent knowledge base
description: Learn how Knowledge Bases help the Conditional Access Optimization Agent create tailored policy recommendations based on your organization's unique standards.
#customer intent: As an IT admin, I want to upload organizational Conditional Access standards to a Knowledge Base so that the Conditional Access Optimization Agent can generate recommendations aligned with my organization's policies.
author: shlipsey3
ms.author: sarahlipsey
reviewer: jodahl
ms.date: 06/10/2026
ms.topic: how-to
ms.service: entra-id
ms.subservice: conditional-access
---
 
# Conditional Access Optimization Agent knowledge base
 
Organizations that use Conditional Access policies to protect access to resources should establish standards and patterns to stay organized. For example, having a consistent naming convention can keep you organized and prevent policy overlap or gaps. The Conditional Access Optimization Agent can use a document from your organization that maps out these standards so that agent reasons with context using the patterns that you design.
 
- Different user personas require distinct policy sets, such as admins, workforce users, and contractors
- Policy naming standards are enforced
- Breakglass accounts must be consistently excluded

MODIFIED docs/external-id/customers/how-to-custom-oidc-federation-customers.md

Modified by Gearoid O'Donnell on Jun 11, 2026 3:04 PM
📖 View on learn.microsoft.com

+75 / -2 lines changed

Commit: docs: Email not required for external IdP sign-up (#13284)

Changes:

Before

After

title: Add OIDC for customer sign-in
description: Learn how to set up OpenID Connect as an external identity provider in Microsoft Entra External ID, enabling users to sign in using their existing accounts. 
ms.topic: how-to
ms.date: 09/15/2025
ms.reviewer: brozbab
ms.custom: it-pro, msecd-doc-authoring-1012
 
#customer intent: As a developer, devops, or it administrator, I want to learn how to add an OpenID Connect identity provider for my external tenant.
---
  - Name
  - Given name
  - Family name
  - Email (required)
  - Email_verified
  - Phone number
  - Phone_number_verified
 
1. Select **Save**.
 
## Related content

title: Add OIDC for customer sign-in
description: Learn how to set up OpenID Connect as an external identity provider in Microsoft Entra External ID, enabling users to sign in using their existing accounts. 
ms.topic: how-to
ms.date: 06/11/2026
ms.reviewer: brozbab
ms.custom: it-pro, msecd-doc-authoring-1012
ai-usage: ai-assisted
 
#customer intent: As a developer, devops, or it administrator, I want to learn how to add an OpenID Connect identity provider for my external tenant.
---
  - Name
  - Given name
  - Family name
  - Email (required by default; can be [made optional](#make-email-optional-for-external-identity-provider-sign-up))
  - Email_verified
  - Phone number
  - Phone_number_verified
 
1. Select **Save**.
 

MODIFIED docs/identity/authentication/howto-registration-mfa-sspr-combined-troubleshoot.md

Modified by Paula Thurman on Jun 11, 2026 9:26 PM
📖 View on learn.microsoft.com

+28 / -30 lines changed

Commit: [AQ] edit pass: Security info registration (#13295)

Changes:

Before

After

---
title: Troubleshoot combined registration
description: Troubleshoot Microsoft Entra multifactor authentication and self-service password reset combined registration
ms.custom: no-azure-ad-ps-ref, sfi-image-nochange
ms.topic: troubleshooting
ms.date: 03/04/2025
ms.reviewer: tilarso
---
# Troubleshooting combined security information registration
 
The information in this article is meant to guide admins who are troubleshooting issues reported by users of the combined registration experience.
 
## Audit logs
 
The events logged for combined registration are in the Authentication Methods service in the Microsoft Entra audit logs.
 
![Microsoft Entra audit logs interface showing registration events](media/howto-registration-mfa-sspr-combined-troubleshoot/combined-security-info-audit-log.png)
 
The following table lists all audit events generated by combined registration:
 

---
title: Troubleshoot Combined Registration
description: Troubleshoot Microsoft Entra multifactor authentication and self-service password reset combined registration.
ms.custom: no-azure-ad-ps-ref, sfi-image-nochange
ms.topic: troubleshooting
ms.date: 03/04/2025
ms.reviewer: tilarso
---
# Troubleshoot combined security information registration
 
The information in this article helps admins who are troubleshooting issues reported by users of the combined registration experience.
 
## Audit logs
 
The events logged for combined registration are listed in the Microsoft Entra audit logs. In the **Service** column, see **Authentication Methods**.
 
![Screenshot that shows the Microsoft Entra audit logs interface showing registration events.](media/howto-registration-mfa-sspr-combined-troubleshoot/combined-security-info-audit-log.png)
 
The following table lists all audit events generated by combined registration.
 

MODIFIED docs/identity/conditional-access/agent-id.md

Modified by shlipsey3 on Jun 11, 2026 4:24 PM
📖 View on learn.microsoft.com

+12 / -42 lines changed

Commit: ca-updates-061126 (#13450)

Changes:

Before

After

 
- High-level overview of Conditional Access: [What is Conditional Access?](overview.md)
- Guide to managing agent identities across your organization: [Manage agent identities in your organization](../../agent-id/manage-agent-identities-admin.md).
- [Configure policies for autonomous agent access](policy-autonomous-agents.md)
 
## How Conditional Access evaluates agent access requests
> [!NOTE]
> The on-behalf-of flow is also known as delegated access. Agents using this type of access are sometimes called interactive agents or assistive agents, as they involve a user interface for human interaction.
 
:::image type="content" source="media/agent-id/on-behalf-of-agent-flow-diagram.png" alt-text="Diagram showing the OBO flow for agents accessing resources on behalf of a user." lightbox="media/agent-id/on-behalf-of-agent-flow-diagram-expanded.png":::
 
In this flow, the agent can't reuse the user's original token because it was issued for a different audience. Instead, the agent uses the OBO flow to exchange tokens with Microsoft Entra ID, obtaining a new token scoped to the target resource. This token exchange is also evaluated by Conditional Access, letting admins enforce granular controls over which resources agents can access on behalf of the user.
 
Because the user is the subject in this flow, Conditional Access policies target **users and groups**, not agent identities. For step-by-step policy configuration, see [Conditional Access for agents operating on-behalf-of a user](policy-on-behalf-of-agents.md).
 
Agents might access resources without a signed-in user. In this case the agent accesses the resource with its own identity. This flow is also known as client credentials flow, or app only access. All types of agents might use this flow. For more information about how agents authenticate with their own identity, see [Agent OAuth flows: Autonomous apps](../../agent-id/agent-autonomous-app-oauth-flow.md).
 
The following diagram shows the application only access authorization flow.
 
:::image type="content" source="media/agent-id/application-only-flow-diagram.png" alt-text="Diagram showing the application only access flow for agents accessing resources with their own identity." lightbox="media/agent-id/application-only-flow-diagram-expanded.png":::

 
- High-level overview of Conditional Access: [What is Conditional Access?](overview.md)
- Guide to managing agent identities across your organization: [Manage agent identities in your organization](../../agent-id/manage-agent-identities-admin.md).
- [How to target agent identities in Conditional Access](howto-target-agent-identities.md)
- [Configure policies for autonomous agent access](policy-autonomous-agents.md)
 
## How Conditional Access evaluates agent access requests
> [!NOTE]
> The on-behalf-of flow is also known as delegated access. Agents using this type of access are sometimes called interactive agents or assistive agents, as they involve a user interface for human interaction.
 
In this flow, the agent can't reuse the user's original token because it was issued for a different audience. Instead, the agent uses the OBO flow to exchange tokens with Microsoft Entra ID, obtaining a new token scoped to the target resource. This token exchange is also evaluated by Conditional Access, letting admins enforce granular controls over which resources agents can access on behalf of the user.
 
Because the user is the subject in this flow, Conditional Access policies target **users and groups**, not agent identities. For step-by-step policy configuration, see [Conditional Access for agents operating on-behalf-of a user](policy-on-behalf-of-agents.md).
 
Agents might access resources without a signed-in user. In this case the agent accesses the resource with its own identity. This flow is also known as client credentials flow, or app only access. All types of agents might use this flow. For more information about how agents authenticate with their own identity, see [Agent OAuth flows: Autonomous apps](../../agent-id/agent-autonomous-app-oauth-flow.md).
 
This flow applies in the following common scenarios:
 
- **Autonomous agents that operate independently** run in the background, respond to events, or run on a schedule.
  - For example, an agent that generates a daily report and sends the result to a group of employees.

MODIFIED docs/identity/authentication/howto-registration-mfa-sspr-combined.md

Modified by Paula Thurman on Jun 11, 2026 9:26 PM
📖 View on learn.microsoft.com

+19 / -21 lines changed

Commit: [AQ] edit pass: Security info registration (#13295)

Changes:

Before

After

---
title: Enable combined security information registration
description: Learn how to simplify the end-user experience with combined Microsoft Entra multifactor authentication and self-service password reset registration.
ms.topic: how-to
ms.date: 03/04/2025
ms.reviewer: tilarso
---
# Enable combined security information registration in Microsoft Entra ID
 
Before combined registration, users registered authentication methods for Microsoft Entra multifactor authentication and self-service password reset (SSPR) separately. Users were confused that similar methods were used for Microsoft Entra multifactor authentication and SSPR but they had to register for both features. Now, with combined registration, users can register once and get the benefits of both Microsoft Entra multifactor authentication and SSPR.
 
To help you understand the functionality and effects of the new experience, see the [Combined security information registration concepts](concept-registration-mfa-sspr-combined.md).
 
![Combined security information registration enhanced experience](media/howto-registration-mfa-sspr-combined/combined-security-info-more-required.png)
 
## Conditional Access policies for combined registration
 
To secure when and how users register for Microsoft Entra multifactor authentication and self-service password reset, you can use user actions in Conditional Access policy. This functionality may be enabled in organizations that want users to register for Microsoft Entra multifactor authentication and SSPR from a central location, such as a trusted network location during HR onboarding.
 
> [!NOTE]

---
title: Enable Combined Security Information Registration
description: Learn how to simplify the user experience with combined Microsoft Entra multifactor authentication and self-service password reset registration.
ms.topic: how-to
ms.date: 03/04/2025
ms.reviewer: tilarso
---
# Enable combined security information registration in Microsoft Entra ID
 
Before combined registration was introduced, users registered authentication methods for Microsoft Entra multifactor authentication (MFA) and self-service password reset (SSPR) separately. Users were confused that similar methods were used for Microsoft Entra MFA and SSPR, but they had to register for both features. Now, with combined registration, users can register once and get the benefits of both Microsoft Entra MFA and SSPR.
 
To help you understand the functionality and effects of the new experience, see [Combined security information registration concepts](concept-registration-mfa-sspr-combined.md).
 
![Screenshot that shows the combined security information registration enhanced experience.](media/howto-registration-mfa-sspr-combined/combined-security-info-more-required.png)
 
## Conditional Access policies for combined registration
 
To secure when and how users register for Microsoft Entra MFA and SSPR, you can use user actions in a Microsoft Entra Conditional Access policy. Organizations can enable this functionality so that users can register for Microsoft Entra MFA and SSPR from a central location. For example, users can use a trusted network location that they access during human resources onboarding.
 
> [!NOTE]

MODIFIED docs/identity/conditional-access/howto-target-agent-identities.md

Modified by shlipsey3 on Jun 11, 2026 4:24 PM
📖 View on learn.microsoft.com

+6 / -6 lines changed

Commit: ca-updates-061126 (#13450)

Changes:

Before

After

 
# Target agent identities in Conditional Access policies
 
Conditional Access policies for agent identities let you control how AI agents access corporate resources. As your organization deploys more agents, you need policies that target the right agents, evaluate the right signals, and enforce the right controls.
 
This article walks through each section of the Conditional Access policy builder for agents:
 
- Policies targeting all users don't include agent's user accounts.
- The **agent users** option targets agents' user accounts. This option is currently in Preview.
- Agent-based policies apply when agents access resources using their own identity, not on behalf of a user.
- Targeting a blueprint automatically covers all agent identities derived from it, including ones added in the future. For more information about targeting agent identity blueprints, see [Conditional Access for agent identities: Agent identity blueprints](agent-id.md#agent-identity-blueprints).
 
## Target resources
 
Target resources define which resources the policy protects when agents attempt to access them.
 
1. Under **Target resources**, select the resources you want to protect.
1. Under **Include**, select one of the following:
## Related content
 

 
# Target agent identities in Conditional Access policies
 
Conditional Access policies for agent identities let you control how AI agents access corporate resources. As your organization deploys more agents, you need policies that target the right agents, evaluate the right signals, and enforce the right controls. To learn more about how Conditional Access policies for agents work for different scenarios, see [Conditional Access policies for agents](agent-id.md).
 
This article walks through each section of the Conditional Access policy builder for agents:
 
- Policies targeting all users don't include agent's user accounts.
- The **agent users** option targets agents' user accounts. This option is currently in Preview.
- Agent-based policies apply when agents access resources using their own identity, not on behalf of a user.
- Targeting a blueprint automatically covers all agent identities derived from it, including ones added in the future. For more information about targeting agent identity blueprints, see [Conditional Access for agent identities: Agent identity blueprints](agent-id.md#conditional-access-policies-and-agent-identity-blueprints).
 
## Target resources
 
Target resources define which resources the policy protects when agents attempt to access them. To select a target resource in a Conditional Access policy, the resource must have an enterprise application (service principal) in your Microsoft Entra ID tenant. This requirement applies regardless of the data access pattern or resource type, including Microsoft Graph, MCP servers, Open API tools, and custom tools you build. For more information, see [Targeting resources with Conditional Access](concept-conditional-access-cloud-apps.md).
 
For custom MCP servers, Open API-based tools, or other custom tool types, register the tool as an application in Microsoft Entra ID and expose its permissions. For more information, see [How to configure an application to expose a web API](../../identity-platform/quickstart-configure-app-expose-web-apis.md).
 
1. Under **Target resources**, select the resources you want to protect.
1. Under **Include**, select one of the following:

MODIFIED docs/identity-platform/tutorial-desktop-app-maui-sign-in-sign-out.md

Modified by learn-build-service-prod[bot] on Jun 11, 2026 10:20 PM
📖 View on learn.microsoft.com

+4 / -4 lines changed

Commit: Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/entra-docs (branch main) (#13462)

Changes:

Before

After

1. Select **Add**.
1. The *MainView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml" :::
 
1. Save the file.
 
1. In the **Solution Explorer** pane of Visual Studio, expand the **MainView.xaml** file to reveal its code-behind file **MainView.xaml.cs**. Open the **MainView.xaml.cs** and replace the content of the file with following code:
 
   :::code language="csharp" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml.cs" :::
 
The `MainView` class is a content page responsible for displaying the main view of the app. In the constructor, it retrieves the cached user account using the `MSALClientHelper` from the `PublicClientSingleton` instance and enables the sign-in button, if no cached user account is found.
 
1. Select **Add**.
1. The *ClaimsView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/ClaimsView.xaml" :::
 
   This XAML markup code represents the UI layout for a claim view in a .NET MAUI app. It starts by defining the `ContentPage` with a title and disabling the back button behavior.

1. Select **Add**.
1. The *MainView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
 <!--  :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml" ::: -->
 
1. Save the file.
 
1. In the **Solution Explorer** pane of Visual Studio, expand the **MainView.xaml** file to reveal its code-behind file **MainView.xaml.cs**. Open the **MainView.xaml.cs** and replace the content of the file with following code:
 
<!--   :::code language="csharp" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml.cs" ::: -->
 
The `MainView` class is a content page responsible for displaying the main view of the app. In the constructor, it retrieves the cached user account using the `MSALClientHelper` from the `PublicClientSingleton` instance and enables the sign-in button, if no cached user account is found.
 
1. Select **Add**.
1. The *ClaimsView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
<!--   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/ClaimsView.xaml" ::: -->
 
   This XAML markup code represents the UI layout for a claim view in a .NET MAUI app. It starts by defining the `ContentPage` with a title and disabling the back button behavior.

MODIFIED docs/identity-platform/tutorial-mobile-app-maui-sign-in-sign-out.md

Modified by learn-build-service-prod[bot] on Jun 11, 2026 10:20 PM
📖 View on learn.microsoft.com

+4 / -4 lines changed

Commit: Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/entra-docs (branch main) (#13462)

Changes:

Before

After

1. Select **Add**.
1. The *MainView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml" :::
 
1. Save the file.
 
1. In the **Solution Explorer** pane of Visual Studio, expand the **MainView.xaml** file to reveal its code-behind file **MainView.xaml.cs**. Open the **MainView.xaml.cs** and replace the content of the file with following code:
 
   :::code language="csharp" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml.cs" :::
 
   The `MainView` class is a content page responsible for displaying the main view of the app. In the constructor, it retrieves the cached user account using the `MSALClientHelper` from the `PublicClientSingleton` instance and enables the sign-in button, if no cached user account is found.
 
1. Select **Add**.
1. The *ClaimsView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/ClaimsView.xaml" :::
 
   This XAML markup code represents the UI layout for a claim view in a .NET MAUI app. It starts by defining the `ContentPage` with a title and disabling the back button behavior.

1. Select **Add**.
1. The *MainView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
<!--   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml" ::: -->
 
1. Save the file.
 
1. In the **Solution Explorer** pane of Visual Studio, expand the **MainView.xaml** file to reveal its code-behind file **MainView.xaml.cs**. Open the **MainView.xaml.cs** and replace the content of the file with following code:
 
<!--   :::code language="csharp" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/MainView.xaml.cs" ::: -->
 
   The `MainView` class is a content page responsible for displaying the main view of the app. In the constructor, it retrieves the cached user account using the `MSALClientHelper` from the `PublicClientSingleton` instance and enables the sign-in button, if no cached user account is found.
 
1. Select **Add**.
1. The *ClaimsView.xaml* file will open in a new document tab, displaying all of the XAML markup that represents the UI of the page. Replace the XAML markup with the following markup:
 
<!--   :::code language="xaml" source="~/../ms-identity-ciam-dotnet-tutorial/1-Authentication/2-sign-in-maui/Views/ClaimsView.xaml" ::: -->
 
   This XAML markup code represents the UI layout for a claim view in a .NET MAUI app. It starts by defining the `ContentPage` with a title and disabling the back button behavior.

MODIFIED docs/identity/conditional-access/what-if-tool.md

Modified by learn-build-service-prod[bot] on Jun 11, 2026 10:20 PM
📖 View on learn.microsoft.com

+3 / -3 lines changed

Commit: Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/entra-docs (branch main) (#13462)

Changes:

Before

After

 
## Key differences between the What If evaluation API and the legacy experience 
 
The What If Evaluation API is a Microsoft Graph API that is called by the Conditional Access experience. The What If tool powered by the [What If Evaluation API](/graph/api/conditionalaccessroot-evaluate) is currently in preview. The API is different from the legacy What If evaluation in a few ways:
 
1. The What-if API is a public and fully supported API (once the API is generally available). The API can be used through the Conditional Access UX and the MS Graph API.
1. The logic aligns with the authentication logic used during sign-in to provide more accurate policy evaluation.
1. The What-if API expects all sign-in parameters to be defined for the evaluation to provide the most accurate results. If your tenant has policies with specific conditions and the sign-in details for those conditions aren't provided, the What If API can't evaluate those conditions.
 
> [!NOTE]
> For application specification, provide the App ID. Groups of apps, such as **Office 365** or **Microsoft Admin Portals**, don't result in a match.

 
## Key differences between the What If evaluation API and the legacy experience 
 
The [What If Evaluation API](/graph/api/conditionalaccessroot-evaluate) is a Microsoft Graph API that is called by the Conditional Access experience. The API is different from the legacy What If evaluation in a few ways:
 
1. The What If API is a public and fully supported API. You can use it through the Conditional Access experience and the Microsoft Graph API.
1. The logic aligns with the authentication logic used during sign-in to provide more accurate policy evaluation.
1. The What If API expects all sign-in parameters to be defined for the evaluation to provide the most accurate results. If your tenant has policies with specific conditions and the sign-in details for those conditions aren't provided, the What If API can't evaluate those conditions.
 
> [!NOTE]
> For application specification, provide the App ID. Groups of apps, such as **Office 365** or **Microsoft Admin Portals**, don't result in a match.

MODIFIED docs/security-copilot/conditional-access-agent-optimization.md

Modified by shlipsey3 on Jun 11, 2026 4:27 PM
📖 View on learn.microsoft.com

+3 / -3 lines changed

Commit: ca-agent-kb-updates (#13441)

Changes:

Before

After

author: shlipsey3
ms.reviewer: jodah
 
ms.date: 05/22/2026
 
ms.update-cycle: 180-days
ms.service: entra-id
The agent also evaluates all existing enabled policies to propose potential consolidation of similar policies. When the agent identifies a suggestion, you can have the agent update the associated policy with one-click remediation.
 
> [!IMPORTANT]
> The ServiceNow integration, file upload capability, and activity-based runs in the Conditional Access Optimization Agent are currently in preview. This information relates to a prerelease product that might be substantially modified before release. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
 
## Prerequisites
 
- **Risky agents**: The agent suggests a policy to block authentication for high-risk sign-ins. Requires a Microsoft Entra ID P2 license.
- **Policy consolidation**: The agent scans your policy and identifies overlapping settings. For example, if you have more than one policy that has the same grant controls, the agent suggests consolidating those policies into one.
- **Deep analysis**: The agent evaluates policies that correspond to key scenarios to identify outlier policies that have more than a recommended number of exceptions (leading to unexpected gaps in coverage) or no exceptions (leading to possible lockout).
- **Deep analysis MFA gap analysis**: The agent scans all enabled Conditional Access policies in your tenant to identify users not covered by any MFA policy. This scan includes users excluded from baseline policies, missed in group membership, or falling through gaps between overlapping policies. Unlike standard scans, this analysis evaluates the entire tenant configuration and isn't limited to the last 24 hours.
- **Least-privileged access for agent identities (preview)**: The agent identifies agent identities with unused or overprivileged Microsoft Graph permissions. It then recommends least-privilege enforcement, such as removing unused permissions or replacing broad permissions with more specific ones.
 

author: shlipsey3
ms.reviewer: jodah
 
ms.date: 06/10/2026
 
ms.update-cycle: 180-days
ms.service: entra-id
The agent also evaluates all existing enabled policies to propose potential consolidation of similar policies. When the agent identifies a suggestion, you can have the agent update the associated policy with one-click remediation.
 
> [!IMPORTANT]
> The ServiceNow integration and activity-based runs in the Conditional Access Optimization Agent are currently in preview. This information relates to a prerelease product that might be substantially modified before release. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
 
## Prerequisites
 
- **Risky agents**: The agent suggests a policy to block authentication for high-risk sign-ins. Requires a Microsoft Entra ID P2 license.
- **Policy consolidation**: The agent scans your policy and identifies overlapping settings. For example, if you have more than one policy that has the same grant controls, the agent suggests consolidating those policies into one.
- **Deep analysis**: The agent evaluates policies that correspond to key scenarios to identify outlier policies that have more than a recommended number of exceptions (leading to unexpected gaps in coverage) or no exceptions (leading to possible lockout).
- **Deep analysis MFA gap analysis**: This analysis identifies users who aren't protected by any Conditional Access policy that requires MFA or authentication strengths. The agent evaluates both enabled and report-only policies across your entire tenant to calculate how many users fall outside MFA coverage. Common causes include users excluded from policies, missing from required groups, or falling through gaps between overlapping policies. The analysis also provides a sample of impacted users, prioritized by recent sign-in activity, so you can investigate the highest-risk gaps first.
- **Least-privileged access for agent identities (preview)**: The agent identifies agent identities with unused or overprivileged Microsoft Graph permissions. It then recommends least-privilege enforcement, such as removing unused permissions or replacing broad permissions with more specific ones.
 

MODIFIED docs/external-id/customers/reference-oidc-claims-mapping-customers.md

Modified by Gearoid O'Donnell on Jun 11, 2026 3:04 PM
📖 View on learn.microsoft.com

+3 / -3 lines changed

Commit: docs: Email not required for external IdP sign-up (#13284)

Changes:

Before

After

title: Set up claims mapping for OIDC
description: Learn how to configure the standard OpenID Connect claims with the claims your identity provider provides in your external tenant.
ms.topic: how-to
ms.date: 04/17/2026
ms.reviewer: brozbab
ms.custom: it-pro, sfi-image-nochange
ai-usage: ai-assisted
|name|Display Name|Full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the end-user's locale and preferences.|
|given_name|First Name|Given name(s) or first name(s) of the end-user.|
|family_name|Last Name|Surname(s) or family name of the end-user.|
|email (required)|Email|Preferred e-mail address.|
|email_verified|N/A|In the received ID token, the value of this claim is true if the end-user's e-mail address has been verified by the identity provider; otherwise, false. When this claim value is true, this means that your identity provider took affirmative steps to ensure that this e-mail address was controlled by the end-user at the time the verification was performed. If this claim value is false or not mapped to any claim from the identity provider, the user will not be able to create an account. A verified email address is required for account creation. If the email is missing or unverified, an error message appears.|
|phone_number|Phone number|The claim provides the phone number for the user.|
|phone_number_verified|N/A|In the received ID token, the value of this claim is true if the end-user's phone number has been verified; otherwise, false. When this claim value is true, this means that your identity provider took affirmative steps to verify the phone number.|
|street_address|Street Address|Full mailing address, formatted for display or use on a mailing label. In the token response, this field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").|

title: Set up claims mapping for OIDC
description: Learn how to configure the standard OpenID Connect claims with the claims your identity provider provides in your external tenant.
ms.topic: how-to
ms.date: 06/11/2026
ms.reviewer: brozbab
ms.custom: it-pro, sfi-image-nochange
ai-usage: ai-assisted
|name|Display Name|Full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the end-user's locale and preferences.|
|given_name|First Name|Given name(s) or first name(s) of the end-user.|
|family_name|Last Name|Surname(s) or family name of the end-user.|
|email (required by default)|Email|Preferred email address. You can [make it optional](how-to-custom-oidc-federation-customers.md#make-email-optional-for-external-identity-provider-sign-up) for external IdP sign-up scenarios.|
|email_verified|N/A|Indicates whether the identity provider verified the end-user's email address. `true` means the identity provider took affirmative steps to ensure the email address was controlled by the end-user at the time the verification was performed. If the email claim is present, a value of `true` is required for account creation. If the email claim isn't present and [email is configured as optional](how-to-custom-oidc-federation-customers.md#make-email-optional-for-external-identity-provider-sign-up), account creation proceeds without an email address.|
|phone_number|Phone number|The claim provides the phone number for the user.|
|phone_number_verified|N/A|In the received ID token, the value of this claim is true if the end-user's phone number has been verified; otherwise, false. When this claim value is true, this means that your identity provider took affirmative steps to verify the phone number.|
|street_address|Street Address|Full mailing address, formatted for display or use on a mailing label. In the token response, this field MAY contain multiple lines, separated by newlines. Newlines can be represented either as a carriage return/line feed pair ("\r\n") or as a single line feed character ("\n").|

MODIFIED docs/identity/authentication/concept-fido2-hardware-vendor.md

Modified by Justinha on Jun 11, 2026 2:34 PM
📖 View on learn.microsoft.com

+3 / -3 lines changed

Commit: Update IDmelon FIDO2 key transport capabilities

Changes:

Before

After

---
title: Microsoft Entra ID attestation for FIDO2 security key vendors
description: Learn about requirements to prepare FIDO2 hardware for attestation with Microsoft Entra ID.
ms.date: 05/11/2026
ms.reviewer: kimhana
ms.topic: concept-article
---
IDEMIA SOLVO Fly 80 R3 FIDO Card c|dda9aa35-aaf1-4d3c-b6db-7902fd7dbbbf|&#10060;|&#10060;|&#x2705;|&#10060;
IDEMIA SOLVO Fly 80 R3 FIDO Card e|def8ab1a-9f91-44f1-a103-088d8dc7d681|&#10060;|&#10060;|&#x2705;|&#10060;
IDEX CTAP2.1 Biometrics|49a15c1c-3f63-3f51-23a7-b9e00096edd1|&#x2705;|&#x2705;|&#x2705;|&#10060;
IDmelon Authenticator|820d89ed-d65a-409e-85cb-f73f0578f82a|&#x2705;|&#10060;|&#10060;|&#10060;
IDmelon Key|39a5647e-1853-446c-a1f6-a79bae9f5bc7|&#x2705;|&#10060;|&#10060;|&#10060;
IDPrime 3930 FIDO|ca4cff1b-5a81-4404-8194-59aabcf1660b|&#10060;|&#10060;|&#x2705;|&#10060;
IDPrime 3940 FIDO|b50d5e0a-7f81-4959-9b12-f45407407503|&#10060;|&#10060;|&#x2705;|&#10060;
IDPrime 931 Fido|2194b428-9397-4046-8f39-007a1605a482|&#10060;|&#10060;|&#x2705;|&#10060;

---
title: Microsoft Entra ID attestation for FIDO2 security key vendors
description: Learn about requirements to prepare FIDO2 hardware for attestation with Microsoft Entra ID.
ms.date: 06/11/2026
ms.reviewer: kimhana
ms.topic: concept-article
---
IDEMIA SOLVO Fly 80 R3 FIDO Card c|dda9aa35-aaf1-4d3c-b6db-7902fd7dbbbf|&#10060;|&#10060;|&#x2705;|&#10060;
IDEMIA SOLVO Fly 80 R3 FIDO Card e|def8ab1a-9f91-44f1-a103-088d8dc7d681|&#10060;|&#10060;|&#x2705;|&#10060;
IDEX CTAP2.1 Biometrics|49a15c1c-3f63-3f51-23a7-b9e00096edd1|&#x2705;|&#x2705;|&#x2705;|&#10060;
IDmelon Authenticator|820d89ed-d65a-409e-85cb-f73f0578f82a|&#x2705;|&#x2705;|&#10060;|&#x2705;
IDmelon Key|39a5647e-1853-446c-a1f6-a79bae9f5bc7|&#x2705;|&#x2705;|&#x2705;|&#10060;
IDPrime 3930 FIDO|ca4cff1b-5a81-4404-8194-59aabcf1660b|&#10060;|&#10060;|&#x2705;|&#10060;
IDPrime 3940 FIDO|b50d5e0a-7f81-4959-9b12-f45407407503|&#10060;|&#10060;|&#x2705;|&#10060;
IDPrime 931 Fido|2194b428-9397-4046-8f39-007a1605a482|&#10060;|&#10060;|&#x2705;|&#10060;

MODIFIED docs/identity-platform/howto-update-permissions.md

Modified by learn-build-service-prod[bot] on Jun 11, 2026 4:48 PM
📖 View on learn.microsoft.com

+2 / -2 lines changed

Commit: status (#13359)

Changes:

Before

After

 
1. Identify the permissions your app requires, their permission IDs, and whether they're app roles (application permissions) or delegated permissions. For example, if you want to request Microsoft Graph permissions, see [Microsoft Graph permissions](/graph/permissions-reference#permission-scenarios) for a list of permissions and their IDs.
1. Add the required Microsoft Graph permissions to your app.
   The following example calls the [Update application](/graph/api/application-update) API to add the required Microsoft Graph permissions to an app registration identified by object ID `ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0`. This example uses `Analytics.Read` and `Application.Read.All` delegated permission and application permission. Microsoft Graph is identified as a ServicePrincipal object with `00000003-0000-0000-c000-000000000000` as its globally unique `AppId`.
 
   ```http
   PATCH https://graph.microsoft.com/v1.0/applications/aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
1. Identify the permissions for your app.
1. For example, to stop your app from requesting Microsoft Graph permissions, identify the Microsoft Graph permissions for your app, their permission IDs, and whether they're app roles (application permissions) or delegated permissions.
1. Remove the unwanted Microsoft Graph permissions from your app.
   The following example calls the [Update application](/graph/api/application-update) API to remove the unwanted Microsoft Graph permissions from an app registration identified by a sample client ID `ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0`. In this example, the application has `Analytics.Read`, `User.Read`, and `Application.Read.All`. We need to remove `Analytics.Read` and `Application.Read.All` delegated permission and application permission. Microsoft Graph is identified as a ServicePrincipal object with `00000003-0000-0000-c000-000000000000` as its globally unique `AppId` and Microsoft Graph as its `DisplayName` and `AppDisplayName`.
 
    ```http
    PATCH https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444

 
1. Identify the permissions your app requires, their permission IDs, and whether they're app roles (application permissions) or delegated permissions. For example, if you want to request Microsoft Graph permissions, see [Microsoft Graph permissions](/graph/permissions-reference#permission-scenarios) for a list of permissions and their IDs.
1. Add the required Microsoft Graph permissions to your app.
   The following example calls the [Update application](/graph/api/application-update) API to add the required Microsoft Graph permissions to an app registration identified by object ID `00001111-aaaa-2222-bbbb-3333cccc4444`. This example uses `Analytics.Read` and `Application.Read.All` delegated permission and application permission. Microsoft Graph is identified as a ServicePrincipal object with `00000003-0000-0000-c000-000000000000` as its globally unique `AppId`.
 
   ```http
   PATCH https://graph.microsoft.com/v1.0/applications/aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
1. Identify the permissions for your app.
1. For example, to stop your app from requesting Microsoft Graph permissions, identify the Microsoft Graph permissions for your app, their permission IDs, and whether they're app roles (application permissions) or delegated permissions.
1. Remove the unwanted Microsoft Graph permissions from your app.
   The following example calls the [Update application](/graph/api/application-update) API to remove the unwanted Microsoft Graph permissions from an app registration identified by a sample client ID `00001111-aaaa-2222-bbbb-3333cccc4444`. In this example, the application has `Analytics.Read`, `User.Read`, and `Application.Read.All`. We need to remove `Analytics.Read` and `Application.Read.All` delegated permission and application permission. Microsoft Graph is identified as a ServicePrincipal object with `00000003-0000-0000-c000-000000000000` as its globally unique `AppId` and Microsoft Graph as its `DisplayName` and `AppDisplayName`.
 
    ```http
    PATCH https://graph.microsoft.com/v1.0/applications/00001111-aaaa-2222-bbbb-3333cccc4444

MODIFIED docs/identity-platform/reference-breaking-changes.md

Modified by learn-build-service-prod[bot] on Jun 11, 2026 4:48 PM
📖 View on learn.microsoft.com

+2 / -2 lines changed

Commit: status (#13359)

Changes:

Before

After

 
#### Example request
 
`https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0&...`
In this example, the resource tenant (authority) is contoso.com, the resource app is a single-tenant app called `gateway.contoso.com/api` for the Contoso tenant, and the client app is `ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0`. If the client app has a service principal within Contoso.com, this request can continue. If it doesn't, however, then the request will fail with the error above.
 
If the Contoso gateway app were a multitenant application, however, then the request would continue regardless of the client app having a service principal within Contoso.com.

 
#### Example request
 
`https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&...`
In this example, the resource tenant (authority) is contoso.com, the resource app is a single-tenant app called `gateway.contoso.com/api` for the Contoso tenant, and the client app is `00001111-aaaa-2222-bbbb-3333cccc4444`. If the client app has a service principal within Contoso.com, this request can continue. If it doesn't, however, then the request will fail with the error above.
 
If the Contoso gateway app were a multitenant application, however, then the request would continue regardless of the client app having a service principal within Contoso.com.

📋 Microsoft Entra Documentation Changes

📊 Summary

🆕 New Documentation Files

📝 Modified Documentation Files