What is a Service Principal?
A Service Principal is the local identity an application uses inside an Entra ID tenant. Learn what it represents, how it differs from a user identity, and how to secure it.
What is a Service Principal?
Definition
A Service Principal (SP) in Microsoft Entra ID is the local identity a registered application uses inside a specific tenant. It is the runtime instance of an App Registration — what actually signs in, holds permissions, and gets assigned roles in that tenant.
When you (or another tenant) consent to an App Registration, a Service Principal is created in that tenant. The Service Principal is what shows up under Enterprise Applications in the Entra ID admin center.
In simple terms:
App Registration is the app's blueprint; Service Principal is the app's identity card in your tenant.
Why Service Principals Matter
- They're how applications and automation authenticate to your tenant.
- They hold API permissions (delegated and application).
- They can be assigned Entra ID roles and Azure RBAC roles.
- They have their own credentials (or use federated identity / Managed Identity).
- They are non-human identities — outnumber users in many tenants 10:1.
- Unmanaged or over-permissioned SPs are one of the top cloud identity risks.
Three Types of Service Principal
1. Application
The most common type — created when an app from your tenant or a multi-tenant app is consented in your tenant.
2. Managed Identity
Azure-managed service principal for an Azure resource. No secrets to manage — Azure handles credentials.
3. Legacy
For older Microsoft services (Graph API legacy, etc.). Less common today.
App Registration vs Service Principal
| Aspect | App Registration | Service Principal |
|---|---|---|
| Lives in | Home tenant only | Each tenant where consented |
| Defines | App identity, secrets, permissions request | App's instance, role assignments, consented permissions |
| Where seen | App Registrations blade | Enterprise Applications blade |
| Number | One | One per consenting tenant |
For a multi-tenant SaaS app, there is one App Registration in the publisher's tenant and one Service Principal in every customer tenant.
What Service Principals Can Hold
- API permissions (consented).
- Entra ID role assignments (e.g., User Admin, Application Admin, even Global Admin).
- Azure RBAC roles at any scope (subscription, RG, resource).
- Credentials (for non-Managed-Identity SPs): client secrets, certificates, federated credentials.
- App roles assigned to users / groups for that app.
- Sign-in logs and audit events.
Common Service Principal Risks
- Service principals with Global Admin or equivalent permissions.
- Long-lived secrets (1–2 years).
- Stolen credentials from CI/CD logs, source control, config files.
- Application permissions that grant full mailbox / file / directory access.
- No ownership — orphaned SPs years after the original team left.
- No conditional access for SP sign-ins (workload identity CA).
- Consent phishing — malicious multi-tenant apps consented by users.
- Permission drift — initial scope grew over time.
Real-World Examples
1. Midnight Blizzard / OAuth Persistence
After initial password spray compromise, attackers created or co-opted OAuth applications and granted them mailbox-read permissions — providing persistent access even after credentials were reset.
2. CI/CD Secret Leak
A CI pipeline ran with a service principal that had Owner on a critical subscription. The SP secret leaked into build logs accessible to a wider team. Attacker used it for cryptomining and data theft.
3. Excessive Microsoft Graph Permissions
A reporting tool requested Directory.ReadWrite.All and Application.ReadWrite.All "for flexibility." Compromise of the SP would have allowed full directory takeover.
4. Stale Multi-Tenant Consent
A SaaS app consented in 2019 with Mail.ReadWrite.All is no longer used. The SP still exists with the permission. Vendor compromise = mass mailbox compromise.
Service Principal Best Practices
Credentials
- Use Managed Identities for Azure-hosted workloads.
- Use Workload Identity Federation for GitHub Actions, Kubernetes, GitLab — no secrets at all.
- Prefer certificates over client secrets when secrets are unavoidable.
- Short credential lifetimes (90–180 days).
- Automated rotation.
- Vault credentials (Key Vault, secret managers).
Permissions
- Least privilege — only the permissions needed.
- Audit application permissions quarterly.
- Watch for consent drift (new permissions added).
- Disable user consent to high-risk scopes.
Identity Management
- Assign owners to every SP — group ownership preferred.
- Tag SPs with purpose, environment, and risk.
- Quarterly review of SP inventory.
- Decommission unused SPs.
- Use Conditional Access for workload identities (with appropriate license) — restrict by IP, etc.
Detection
- Audit log alerts on credential additions and consent grants.
- Sign-in log monitoring for unusual SP behavior.
- Microsoft Defender for Cloud Apps OAuth risk detection.
Service Principal Security Checklist
- Inventory of all SPs with owners and purpose?
- Managed Identities used where possible?
- Workload Identity Federation for CI/CD?
- Credentials short-lived, rotated, vaulted?
- Application permissions minimized?
- User consent locked down for high-risk scopes?
- Quarterly SP review and decommission?
- Conditional Access for workload identities?
- Audit log + sign-in log monitoring on SPs?
- SPs with privileged roles treated as Tier 0?
How Forestall Helps
Forestall enumerates every Service Principal in your tenant:
- Inventory with type, owner, credentials, expiration.
- Effective permissions (Entra roles, app permissions, Azure RBAC).
- Path analysis from any SP → privileged data.
- Drift detection on permissions and credentials.
- Stale / orphaned SP identification.
Frequently Asked Questions
How many SPs do typical tenants have?
Hundreds to tens of thousands. Outnumber users in most enterprises.
What's the safest credential type?
Federated identity / Managed Identity (no credentials to manage). Then certificates. Then short-lived secrets.
Can SPs sign in interactively?
No — they're non-interactive identities authenticating with credentials.
Are SPs covered by Conditional Access?
Yes, with Workload Identities features (requires appropriate license). Configure carefully.
How do I find a stale SP?
Check sign-in logs and last-used credential timestamps. SPs with no sign-ins in 90+ days and no automation pointing at them are likely candidates.
Conclusion
Service Principals are the application identities running in your Entra ID tenant — and the most overlooked dimension of cloud identity security in many organizations. Inventory them, assign owners, rotate or eliminate credentials, minimize permissions, decommission what isn't used, and apply Conditional Access. Done well, the SP plane stops being the attacker's quietest persistence option and becomes a well-governed integration surface.
Inventory and de-risk your tenant's service principals.
Forestall maps service principals, their permissions, and the privileged data they can reach.