Entra ID App Permissions Audit: Microsoft 365 Service Principal Security

An administrator can complete strong MFA enrollment while a forgotten application continues reading Microsoft 365 data through an old consent grant. The application may never use that administrator’s current sign-in session. Human access controls and application permissions therefore need separate evidence.

This Entra ID app permissions audit is a reference procedure for a Microsoft 365 tenant with enterprise applications and service principals. It focuses on identifying access, assigning ownership, and reducing permissions through controlled tests. It does not assume that every broad permission is malicious or that an unused-looking integration can be removed without business impact.

1. Start with the tenant’s actual application identities

Inventory enterprise applications as well as app registrations. Record the application client ID, local service principal object ID, display name, publisher information, application type, and owners. Keep the identifiers distinct: a familiar display name is not a reliable key for an audit or incident investigation.

An application registration and its local service principal serve different purposes. The enterprise application’s service principal represents the application in the tenant where access is being reviewed. A third-party application can therefore appear in enterprise applications even when your team does not own its application registration. See Microsoft’s application and service principal model.

Add a business owner and a technical owner for each integration. Record the actual task, such as exporting approved mailbox data or synchronising a defined directory subset. “Required for Microsoft 365” is insufficient justification for tenant-wide access. Where the owner is unknown, investigate the deployment record and usage before deciding how to contain or retire it.

Use our Microsoft 365 and Entra ID hardening guide for the administrator baseline. This audit extends that work to the applications that can access resources independently of everyday human administration.

2. Separate requested permissions from granted access

Review what has actually been granted in the tenant, rather than relying only on the API permissions listed on an app registration. Requested configuration and consented access are different records. Inspect delegated permission grants and application role assignments separately.

Delegated access involves a signed-in user and the granted scopes. App-only access uses the application’s identity without a signed-in user. The same permission name can have different implications depending on the access type. Follow Microsoft’s permissions and consent overview when interpreting the records.

Translate identifiers into resource access

For an application role assignment, identify the resource service principal and resolve the role identifier to the resource’s published permission definition. For a delegated grant, record the resource, scope names, consent type, and any user-specific principal. Do not label an opaque identifier as low risk simply because its meaning has not yet been resolved.

Write a plain-language description of the resulting access. Include the data affected, permitted operations, whether a user context is involved, and any resource-level restrictions. Check the applicable resource’s authorisation model before assuming that a permission is automatically limited to the business scope.

3. Collect grant records through read-only inspection

Use an approved audit identity and the least read permissions supported by the selected Microsoft Graph operation. Check both Graph permissions and any required directory role before collecting records. Do not grant write-capable application administration merely because it is easier than setting up a scoped audit process.

These illustrative HTTP requests inspect app-role assignments for one client service principal and delegated grants filtered to that client’s local object ID. Replace the placeholder with the service principal object ID, not the application client ID.

GET https://graph.microsoft.com/v1.0/servicePrincipals/CLIENT_SP_OBJECT_ID/appRoleAssignments

GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants?$filter=clientId eq 'CLIENT_SP_OBJECT_ID'

Use an authenticated client and encode the query as required. Follow the appRoleAssignments API documentation and the delegated grants API documentation. Handle pagination and preserve collection timestamps so an incomplete first page is not mistaken for a full audit.

The outgoing assignments above show app roles granted to the client. Do not substitute a list of users or applications assigned to the client itself; that answers a different question. Keep the raw identifiers with the resolved names so a later review can reproduce the conclusion.

4. Prioritise by capability and business dependency

Start with access that can modify identities, alter permissions, send mail, or read sensitive data beyond the stated business purpose. Review broad read access as well as write access. An application that can only read may still expose confidential records.

Compare each grant with the documented task. Ask whether the application needs every permitted operation and whether the resource offers a narrower supported authorisation method. Do not replace a working integration with a theoretical permission set that the vendor cannot operate. Obtain a supported least-privilege design and test it.

• Access has a named owner and a documented business purpose.
• The permission type matches the application’s actual authentication flow.
• The resource and data scope match the approved task.
• Credential and federation configuration have an accountable owner.
• Any exception has a reason, expiry, and validation plan.

