An app registration can look harmless until it carries tenant-wide access, long-lived secrets, and a consent grant nobody remembers approving. That is where excess privilege hides.

If you need to audit Entra app registrations, start with permissions, owners, and credentials, then trace each app back to a clear business need. In 2026, the Entra admin center still shows the same core objects, although blade names and menu labels can vary a little by tenant.

The safest audits focus on what the app can do on its own, what it can do on behalf of a user, and whether anyone still uses it. The steps below keep that review practical.

Table of contents

• Start with a complete app inventory
• Review delegated and application permissions separately
• Check admin consent, app roles, and OAuth scopes
• Look for unused apps, stale credentials, and weak ownership
• Turn findings into least-privilege changes
• FAQs

Start with a complete app inventory

Audit Entra app registrations at tenant scale

Start with every application object and its matching service principal. The app registration lives in the home tenant, while the service principal is the live identity that receives consent and assignments. If you only review one side, you miss half the risk.

Build an inventory with these fields:

• Owner and backup owner.
• Application ID and service principal ID.
• Publisher verification status.
• Delegated scopes and application permissions.
• Admin consent date and consent grant source.
• Secret and certificate expiry dates.
• Last sign-in or last API use.
• Business purpose and data owner.

Use Microsoft Graph exports or the Entra portal if that is faster for your team. The exact blade names may differ a bit across tenants, but the core data is still there. What matters is consistency, because a one-time spreadsheet turns into noise unless you refresh it on a schedule.

If an app has no named owner, no clear business use, or no current credential owner, mark it for review right away. That early triage saves time later.

Review delegated and application permissions separately

Delegated permissions and application permissions do different jobs, so they need different checks. Delegated permissions act on behalf of a signed-in user. Application permissions act on their own, which makes them easier to miss and harder to justify.

A side-by-side view helps keep the review honest.

Permission type	How it works	What to check	Common risk
Delegated permissions	The app uses the signed-in user’s access	Scope list, user role, consent source	A privileged user can make the app far more powerful
Application permissions	The app acts without a user present	App roles, tenant-wide grants, admin consent	The app can reach data all by itself

Search for broad scopes and roles such as Directory.ReadWrite.All, Application.ReadWrite.All, Mail.ReadWrite, and Files.ReadWrite.All. If the permission set is larger than the app’s job, it usually is.

Application permissions deserve the closest review because they work without a user in the loop.

Microsoft documents how to review application permission activity logs, which helps when you need to trace a grant back to an event. For a broader checklist on app control and consent hygiene, CoreView’s Entra app registration security guide gives a useful outside view.

Check admin consent, app roles, and OAuth scopes

Admin consent review is where many risky grants hide. Check who approved the permission, when it happened, and whether the app still has a business owner who understands the request. If your tenant still allows user consent, review those settings as well.

OAuth scopes describe delegated access. App roles describe application permissions. That difference matters, because the wrong scope can give an app access far beyond the original request. Review the app’s scopes, the enterprise application’s app roles, and any consent grants that cover more resources than the app should touch.

The quickest red flags are easy to spot:

• The app asks for tenant-wide mail, file, or directory access.
• Consent came from a privileged admin during a rushed change.
• The publisher is unknown or not verified.
• The grant covers several resources, but the use case is narrow.

A clean admin consent trail should answer three questions without extra work. Who approved it? Why was it needed? Does the app still deserve it? If those answers are fuzzy, the grant needs a second look.

Look for unused apps, stale credentials, and weak ownership

Unused apps are quiet, so they often stay in place long after the business moved on. Check sign-in logs for the enterprise application, then compare them with audit logs for changes to the app registration. Look for secret additions, certificate changes, owner changes, and new consent grants. Those events tell you when privilege drift starts.

The best indicator of waste is a mismatch between access and activity. An app with broad permissions, no recent sign-ins, and no active owner is a strong removal candidate. Use a review window that fits the app type, because a monthly finance integration and a seasonal app do not age the same way.

Credential hygiene deserves the same attention. Old secrets, forgotten certificates, and multiple live credentials create blind spots. Review for:

• Secrets with no clear owner.
• Credentials that expired and were left in place.
• Multiple active secrets on a low-value app.
• Certificates with no documented rotation plan.

If the app can use managed identity or workload identity federation, replace stored secrets where possible. That cuts down the number of places where an old credential can hide.

Turn findings into least-privilege changes

An audit only matters if it changes the tenant. Start by removing permissions nobody can justify, then shrink the rest. Replace tenant-wide access with narrower scopes, resource-specific permissions, or app policies when the platform supports them.

Fix the control plane too. Restrict who can register apps, tighten user consent, and require admin consent for sensitive permissions. Every app should have a named owner, a review date, and a reason for existing. If the business owner cannot explain the access, the access is probably too broad.

A practical cleanup list usually looks like this:

• Remove unused permissions first.
• Delete stale secrets and certificates.
• Reassign or remove apps with no owner.
• Replace broad app-only access with narrower permissions.
• Add alerts for new consent grants, owner changes, and credential updates.

If your team needs help with a tenant-wide permission review or a cleanup plan, Book a Discovery Call with Bud Consulting. A second set of eyes is often the fastest way to separate real business need from inherited risk.

Conclusion

Excess privilege rarely sits in one obvious place. It spreads across permissions, consent, ownership, and credentials.

When you audit Entra app registrations, review those four pieces together. That gives you a clear picture of what the app can do, who approved it, and whether it still deserves the access it has.

FAQs

What is the difference between an app registration and an enterprise application?

The app registration is the application object in the home tenant. The enterprise application is the service principal that lives in the tenant where access is granted. Audits need both, because consent, assignment, and sign-in activity often show up on the service principal side.

Which permissions are the most risky?

Application permissions with directory-wide, mail-wide, file-wide, or app-management rights deserve the closest review. Delegated permissions can still be risky, especially when privileged users sign in, but app-only access does not need a user present. If the permission set is broader than the job, cut it back.

How often should you audit Entra app registrations?

Most teams do a quarterly review, then add alerts for new consents, new credentials, and owner changes between audits. Faster cycles make sense for high-risk tenants or apps that touch sensitive data. The right schedule is the one that catches drift before it becomes normal.