Entra App Registration Security: Audit & Best Practices

App registrations vs enterprise apps vs service principals

This is the single most common point of confusion in Entra ID, and it is worth getting precisely right before anything else in this article makes sense.

An app registration is the global definition of an application: its name, its supported account types, its redirect URIs, the API permissions it requests, and its credentials (client secrets or certificates). It lives in the tenant where the application was originally registered, and it is represented by an applicationRegistration object with its own appId.

A service principal is the local instance of that application in a given tenant. When an app registration is created, Entra ID automatically creates a matching service principal in the same tenant. When another tenant's user consents to that same application (in a multi-tenant scenario, for example), Entra ID creates a second service principal for it, this time in the consenting tenant, with no local app registration of its own. The service principal is the object that actually gets assigned permissions, appears in sign-in logs, and is checked at runtime when the application authenticates or acts. In practical terms: the app registration is the blueprint, the service principal is the object that does the work.

Enterprise application is not a third distinct object type. It is simply the label Microsoft uses in the Entra admin centre's portal blade for a service principal, specifically when you are viewing it from the perspective of "an application operating in my tenant" rather than "an application I built and registered." A first-party app you registered yourself shows up in App registrations. A gallery app, a multi-tenant app from another organisation, or any service principal where you are the consuming tenant rather than the home tenant shows up in Enterprise applications. Under the hood, both blades are looking at service principal objects, just filtered and labelled differently for the two most common ways people think about them.

For an audit, this distinction matters practically: permissions, sign-in activity, and owner assignments are properties of the service principal, not the app registration. Credentials (secrets and certificates) belong to the app registration. A thorough review has to look at both objects for a given application, not just whichever one happens to be easier to find in the portal.

Credential hygiene

App registrations authenticate using one of two mechanisms: client secrets or certificates. A client secret is a shared string, generated by Entra ID and copied into the application's configuration, typically an environment variable or a secrets store. A certificate uses a public/private key pair, where only the public key is uploaded to Entra ID and the private key never has to be shared or transmitted anywhere.

Certificates are the stronger option, and not by a small margin. A leaked client secret is immediately usable by whoever has it, with no additional step required. A certificate's private key, properly stored, is harder to exfiltrate in the first place, and certificate-based authentication is generally easier to rotate without touching application code, since the trust relationship is based on the key pair rather than a value baked into a config file.

The more urgent issue, though, is expiry. A client secret can be set to expire in as little as a day or as long as Entra ID allows (historically up to two years, though Microsoft has been tightening defaults). A long-lived client secret is not just a best-practice nag item, it is itself a finding worth flagging on its own terms: it is a credential with a long window in which a leak, once it happens, stays exploitable. The same logic that applies to long-lived passwords for human accounts applies here, arguably more so, because nobody is prompted to rotate an app secret the way a user is prompted to change a password.

The operational risk compounds at scale. A tenant with a handful of app registrations can track expiry dates on a spreadsheet. A tenant with dozens or hundreds cannot, and this is where expiry sprawl becomes a genuine incident risk rather than a housekeeping annoyance. When a secret expires unexpectedly, the application it belongs to typically fails silently or noisily depending on how well it was built, and the person who gets paged is rarely the person who originally created the registration. Tracking every credential's expiry date, and knowing well in advance which ones are approaching it, is not optional at any meaningful scale.

What to keep as evidence: a current export of every app registration's credentials, including type (secret or certificate), creation date, and expiry date, reviewed on a cadence tighter than the shortest expiry window in use.

Permission review

Microsoft Graph and other Entra-integrated APIs expose two categories of permission: delegated and application.

Delegated permissions act on behalf of a signed-in user. The application can only do what that user is themselves allowed to do, and every action is attributable to that user's session. If the user has no access to a resource, the delegated permission grants none either.

Application permissions act on behalf of the app itself, with no signed-in user involved at all. This is the model used by background services, scheduled jobs, and daemons, exactly the kind of unattended automation this article's companion piece on service principals is about. Application permissions are the higher-risk category precisely because there is no user context constraining them and no session to monitor. Once granted, an application permission is active every time that app registration authenticates, with the full scope of the permission, indefinitely, until someone revokes it.

A permission review should specifically look for a shortlist of Microsoft Graph application permissions that carry outsized risk if granted more broadly than necessary:

None of these are inherently wrong to grant. Some legitimate automation genuinely needs directory write access or tenant-wide mail access. The point of the review is to confirm that every app holding one of these permissions actually needs it for its stated purpose, and that the grant was a deliberate decision rather than an accident of over-broad scoping at build time.

