Review Entra ID application consent without breaking workflows

Consent is different from sign-in

An application can authenticate users and also receive authorization to access an API. Reviewing who can sign in does not establish which data the application can read or change. An automation application may also operate without an interactive user.

Microsoft distinguishes delegated and application permissions. Delegated permissions operate in a user context; application permissions allow access without that context and require administrator consent. The distinction changes the questions you need to ask the workflow owner.

Do not confuse permissions requested in an app registration with effective grants in the tenant. Keep the application identifier and the identifier of the local object under review to avoid mixing integrations with similar names. Names help communication, while identifiers support technical traceability.

Delegated and application access change the decision

Who consents, and for whom?

User and administrator consent depend on permissions and tenant policies. Some delegated permissions require an administrator rather than individual approval. A single-user grant and an all-user grant need separate records. Disabling new user consent does not automatically remove existing grants.

For an enterprise review, identify the authorized population and the workflow using it. A report run by a broadly authorized user has a different context from app-only automation. Ask how each component authenticates and which resources it requests. Where a solution combines both models, inventory both grants: reviewing its sign-in screen does not cover its server component. Tie each access context to a documented operation so the business owner can validate its purpose.

An application can request permissions at different stages. Compare the vendor’s declaration with the functions enabled in your organization. Requested permission is not proof of granted access, and granted access is not proof of usage. Keep three evidence categories separate: requested configuration, recorded grant and observed operation. The decision register should explain discrepancies rather than collapse them into one apparently complete list.

Build the context missing from a portal screenshot

For each application, record its technical owner, business owner, purpose, accessed resource, permission type, granted scope and justification. Include the decision approver, evidence reviewed and next review date. If the owner is unknown, record the gap rather than replacing it with an assumption.

Include backup, migration, management, reporting and automation integrations that may hold broad permissions. The objective is not to label every such tool dangerous. It is to confirm that access supports a necessary function, an accountable owner exists and the workflow remains active.

MSAdvance’s Entra ID application integration guide provides authentication and integration context. This review adds authorization evidence and a decision lifecycle for granted permissions.

App Registrations and Enterprise Applications

Microsoft distinguishes the application object and service principal. App Registrations shows application definitions in their home tenant; Enterprise Applications shows local representations. Retain appId and the service principal object ID; they are not interchangeable. An external application’s registration can reside in its vendor’s tenant.

This model prevents a common mistake: searching for a local registration that does not exist and concluding that the inventory is incomplete. Review the local enterprise application and its grants. Also distinguish an application service principal from a managed identity. Both can belong in the investigation, but maintenance and credential requirements differ. Identify the type before assigning an intervention and do not assume every principal maps to a locally managed app registration.

Ownership and dependencies the directory cannot explain

A directory-listed owner helps locate a team but does not establish who approves the business function. Confirm technical and business owners and a backup. Review contracts, application inventories, repositories and automation with the relevant teams. An application without an identified owner needs an investigation and an assigned decision; leaving the field blank indefinitely does not resolve the exposure.

List scheduled jobs, integration connections, data destinations and consuming users. Include occasional workflows such as month-end processing or recovery that may not appear during an ordinary week. Record the critical dependency and its validation test. If a vendor requests broad permissions, ask for justification by function and version. General commercial documentation does not replace the relationship between permission, API and operation. Keep the vendor response with the decision evidence.

Read grants with the appropriate role

The official enterprise application permission review guidance describes the permissions area and administrator and user consent views. It also explains role requirements and differences between actions available in the portal and through Microsoft Graph or PowerShell.

Start with read-only investigation. Capture the granted set and its context before proposing changes. Do not elevate an account to Global Administrator for convenience. Permission to review, revoke and grant access can differ; verify the exact operation and resource involved.

Store any permission export in a repository with suitable access controls. It does not need client secrets or credentials. If you collect usage records, minimize personal information to what is required to validate the integration.

Portal review and operation-specific limits

The documented route is Entra ID > Enterprise apps > All applications > application > Permissions. Distinguish Admin consent from User consent. The review guide requires Cloud Application Administrator or Application Administrator for its procedure. The portal cannot revoke from User consent; it directs those operations to Graph or PowerShell. A visible tab does not establish that every action is available.

