Discover identities in target applications with account discovery
In brief
Account discovery now covers users and groups, classifying them as local, unassigned, or assigned identities. Group discovery is identified as being in preview, and correlation requires a direct matching attribute.
What Entra admins need to know
Administrators can assess unmanaged groups alongside users, but should account for the preview status and matching-attribute requirement.
This editorial summary was generated by AI from the documentation changes. Verify important details in the full Microsoft Learn article.
Documentation change
The comparison below shows only the changed extract. Use the full-page view for complete context.
Discover identities in target applications with account discovery
When organizations adopt Microsoft Entra ID for application provisioning, target applications often already contain user accountsusers and groups that were created before provisioning was configured. Account discovery helps you find these existing accounts,uses the Discover identities experience to retrieve users and groups from a target application, match them to corresponding users and groups in Microsoft Entra ID users,ID, and categorize themclassify the results so you can bring unmanaged identities under governance. After onboarding to provisioning, application administrators can manually create accounts in the application. ThisThe discovery report allows organizations tohelps you identify local or orphan accountsidentities both during initial onboarding and after they have operationalized provisioning.during ongoing provisioning operations.
Account discovery retrieves all user accountsusers and groups from a target application and classifies them into three categories:
- Local
accountsidentities —AccountsUsers or groups in the target application that have nomatchingcorresponding user or group in Microsoft Entra ID. Theseaccountsidentities might belong to former employees, service accounts, users who were provisioned through a different process, groups created directly in the target application, oraccountsidentities that didn't match due to data quality issues (for example, mismatched or outdated attribute values). - Unassigned
usersidentities —AccountsUsers or groups that match a user or group in Microsoft Entra IDuserbutthe user isnaren't assigned to the enterprise application. Theseusersidentities exist in your directory but don't have the required application assignment for provisioning to manage them. - Assigned
usersidentities —AccountsUsers or groups that match a user or group in Microsoft Entra IDuser who isand are assigned to the enterprise application. Theseaccountsidentities are fully managed by the provisioning service.
This classification gives you visibility into who has access to your applications and helps you identify accountsidentities that should be governed, reassigned, or removed.
Prerequisites
The Microsoft Entra ID GovernancePrerequisites
add-on license or Microsoft Entra Suite. For details on feature availability by license, see Microsoft Entra ID Governance licensing fundamentals.- An enterprise application configured for provisioning with valid credentials and a successful test connection.
- A direct matching attribute mapping configured between Microsoft Entra ID and the target application. Account discovery uses the first matching attribute to correlate users and groups between the two systems.
- One of the following roles: Application Administrator, Cloud Application Administrator, or Hybrid Identity Administrator.
Known limitations
- Account discovery requires a direct matching attribute for
usercorrelation. Expression-based transformations aren't supported for matching. - If multiple matching attributes are configured, only the first matching attribute is used.
Application support
For SCIM-based connectors, account discovery requires that the application support RFC 7644, Section 3.4.2.4.
Connectors with established discovery behavior
Customers using account discovery with the following applications consistently receive complete discovery results:
Atlassian CloudSCIMSalesforceSAP Cloud Identity ServicesECMA (enables support for on-premises applications through SQL, LDAP, web services, and PowerShell connectors)GitHub Enterprise Cloud (see List SCIM provisioned identities for limitations)
Connectors that do not support discovery
Account discovery is currently unsupported for the following applications:
HR provisioning (Workday, SAP SuccessFactors, API-driven provisioning)ServiceNowAmazon Web Services (AWS)SnowflakeCross-tenant synchronizationCloud syncGroup provisioning to Active Directory
All other connectors
Account discovery can be enabled for all other supported connectors.provisioning connectors except those listed below. For account discovery to work, the target application must implement SCIM pagination as described in RFC 7644, Section 3.4.2.4. Discovery outcomes might vary depending on whether the target application supports listing users and groups and pagination through its SCIM API. If your discovery report has zero results, verify that you configured a single direct matching attribute (no expressions) in your attribute mappings. Next, verify with the application vendor that the application supports pagination in accordance with RFC 7644, Section 3.4.2.4.
The following connectors and provisioning scenarios don't support user or group discovery at this time: Adobe Identity Management, Amazon Web Services (AWS), Cloud sync, Cross-tenant synchronization and cross-cloud synchronization, Freshservice, Group provisioning to Active Directory, HR provisioning (Workday, SAP SuccessFactors, HiBob, and API-driven provisioning), LinkedIn Learning, LinkedIn Sales Navigator, N-able, ServiceNow, and Snowflake.
The following connectors and provisioning scenarios support user discovery, but don't support group discovery at this time: ECMA, Google Cloud, and Google Workspace.
Discover identities in a target application
To discover existing user accountsusers and groups in a target application:
- Sign in to the Microsoft Entra admin center as at least an Application Administrator.
- Browse to Identity > Applications > Enterprise applications.
- Verify that the provisioning configuration has valid credentials and a successful test connection.
- Select Discover identities.
The provisioning service retrieves all user accountsusers and groups from the target application and displays them organized by category. The discovery takes at least 30 minutes to generate a report. The more accountsidentities that are included in the target application, the longer the report takes. For example, an application with 250,000 accountsidentities might take 12 hours or more to generate a discovery report.
Review discovered accountsidentities
After the discovery process completes, review the results in each category.
Local accountsidentities
Local accountsidentities exist in the target application but have no matchingcorresponding user or group in Microsoft Entra ID. These accountsidentities might represent:
- Former employees whose directory accounts were removed but whose application accounts weren't deprovisioned.
- Service accounts or shared accounts created directly in the application.
- Users provisioned through a separate process that didn't use Microsoft Entra ID.
- Groups created directly in the target application.
- A data quality issue that prevents a match.
Review these accountsidentities to determine whether they should be removed from the target application, matched to an existing user or group in Microsoft Entra ID user,ID, or kept as-is.
Unassigned usersidentities
Unassigned usersidentities match a user or group in Microsoft Entra ID user based on the matching attribute but aren't assigned to the enterprise application. To bring these accountsidentities under provisioning management:
- Navigate to the enterprise application's Users and groups page.
- Assign the appropriate users or groups to the application.
- After assignment, the provisioning service manages these
accountsidentities on subsequent provisioning cycles.
Assigned usersidentities
Assigned usersidentities match a user or group in Microsoft Entra ID user who isthat's already assigned to the application. These accountsidentities are fully managed by the provisioning service. No action is needed unless you want to review or update their attribute mappings.
Assign correlated users to your enterprise application and/or access packages
- "Are any account discovery reports still in progress?"
- "Get identity correlation report
<report-id>." - "List the identities in identity correlation report
<report-id>." - "Which identities in report
<report-id>are localaccounts?identities?" - "Which identities in report
<report-id>match a Microsoft Entrausersuser or group but don't have an application assignment?" - "Which identities in report
<report-id>failed to correlate?"
Depending on the question, the MCP server can execute requests such as:
| Correlation category | Microsoft Graph status | Description |
|---|---|---|
| Assigned |
correlatedAssigned |
The target identity matches |
| Unassigned |
correlatedNotAssigned |
The target identity matches |
| Local |
uncorrelated |
No corresponding user or group in Microsoft Entra ID |
| Correlation failure | failToCorrelate |
The correlation process couldn't evaluate the identity successfully. Review the error information returned for the identity. |
Example investigation
- Ask, "Show me the latest completed account discovery report for service principal
<service-principal-id>." - Copy the report ID returned by the MCP client.
- Ask, "List the identities in identity correlation report
<report-id>." - Ask another question that includes the report ID, such as, "Which identities in report
<report-id>are localaccounts?identities?" or "Which identities in report<report-id>failed to correlate?"
Review the Microsoft Graph request displayed by the MCP client before relying on the result. For large reports, the client might need to follow @odata.nextLink to retrieve additional pages.
For application developers
For account discovery to work with a target application, the application must support SCIM pagination as described in RFC 7644, Section 3.4.2.4. The provisioning service uses pagination to retrieve all user accountsusers and groups from the target application during the discovery process.
@@ -1,6 +1,6 @@ --- title: Discover identities in target applications with account discovery-description: Learn how to use account discovery to find and categorize existing user accounts in target applications, match them to Microsoft Entra ID users, and prepare for provisioning governance.+description: Learn how to use account discovery to find and categorize existing users and groups in target applications, match them to Microsoft Entra ID identities, and prepare for provisioning governance. ms.topic: how-to ms.date: 08/11/2026 ms.reviewer: arvinh@@ -8,21 +8,25 @@ ms.service: entra-id ms.subservice: app-provisioning ai-usage: ai-assisted -#Customer intent: As an IT administrator, I want to discover existing user accounts in target applications and match them to Microsoft Entra ID identities so I can identify unmanaged accounts and bring them under governance.+#Customer intent: As an IT administrator, I want to discover existing users and groups in target applications and match them to Microsoft Entra ID identities so I can identify unmanaged accounts and bring them under governance. --- # Discover identities in target applications with account discovery -When organizations adopt Microsoft Entra ID for application provisioning, target applications often already contain user accounts that were created before provisioning was configured. Account discovery helps you find these existing accounts, match them to Microsoft Entra ID users, and categorize them so you can bring unmanaged identities under governance. After onboarding to provisioning, application administrators can manually create accounts in the application. This report allows organizations to identify local or orphan accounts both during initial onboarding and after they have operationalized provisioning.+When organizations adopt Microsoft Entra ID for application provisioning, target applications often already contain users and groups that were created before provisioning was configured. Account discovery uses the **Discover identities** experience to retrieve users and groups from a target application, match them to corresponding users and groups in Microsoft Entra ID, and classify the results so you can bring unmanaged identities under governance. After onboarding to provisioning, application administrators can manually create accounts in the application. The discovery report helps you identify local or orphan identities both during initial onboarding and during ongoing provisioning operations. -Account discovery retrieves all user accounts from a target application and classifies them into three categories:+Account discovery retrieves users and groups from a target application and classifies them into three categories: -- **Local accounts** — Accounts in the target application that have no matching user in Microsoft Entra ID. These accounts might belong to former employees, service accounts, users who were provisioned through a different process, or accounts that didn't match due to data quality issues (for example, mismatched or outdated attribute values).-- **Unassigned users** — Accounts that match a Microsoft Entra ID user but the user isn't assigned to the enterprise application. These users exist in your directory but don't have the required application assignment for provisioning to manage them.-- **Assigned users** — Accounts that match a Microsoft Entra ID user who is assigned to the enterprise application. These accounts are fully managed by the provisioning service.+- **Local identities** — Users or groups in the target application that have no corresponding user or group in Microsoft Entra ID. These identities might belong to former employees, service accounts, users who were provisioned through a different process, groups created directly in the target application, or identities that didn't match due to data quality issues (for example, mismatched or outdated attribute values).+- **Unassigned identities** — Users or groups that match a user or group in Microsoft Entra ID but aren't assigned to the enterprise application. These identities exist in your directory but don't have the required application assignment for provisioning to manage them.+- **Assigned identities** — Users or groups that match a user or group in Microsoft Entra ID and are assigned to the enterprise application. These identities are fully managed by the provisioning service. -This classification gives you visibility into who has access to your applications and helps you identify accounts that should be governed, reassigned, or removed.+This classification gives you visibility into who has access to your applications and helps you identify identities that should be governed, reassigned, or removed.++> [!IMPORTANT]+> Group discovery is 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 @@ -30,48 +34,25 @@ Before you can use account discovery, the following must be in place: - The [Microsoft Entra ID Governance](https://www.microsoft.com/security/business/identity-access/microsoft-entra-id-governance) add-on license or [Microsoft Entra Suite](https://www.microsoft.com/security/business/microsoft-entra-pricing). For details on feature availability by license, see [Microsoft Entra ID Governance licensing fundamentals](/entra/id-governance/licensing-fundamentals#features-by-license). - An enterprise application configured for provisioning with valid credentials and a successful test connection.-- A **direct matching attribute mapping** configured between Microsoft Entra ID and the target application. Account discovery uses the first matching attribute to correlate users between the two systems.+- A **direct matching attribute mapping** configured between Microsoft Entra ID and the target application. Account discovery uses the first matching attribute to correlate users and groups between the two systems. - One of the following roles: [Application Administrator](../../identity/role-based-access-control/permissions-reference.md#application-administrator), [Cloud Application Administrator](../../identity/role-based-access-control/permissions-reference.md#cloud-application-administrator), or [Hybrid Identity Administrator](../../identity/role-based-access-control/permissions-reference.md#hybrid-identity-administrator). ## Known limitations -- Account discovery requires a **direct matching attribute** for user correlation. Expression-based transformations aren't supported for matching.+- Account discovery requires a **direct matching attribute** for correlation. Expression-based transformations aren't supported for matching. - If multiple matching attributes are configured, only the **first** matching attribute is used. ## Application support -For SCIM-based connectors, account discovery requires that the application support [RFC 7644, Section 3.4.2.4](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.4).--### Connectors with established discovery behavior--Customers using account discovery with the following applications consistently receive complete discovery results:--- Atlassian Cloud-- SCIM-- Salesforce-- SAP Cloud Identity Services-- ECMA (enables support for on-premises applications through SQL, LDAP, web services, and PowerShell connectors)-- GitHub Enterprise Cloud (see [List SCIM provisioned identities](https://docs.github.com/enterprise-cloud@latest/rest/scim/scim?apiVersion=2026-03-10#list-scim-provisioned-identities) for limitations)--### Connectors that do not support discovery--Account discovery is currently unsupported for the following applications:--- HR provisioning (Workday, SAP SuccessFactors, API-driven provisioning)-- ServiceNow-- Amazon Web Services (AWS)-- Snowflake-- Cross-tenant synchronization-- Cloud sync-- Group provisioning to Active Directory+Account discovery is enabled for all provisioning connectors except those listed below. For account discovery to work, the target application must implement SCIM pagination as described in [RFC 7644, Section 3.4.2.4](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.4). Discovery outcomes vary depending on whether the target application supports listing users and groups and pagination through its SCIM API. If your discovery report has zero results, verify that you configured a single direct matching attribute (no expressions) in your attribute mappings. Next, verify with the application vendor that the application supports pagination in accordance with [RFC 7644, Section 3.4.2.4](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.4). -### All other connectors+The following connectors and provisioning scenarios don't support user or group discovery at this time: Adobe Identity Management, Amazon Web Services (AWS), Cloud sync, Cross-tenant synchronization and cross-cloud synchronization, Freshservice, Group provisioning to Active Directory, HR provisioning (Workday, SAP SuccessFactors, HiBob, and API-driven provisioning), LinkedIn Learning, LinkedIn Sales Navigator, N-able, ServiceNow, and Snowflake. -Account discovery can be enabled for all other supported connectors. Discovery outcomes might vary depending on whether the target application supports listing users and pagination through its SCIM API. If your discovery report has zero results, verify that you configured a single direct matching attribute (no expressions) in your attribute mappings. Next, verify with the application vendor that the application supports pagination in accordance with [RFC 7644, Section 3.4.2.4](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.4).+The following connectors and provisioning scenarios support user discovery, but don't support group discovery at this time: ECMA, Google Cloud, and Google Workspace. ## Discover identities in a target application -To discover existing user accounts in a target application:+To discover existing users and groups in a target application: 1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Application Administrator](../../identity/role-based-access-control/permissions-reference.md#application-administrator). 1. Browse to **Identity** > **Applications** > **Enterprise applications**.@@ -80,34 +61,35 @@ To discover existing user accounts in a target application: 1. Verify that the provisioning configuration has valid credentials and a successful test connection. 1. Select **Discover identities**. -The provisioning service retrieves all user accounts from the target application and displays them organized by category. The discovery takes at least 30 minutes to generate a report. The more accounts that are included in the target application, the longer the report takes. For example, an application with 250,000 accounts might take 12 hours or more to generate a discovery report.+The provisioning service retrieves users and groups from the target application and displays them organized by category. The discovery takes at least 30 minutes to generate a report. The more identities that are included in the target application, the longer the report takes. For example, an application with 250,000 identities might take 12 hours or more to generate a discovery report. -## Review discovered accounts+## Review discovered identities After the discovery process completes, review the results in each category. -### Local accounts+### Local identities -Local accounts exist in the target application but have no matching user in Microsoft Entra ID. These accounts might represent:+Local identities exist in the target application but have no corresponding user or group in Microsoft Entra ID. These identities might represent: - Former employees whose directory accounts were removed but whose application accounts weren't deprovisioned. - Service accounts or shared accounts created directly in the application. - Users provisioned through a separate process that didn't use Microsoft Entra ID.+- Groups created directly in the target application. - A data quality issue that prevents a match. -Review these accounts to determine whether they should be removed from the target application, matched to an existing Microsoft Entra ID user, or kept as-is.+Review these identities to determine whether they should be removed from the target application, matched to an existing user or group in Microsoft Entra ID, or kept as-is. -### Unassigned users+### Unassigned identities -Unassigned users match a Microsoft Entra ID user based on the matching attribute but aren't assigned to the enterprise application. To bring these accounts under provisioning management:+Unassigned identities match a user or group in Microsoft Entra ID based on the matching attribute but aren't assigned to the enterprise application. To bring these identities under provisioning management: 1. Navigate to the enterprise application's **Users and groups** page. 1. Assign the appropriate users or groups to the application.-1. After assignment, the provisioning service manages these accounts on subsequent provisioning cycles.+1. After assignment, the provisioning service manages these identities on subsequent provisioning cycles. -### Assigned users+### Assigned identities -Assigned users match a Microsoft Entra ID user who is already assigned to the application. These accounts are fully managed by the provisioning service. No action is needed unless you want to review or update their attribute mappings.+Assigned identities match a user or group in Microsoft Entra ID that's already assigned to the application. These identities are fully managed by the provisioning service. No action is needed unless you want to review or update their attribute mappings. ## Assign correlated users to your enterprise application and/or access packages @@ -226,8 +208,8 @@ After you connect your MCP client, you can ask questions such as: - "Are any account discovery reports still in progress?" - "Get identity correlation report `<report-id>`." - "List the identities in identity correlation report `<report-id>`."-- "Which identities in report `<report-id>` are local accounts?"-- "Which identities in report `<report-id>` match Microsoft Entra users but don't have an application assignment?"+- "Which identities in report `<report-id>` are local identities?"+- "Which identities in report `<report-id>` match a Microsoft Entra user or group but don't have an application assignment?" - "Which identities in report `<report-id>` failed to correlate?" Depending on the question, the MCP server can execute requests such as:@@ -245,9 +227,9 @@ The Microsoft Graph API represents the account discovery categories with the fol | Correlation category | Microsoft Graph status | Description | |---|---|---|-| Assigned users | `correlatedAssigned` | The target identity matches an Entra user which is assigned to the enterprise application. |-| Unassigned users | `correlatedNotAssigned` | The target identity matches an Entra user, but the Entra user is not assigned to the enterprise application. |-| Local accounts | `uncorrelated` | No corresponding Microsoft Entra ID user was found for the target identity. |+| Assigned identities | `correlatedAssigned` | The target identity matches a user or group in Microsoft Entra ID that's assigned to the enterprise application. |+| Unassigned identities | `correlatedNotAssigned` | The target identity matches a user or group in Microsoft Entra ID, but that user or group isn't assigned to the enterprise application. |+| Local identities | `uncorrelated` | No corresponding user or group in Microsoft Entra ID was found for the target identity. | | Correlation failure | `failToCorrelate` | The correlation process couldn't evaluate the identity successfully. Review the error information returned for the identity. | ### Example investigation@@ -257,7 +239,7 @@ The following conversation illustrates how an administrator might investigate a 1. Ask, "Show me the latest completed account discovery report for service principal `<service-principal-id>`." 1. Copy the report ID returned by the MCP client. 1. Ask, "List the identities in identity correlation report `<report-id>`."-1. Ask another question that includes the report ID, such as, "Which identities in report `<report-id>` are local accounts?" or "Which identities in report `<report-id>` failed to correlate?"+1. Ask another question that includes the report ID, such as, "Which identities in report `<report-id>` are local identities?" or "Which identities in report `<report-id>` failed to correlate?" Review the Microsoft Graph request displayed by the MCP client before relying on the result. For large reports, the client might need to follow `@odata.nextLink` to retrieve additional pages. @@ -293,4 +275,4 @@ Use the search and filter capabilities to find specific accounts: ## For application developers -For account discovery to work with a target application, the application must support SCIM pagination as described in [RFC 7644, Section 3.4.2.4](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.4). The provisioning service uses pagination to retrieve all user accounts from the target application during the discovery process.+For account discovery to work with a target application, the application must support SCIM pagination as described in [RFC 7644, Section 3.4.2.4](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2.4). The provisioning service uses pagination to retrieve all users and groups from the target application during the discovery process. 