An unfamiliar publisher, missing owner, broad grant, or unexplained credential should increase review priority, but none of those signals alone proves compromise. Preserve the evidence and investigate the combination. Where active malicious access is suspected, use the incident response process rather than an ordinary maintenance queue.

5. Review who can use or change the application identity

For applications your organisation controls, inspect credential metadata, expiry, federated identity credentials, and ownership. Record where each credential is used and how it is rotated. Collect identifiers and dates; do not copy secret values or private keys into the audit workbook.

Review who can add a new credential or modify federation trust. Removing an old secret does little if an unintended operator retains the ability to create another credential on the same privileged application. Check Azure role assignments and resource-specific authorisation separately from Microsoft Graph consent.

A managed identity or federated credential can remove a stored-secret dependency in a supported design. It does not reduce the permissions of the identity automatically. Review the hosting or deployment authority that can exercise it. Our zero-trust cloud architecture guide connects those workload and deployment boundaries.

Check Conditional Access coverage explicitly

Do not assume that user MFA policies govern app-only token requests. Conditional Access for workload identities requires the applicable Workload Identities Premium licensing and has documented coverage limits. Managed identities and third-party multitenant applications are outside that policy coverage. Validate eligibility before proposing it as the main control.

6. Control new consent and monitor changes

Review the tenant’s user consent settings and the supported route for administrator approval. Microsoft’s user consent configuration guidance describes policy options. Choose the policy against the business’s application intake process and test what users encounter when an integration needs approval.

Publisher verification can inform review, but it should not replace checking the requested capabilities and business purpose. Confirm an application’s identity through the vendor’s trusted support route, especially when the display name or consent request resembles an existing tool.

Monitor application consent, delegated grant changes, and app-role assignments. Use Microsoft’s application-permission audit activities to identify relevant events. Export required evidence before the tenant’s available retention expires, and assign an owner to investigate unexpected changes.

Review service principal sign-ins alongside configuration events. An absence of recent sign-ins in a short window is weak evidence that an application is unnecessary; include scheduled jobs and infrequent business cycles in the assessment.

7. Reduce access through a staged change

Choose one application and one excessive capability for the pilot. Preserve the approved configuration, relevant grant identifiers, vendor requirements, and rollback route. Use a test tenant or a controlled change window appropriate to the integration.

1. Agree the business operations that must continue working.
2. Remove or replace the selected grant through an authorised change.
3. Obtain fresh tokens for the validation flow and allow for documented token behaviour.
4. Confirm required operations still succeed against approved test data.
5. Confirm the removed capability fails on a known test resource.
6. Record evidence, business acceptance, and the next review date.

Do not declare immediate revocation simply because a permission disappeared from a portal. Existing tokens and resource behaviour can affect when an access change becomes observable. A failed request to a nonexistent resource also fails to prove that the intended permission was removed.

Include backup and recovery applications in the review without disabling them casually. Their permissions may be essential to restore operations. Link proposed changes to the independent recovery authority and run the relevant recovery checks before accepting reduced access.

8. Frequently asked questions

Does administrator MFA secure every enterprise application?

No. App-only access uses an application identity. Review its grants, credential paths, ownership, and applicable workload controls separately from user authentication policies.

Can removing requested API permissions remove existing consent?

Do not assume so. Inspect the tenant’s actual grant records and verify the authorised remediation against those records. Then test the effective access using fresh authentication and known resources.

Should every application with broad permissions be deleted?

No. Establish whether the access supports an approved business function, whether a narrower supported design exists, and how to validate the change. Treat suspected malicious applications through incident response with evidence preservation.

9. Conclusion: make application access accountable

A completed audit maps application identity, effective permission, credential authority, and business purpose. Its strongest evidence is a required operation that still works and an unnecessary capability that now fails.

For a scoped tenant review covering human and application access, see StackLocked Microsoft 365 Security. Bring the enterprise application inventory and known integration owners so the assessment can resolve access paths rather than produce an unowned list of warnings.