Separate three tasks in the plan: read grants, approve a proposal and execute a change. Different people can own them. Document the role used and the duration of administrative access. Inventory reading does not require adding write permissions to an audit client. If a query fails authorization, retain the error and review its requirement instead of turning a read-only investigation into a broad permission grant. Missing evidence must remain visible until resolved.

Read-only Graph v1.0 requests

These examples are HTTP requests for an authorized client, not PowerShell commands. Replace placeholders with object IDs from the tenant under review. The first ID identifies the local client application; resourceId identifies the target API. These requests do not grant or revoke access.

GET https://graph.microsoft.com/v1.0/servicePrincipals/{client-service-principal-id}/oauth2PermissionGrants
GET https://graph.microsoft.com/v1.0/servicePrincipals/{client-service-principal-id}/appRoleAssignments
GET https://graph.microsoft.com/v1.0/servicePrincipals/{resource-service-principal-id}?$select=id,appId,displayName,appRoles,oauth2PermissionScopes

The documented least-privileged permission for oauth2PermissionGrants is Directory.Read.All. For appRoleAssignments, it is Application.Read.All, which also supports service principal reading. For delegated access, check the user’s role as well; Directory Readers is among the roles supported by these operations. Graph client authorization and the Entra role are separate requirements.

Turn query results into interpretable evidence

For oAuth2PermissionGrant, retain id, clientId, resourceId, scope, consentType and principalId. Scope contains space-separated values. Principal identifies consent for one user; AllPrincipals covers all users with a null principalId. For appRoleAssignments, match appRoleId to the resource’s appRoles to resolve the granted permission.

Follow the entire @odata.nextLink URL until no further page is returned. Identify failed queries and do not describe a partial export as a complete inventory. For recent grants, account for replication delays documented for appRoleAssignments. Retain timestamp, tenant, application and request, together with a normalized result another administrator can interpret. Keep authorization headers and tokens out of distributed evidence. The export should show its coverage and unresolved collection errors.

Prioritize capability and impact rather than permission count

Ten bounded read permissions can represent a different risk from one broad write permission. Examine the resource covered, whether the grant affects all users, and whether the application operates interactively or in the background. Data sensitivity and additional resource restrictions also affect the assessment.

Ask what happens if the integration stops working. A reporting workflow may tolerate a test window, while recovery or provisioning could require more careful validation. Dependency does not justify retaining every permission indefinitely, but it does influence the sequence of changes.

This table is an MSAdvance management recommendation. Where compromise is suspected, a periodic access review does not replace the incident response process or its containment priorities.

Interpret sensitive permissions in context

Assess reading, writing, breadth and administrative capability together. Broad read access can expose valuable information; Read does not mean low risk. The ability to change identities or roles requires investigation of who controls the application and its execution. Consult the Graph permission reference for exact description, type and consent requirements rather than inferring scope solely from a name.

Identify additional restrictions verified at the resource. An intention to access only one site does not establish an effective restriction. If proposing a smaller permission, confirm vendor support and whether the API allows the required operation. Design a test for intended access and another proving that an excluded resource cannot be accessed. Preserve both tests’ conditions. A smaller permission name is insufficient evidence of the actual boundary.

Usage, absence of usage and log coverage

Review activity that matches the access model. Service principal sign-ins show nonuser activity and differ from interactive sign-ins. Successful sign-in establishes authentication, not every business operation or use of every permission. Correlate with workflow or resource logs where required.

Before declaring an integration inactive, record the observation window and check license-dependent retention and availability. A monthly task can fall outside a short window. A log gap can prevent a conclusion without justifying indefinite retention of access: assign an owner, test and decision date. Grant review is different from additional governance capabilities that can have their own licensing requirements. Record unavailable evidence and the business owner’s explanation separately.

Prepare a revocation that can be verified

Define the exact grant, approval owner, change window, subsequent tests and rollback criteria. Document the previous state and the permitted recovery option. Do not describe restoration as a universal button: Microsoft documents methods and conditions for restoring revoked permissions that should be checked before making the change.

Granting administrator consent again can apply the set currently requested by the application rather than reconstructing the previous decision automatically. Review the proposed scope before accepting it. Restoring the workflow should not inadvertently grant new capabilities.

After the change, test the workflow and the access that must remain denied. Revoking a grant does not remove data the application previously copied. Those copies need a separate retention or removal decision rather than an assumption that consent withdrawal erases them.

Reducing requests and revoking grants are distinct changes

