Entra Account Discovery: Reconcile Access

The directory can look tidy while a connected application still contains accounts created manually several years ago. Reviewing enterprise-application assignments alone does not establish that those local accounts are gone.

Microsoft’s 12 October Entra roundup highlights preview group discovery alongside application-account discovery.

The value is a better reconciliation queue, provided the report is interpreted with its matching and connector limits in mind.

Start from the application’s view

Microsoft’s discovery documentation separates results into local identities, matching but unassigned identities, and matching assigned identities. A local result can be a former employee, a service account, a manually created group or simply a failed match.

Give the report to an application owner who can explain how that service is used. The identity team can identify a directory mismatch; it may not know that an apparently unused account owns a scheduled export or an emergency support route.

Record the report date, connector, identity types included and current matching rule. Retain the application’s own inventory for comparison. A list without its scope can become misleading when passed to another team.

The existing OAuth consent audit covers access granted to applications. This review looks in the other direction: identities that exist inside the application and the access they hold there.

Check matching before classifying risk

Discovery currently needs a direct matching attribute and uses the first matching attribute. Expression-based matching is not supported by that experience, even though ordinary provisioning supports a wider set of mapping behaviours.

That difference can explain why an integration provisions successfully but discovery produces unexpected local accounts. Compare a few known users in both systems before treating the report as a list of orphaned identities.

For example, an application might retain a previous email address while Entra contains the current address. That is an illustrative data-quality case, not proof that any particular account is safe. Confirm the person, immutable identifiers where available and application ownership before adjusting the match.

Do not change production matching rules casually to make the report look cleaner. Matching controls which existing target account receives future updates. Review the effect on normal provisioning and test the proposed mapping separately.

Reconcile counts and coverage

Account discovery depends on the target application’s supported listing and pagination behaviour. Microsoft documents excluded connectors and separate limitations for group discovery. Confirm the specific application and identity type before recording the service as covered.

SCIM’s protocol specification explains pagination and notes that paged results are not a frozen snapshot: underlying resources can change between requests. This matters when comparing a discovery run with an application export taken at another time.

Ask three practical questions:

1. Does the application expose the relevant users and groups through its supported API?
2. Has the collection completed across all pages?
3. Can differences from the application’s own inventory be explained by scope, matching or timing?

An empty report needs investigation when the application owner knows accounts exist. A large report needs reconciliation before it becomes a bulk-removal plan.

Give every finding an explicit decision

Use a review record containing the application identifier, directory match if any, owner, access purpose, dependency and proposed action. Good actions include correcting a verified match, bringing an approved account under managed provisioning, retaining an owned exception or removing confirmed unnecessary access.

A group requires its own review. Its name does not tell you whether it controls an application role, an export or a support function. Inspect the permissions and dependencies that the application actually applies.

For removals, start with a small set of confirmed redundant test or low-risk accounts. Preserve the approved recovery information and use the application’s supported disable or removal procedure. Avoid a script that deletes every identity in the “local” category.

For accounts brought under provisioning, validate an ordinary attribute update and the expected deprovisioning behaviour in a controlled test. Assignment is a change in management responsibility and should be accepted by both teams.

Repeat discovery after the changes, reconcile the differences and record remaining exceptions with an owner and review date. The aim is a defensible account inventory whose gaps are understood. A lower count is useful only when it represents access that was correctly reviewed.

References

• Microsoft — October Entra announcement, 12 October 2026. Accessed 17 October 2026.
• Microsoft — Discover identities in target applications. Accessed 17 October 2026.
• IETF — IETF RFC 7644: SCIM protocol, sections 3.4.2 and 3.4.2.4. Accessed 17 October 2026.
• Microsoft — Customise provisioning attribute mappings. Accessed 17 October 2026.