Admin consent history is worth reviewing as its own audit trail. Every application permission grant requires admin consent, and Entra ID records who granted it and when. A permission grant with no clear business justification attached, or one granted by an account that no longer has administrative access, is a legitimate thing to flag and follow up on, the same way an unexplained privileged role assignment would be.

Ownerless and unverified apps

Every app registration should have a current, real human owner. Not a shared mailbox, not a departed employee whose account happens to still be enabled, and not nobody at all. The owner is the person who is supposed to know why the app exists, what it does, and whether it is still needed, and who should be the first point of contact when a credential is about to expire or a permission looks wrong on review.

Ownerless app registrations are a genuinely common finding, not a theoretical one. Apps get registered by a contractor who has since left, or by an employee whose account was deprovisioned without anyone reassigning ownership of what they built along the way. The result is an app with real permissions and nobody accountable for it, which is precisely the gap that lets a stale or over-permissioned app sit unnoticed for years.

Publisher verification is a separate, additional signal, and worth understanding precisely rather than assuming it means more than it does. A verified publisher badge means Microsoft has confirmed the organisation behind the app registration is a legitimate, verified entity through the Microsoft Partner Network, and that the app's identity information matches that verified organisation. It is an attestation about who published the app, not an assessment of what the app does, how well it was built, or how appropriately it uses the permissions it requests. An unverified publisher on an internally built app with narrow, well-understood permissions is often unremarkable. An unverified publisher on an app that has been granted broad application permissions, particularly one nobody in the organisation clearly remembers approving, is a legitimate finding worth raising, since it means the organisation behind that access has not been independently confirmed at all.

Redirect URI and multi-tenant misconfigurations

Redirect URIs tell Entra ID where it is allowed to send authentication tokens once a user has signed in. A redirect URI that is overly broad, using a wildcard, a shared domain with many subdomains under different control, or an HTTP (not HTTPS) endpoint, creates a real token-interception risk. If an attacker can stand up something at a URI pattern your app registration trusts, they can potentially receive tokens intended for your legitimate application. Every redirect URI on every app registration should be reviewed for exact specificity: a fixed, fully qualified, HTTPS endpoint that only the intended application controls, not a pattern broad enough to catch anything that happens to match.

Multi-tenant configuration deserves the same scrutiny. An app registration can be configured as single-tenant (usable only within the tenant that registered it) or multi-tenant (usable by users in any Entra tenant, or any Entra tenant plus personal Microsoft accounts, depending on the setting chosen). Multi-tenant is the correct choice for an application genuinely intended to be used across organisations, such as a SaaS product. It is frequently, however, left as the default or chosen out of caution for an internal tool that will only ever be used inside one organisation. Every multi-tenant setting that does not need to be multi-tenant widens the application's attack surface unnecessarily: it means users from other, uncontrolled Entra tenants could in principle attempt to authenticate against it, depending on other controls in place. Reviewing this setting against actual, intended usage, and tightening it to single-tenant wherever multi-tenant access was never actually required, closes off exposure that has no corresponding benefit.

The audit cadence problem

A quarterly manual review of app registrations is a reasonable-sounding control on paper, and it is already behind by the time it happens. A real, active Entra ID tenant does not add app registrations on a quarterly schedule. New integrations, new SaaS connectors, new internal tools, and new one-off automation scripts get registered continuously, sometimes several in a single week, each one requesting its own permissions and generating its own credentials with its own expiry clock. A review that runs four times a year is, on average, looking at a picture that is somewhere between one day and ninety days stale, and the app registrations most likely to be missed entirely are the ones created shortly after the last review closed.

The gap is not really about review frequency in isolation, it is about what a point-in-time review can and cannot catch. A quarterly check can tell you what your app registrations look like on the day you ran it. It cannot tell you that a secret expired six weeks ago and quietly broke an integration nobody noticed, that a new app registration picked up Directory.ReadWrite.All last month without anyone flagging it, or that an app's owner left the organisation the week after the last review closed. Continuous monitoring closes exactly this gap: instead of a snapshot taken four times a year, it is a running, current view of credential expiry, permission grants, ownership, and verification status, checked on the same cadence the rest of the identity estate should be checked on. The value is not "more frequent spreadsheets," it is evidence that stays accurate on the day someone actually needs to rely on it, whether that is an auditor, an incident responder, or a security lead trying to answer a straightforward question about what a given app can actually do.