Microsoft explains that removing a permission from app registration does not revoke its existing grant. For an internally developed integration, coordinate code, requested permissions and local grants. For an external application, agree a supported configuration with the vendor. If only the grant changes while the application continues requesting that permission, investigate the next consent experience before declaring the change stable.

Prepare a change list by grant and resource, including purpose, impact and test. Do not delete the enterprise application merely to remove one permission. Deletion has a different scope and can affect other configuration. If the objective is complete integration retirement, use a specific plan covering connections, credentials, data and owners. A periodic permission review does not replace that procedure. Record the exact object to be changed so execution cannot confuse similar integrations.

Administrator consent and controlled recovery

Roles for granting consent depend on API and permission. Cloud Application Administrator and Application Administrator have an exception for Microsoft Graph app roles; Privileged Role Administrator can consent to any permission. Check that distinction when planning recovery. Do not assume that someone able to read or revoke can regrant every permission.

Retain the previous grant set and the approved post-change set. Define recovery of the exact grant and review the requested set before selecting Grant admin consent. The restoration guide explains that regranting can remove permissions outside the developer’s default set. Service recovery needs an explicit comparison; an old screenshot without identifiers or context can be insufficient. The recovery plan should identify who has the required authorization and when they are available.

Validate after the change

Run the business workflow with the intended identity and conditions, confirm completion and record errors. Include background jobs and relevant occasional tasks. Test access that should remain excluded as well. Saving a portal change does not validate it, and do not promise that previously issued tokens stop working immediately. Define observation and containment according to the resource and case. Where compromise is suspected, follow incident response. Keep the outcome of functional recovery separate from the security conclusion.

Example: a monthly report with unjustified permissions

Consider an integration that prepares a usage report. The owner confirms that it needs certain reads but cannot explain why it retains a write capability. The team reviews the documentation, tests the report in an appropriate environment and proposes removing only the unused capability, with an assigned validation owner.

This example is hypothetical. It does not assert that any reporting tool can operate with a particular permission set. The decision depends on its implementation and the vendor’s requirements. The register should retain that justification and the test evidence.

Develop the case before deciding

In the reporting example, inventory the reads feeding the result and operations that might require writing. Ask the owner for a controlled test report. Compare content, completeness and delivery rather than only the job’s success code. If the vendor does not document a smaller supported set, record the limitation and evaluate alternatives. Do not claim writing is unnecessary because the final report appears to be a read-only output.

Choose a window covering the full cycle. A test outside month-end can miss an additional function. Obtain owner approval and retain service-recovery criteria. After changing the grant, compare results and excluded access. If the test does not explain the behavior, keep the finding open with an owner. Temporarily retaining a permission as an exception needs a reason, conditions and a review date. The illustration does not establish a permission set suitable for every reporting product.

Leave a repeatable review record

• Application and resource identified unambiguously.
• Confirmed technical and business owners.
• Granted permissions and their business need explained.
• Recorded decision, approval and tests.
• Owned exceptions and a planned next review.

The next reviewer should be able to distinguish an approved exception from an unresolved ownership gap. Keep that distinction visible so a future team does not mistake silence for authorization.

A decision register rather than a list of names

For each application and resource, record permission, context, population, need, evidence and decision. Exceptions need an owner, accepted risk, compensating measures and next review. Changes need their identifier, timestamp, executor and tests. Reviewed is insufficient if it does not distinguish retain, reduce, revoke and investigate. The next reviewer must be able to reconstruct the decision without consulting its author. Link restricted technical evidence rather than copying every log into the management summary.

Define triggers as well as a review cycle: vendor changes, new functions, broader permissions, owner departure and workflow retirement. Where several integrations lack context or hold broad access without tests, a specialist audit can organize the inventory, resolve dependencies and plan gradual changes. The intended result is a verifiable technical and operational decision, with visible outstanding work and confirmed owners. Avoid closing a finding merely because the application is familiar or its supplier is well known.

Official documentation and scope

• Microsoft: Application objects and service principals
• Microsoft: User and admin consent
• Microsoft: Review application permissions
• Microsoft: Graph: delegated grants
• Microsoft: Graph: application grants
• Microsoft: Graph permissions reference
• Microsoft: Restore permissions

The review method, prioritization and example are MSAdvance recommendations. Read-only queries require appropriate authorization and permissions. Check operation-specific conditions before executing changes.