Service Principal

A service principal in Microsoft Entra ID is the instance of an application inside a specific tenant — its representation, with its own object ID, permissions, role assignments, and sign-in logs. Distinct from the application registration, which defines the app at its home tenant; the service principal is what shows up in your tenant as an enterprise application. Every multi-tenant SaaS app you've consented to creates a service principal in your tenant. Service principals can authenticate (via client secrets, certificates, or federated credentials), call Graph APIs, and be granted role-based access. As non-human identities, they're a significant attack surface — manage them via Microsoft Entra Workload ID and audit them like users.

One app registration, many service principals

The registration/service-principal split explains a behaviour that confuses a lot of admins the first time they see it: an ISV publishes one multi-tenant app registration in their own tenant, but every customer that consents to it gets a separate service principal created in their own tenant — same underlying app, one representation per tenant it's used in. That's why revoking access in one customer's tenant (deleting or disabling their service principal) has zero effect on any other customer using the same app, and why a single vendor app can look completely different across tenants once admins have scoped its permissions or assigned it to different groups locally.

Client secrets, certificates, and why secrets are the weaker choice

A service principal authenticates as itself using one of three credential types: a client secret (a shared string, the simplest to set up and the easiest to leak — in source control, in a config file, in a Slack message), a certificate (a public/private key pair, harder to accidentally leak because the private key never needs to be transmitted anywhere), or a federated credential (trust established with an external identity provider like a CI/CD pipeline, needing no stored secret at all). Client secrets also expire and get rotated manually, which is exactly the maintenance burden that causes "the integration broke because nobody renewed the secret before it expired" — a recurring, entirely avoidable outage.

Worked example

A finance team adopts a third-party reporting SaaS tool that needs read access to Microsoft 365 usage data via Graph API. Onboarding it creates a service principal in the tenant with application permissions like Reports.Read.All. Six months later, a security review runs a routine audit of enterprise applications and finds this service principal still holds those permissions, with a client secret that was never rotated and is set to expire "never." The reviewer tightens the grant to the minimum needed scope, replaces the client secret with a certificate, and sets a calendar reminder for certificate renewal — turning an unmanaged standing credential into one that's tracked like any other privileged access.

Common pitfalls

The most common failure is treating service principals as invisible infrastructure rather than as identities that need the same governance as user accounts — an over-permissioned service principal with a non-expiring secret is functionally a standing admin account nobody is watching. The second is granting application permissions (which act with no user in the loop, tenant-wide) when delegated permissions (scoped to a signed-in user) would have sufficed — always the more conservative default unless the workload genuinely runs unattended. The third is losing track of why a service principal exists at all once the person who set it up leaves — a periodic enterprise-application review, the same discipline used for access reviews on user accounts, is what catches these before they become an unexplained finding in an audit.