TL;DR: Service principals in Microsoft 365, Intune, Defender, and Entra ID can hold standing secrets, broad permissions, and directory roles without MFA or user-facing controls, creating a persistent attack path according to Senserva. That makes workload identity inventory, consent review, and credential expiry core IAM work, not optional hygiene.
At a glance
What this is: This is an analysis of why service principals in Entra ID become hidden tenant risk when they hold standing secrets, broad permissions, and roles without human-facing controls.
Why it matters: IAM and IGA teams need to treat workload identity inventory, consent governance, and credential expiry as core control paths because service principals can outlive the projects that created them.
Context
Service principals are the non-human identities that applications use to sign in to Entra ID. Unlike people, they do not trigger MFA or Conditional Access prompts, so their permissions can remain active long after the business need has faded.
The governance gap is not that these identities exist. It is that they often accumulate without owners, expiry, or regular review, which makes them easy to miss in environments where user identity controls get most of the attention.
In cloud tenants, that gap turns application access into a standing exposure surface. A service principal with broad consent, a long-lived secret, or a privileged directory role can act with far more reach than most human accounts.
Key questions
Q: What breaks when service principals have standing secrets and broad permissions?
A: They become durable, low-friction access paths that do not depend on a human user, so MFA, Conditional Access, and normal user review no longer constrain the identity. If the secret is reused or the app role is overbroad, a single compromise can translate into tenant-wide access and administrative reach.
Q: Why do service principals with privileged Graph access create higher tenant risk?
A: Because application permissions can act without a signed-in user, so a high-privilege app can read, write, or administer data at scale with no interactive checkpoint. That makes consent scope and directory-role assignment the real control points, not the presence of an application name in inventory.
Q: How do organisations know if service principal governance is working?
A: Service principal governance is working when every non-user identity has clear ownership, policy is versioned and tested, and downstream logging can distinguish service activity from end-user activity. If reviews cannot trace a permission back to a named service owner, the governance model is incomplete.
Q: When should organisations prioritise service principal cleanup over other IAM work?
A: When application identities hold directory roles, tenant-wide Graph permissions, or credentials with no expiry, they should move ahead of lower-impact access tasks. Those identities can outlive the project, bypass user-centric controls, and keep a breach path open long after the original owner has moved on.
Technical breakdown
Service principals, app registrations, and tenant-local identity
An app registration is the global definition of an application, while the service principal is the tenant-local identity that actually signs in and receives permissions. In Entra ID, scripts, daemons, SaaS integrations, and Graph automations all use this non-human identity model. The security issue is not authentication in the human sense, but the combination of standing credentials and delegated or application permissions that can persist without interactive review. Once the service principal is granted access, the operating model assumes the identity remains trustworthy until someone notices otherwise.
Practical implication: treat every service principal as a governed identity object, not just an application setting.
Why standing secrets and app roles create durable access
Service principals commonly authenticate with a client secret or certificate, then use application permissions that apply without a signed-in user. That means the identity can act independently of MFA, user presence, or conditional prompts. When a secret never expires, a certificate lasts for years, or multiple credentials remain active, the credential lifecycle becomes the control surface. Broad Graph scopes such as directory write, role management, or mail access can turn one forgotten app into an estate-wide access path.
Practical implication: prioritise credential expiry, permission scope, and role assignment as the three controls that change actual blast radius.
Why dormant workload identities are often the most dangerous
Dormant service principals are high-risk because they combine low visibility with retained privilege. They may have been created for a project, deployed once, and then left running even after the business owner has moved on. Since workload-identity sign-ins are not watched like human logons, stale access can survive for months without triggering routine review. Orphaned ownership makes that worse because nobody is accountable for the app's lifecycle, revocation, or retirement.
Practical implication: flag any service principal with no recent sign-ins and no owner as a priority review item.
Threat narrative
Attacker objective: The attacker aims to use a forgotten service principal to obtain durable, low-friction access to tenant resources and administrative functions.
- Entry begins when an attacker targets a service principal with a weak or exposed secret, broad consent, or an over-permissioned app role. The identity is attractive because it does not rely on a person being present to approve access.
- Credential access follows when the attacker obtains the secret or certificate and uses it to authenticate silently as the application identity. That bypasses human MFA and removes the usual user-facing tripwires.
- Escalation occurs when the service principal already holds directory roles or powerful Graph permissions such as write access or role management. From there, the attacker can expand control across mail, directory, or administrative functions.
- Impact is tenant-wide reach through persistent non-human access that survives user-password resets and often outlives the original project owner. The attacker objective is durable cloud control through a forgotten application identity.
Breaches seen in the wild
- Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
- Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Standing application identity is a governance problem, not an application detail. Service principals behave like permanent access objects unless lifecycle controls force them back into review. That shifts them squarely into IAM and IGA scope, because the risk is created by permission persistence, ownership drift, and missing expiry discipline. The practitioner conclusion is simple: if the identity can act after the project ends, governance has failed.
Privilege on a service principal is more dangerous than privilege on a user account because it bypasses the controls built for people. Human MFA, Conditional Access, and risk-based sign-in logic do not meaningfully constrain a non-human identity that authenticates with a secret or certificate. That means traditional user-centric assurance can create false confidence around workload access. The conclusion is that service principal governance must be measured separately from human access governance.
Orphaned ownership is the hidden failure mode that turns an app into permanent exposure. When no one owns rotation, consent review, or retirement, the identity stays alive by default even after the business purpose has disappeared. That is not a tooling issue so much as an accountability gap in the identity lifecycle. The conclusion is that ownership and offboarding are as important for service principals as they are for people, but with less visibility and more blast radius.
Service principal risk should be ranked by effective reach, not by inventory size alone. A tenant may have hundreds of apps, but only a few combine broad consent, privileged directory roles, and long-lived secrets. Those are the identities that matter operationally because they convert administrative convenience into attack surface. The conclusion is that security teams should prioritise the small set of app identities that can read, write, or administer the tenant.
Secret expiry is the named control boundary that separates temporary automation from persistent access debt. A secret that never expires turns automation into standing privilege with a different label. That is why credential lifecycle, not just access review, must sit at the center of NHI governance for Entra ID service principals. The conclusion is that expiry discipline is the difference between managed automation and forgotten access.
What this signals
Service principal debt is what happens when automation identities keep their access after the business justification disappears. For IAM teams, the practical shift is to govern ownership, consent, and expiry as lifecycle controls rather than as ad hoc cleanup tasks.
A tenant can look well controlled on the human side and still carry material exposure through dormant application identities. The control failure is not visibility alone, but the fact that user-centric monitoring often misses the workload identities that matter most.
Service principal governance is increasingly a workload identity problem, which means teams should align Entra ID review cycles with non-human credential lifecycle rather than annual access recertification alone.
For practitioners
- Inventory every service principal by effective privilege List application permissions, delegated grants, and directory roles together so the highest-risk identities are visible first, not buried by app name.
- Enforce secret and certificate expiry Flag never-expiring secrets, multi-year certificates, and multiple active credentials on the same app, then treat them as immediate review items.
- Review tenant-wide consent and role assignments Check for broad Microsoft Graph scopes, unexpected admin consent, and any service principal assigned privileged directory roles.
- Remove orphaned and dormant application identities Prioritise apps with no owner or no sign-ins in the last 90 days when they still retain permissions, because those identities are pure residual exposure.
- Separate workload identity monitoring from user sign-in review Pull workload-identity sign-in activity into the same governance process as human access so forgotten service principals do not escape normal dashboards.
Key takeaways
- Service principals are not secondary tenant objects. They are non-human identities with the ability to hold standing access, broad permissions, and privileged roles.
- The main evidence is structural rather than exceptional: no MFA, no Conditional Access prompt, dormant identities, and long-lived credentials make application accounts easier to miss than human accounts.
- The practical response is to govern service principals as first-class identities by tracking ownership, expiry, consent scope, and dormant access together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Orphaned apps and forgotten service principals are the article's core lifecycle failure. |
| NHI-05 — Overprivileged NHI | The article centers on app identities holding broader permissions than their use case requires. | |
| NHI-07 — Long-Lived Secrets | Never-expiring secrets and long certificate lifetimes are highlighted as the durable exposure path. | |
| Recommendation — Track service principal offboarding so unused application identities are revoked instead of left active. Review application permissions and remove tenant-wide scopes that are not strictly required. Set explicit expiry and rotation for service principal secrets and certificates. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle for non-human identities is directly in scope for this control. |
| Recommendation — Apply IA-5 to manage service principal secrets, certificates, and rotation discipline. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on service principal entitlement scope and role assignment. |
| Recommendation — Align entitlement reviews to PR.AA-05 for every service principal with tenant or directory access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen app credentials and overbroad permissions support the attack path described in the article. |
| Recommendation — Map exposed service principal credentials to Credential Access and privilege-bearing lateral movement paths. | ||
Key terms
- Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
- Application Permission: An application permission is an access grant that lets an app act without a signed-in user present. In practice, it can be far more powerful than delegated access because the permission persists independently of a human session and can be abused if the app is over-consented or orphaned.
- Standing Secret: A standing secret is a long-lived credential that remains valid until it is manually replaced or revoked. In practice, it expands attack exposure because the secret can outlive the service change process, especially when ownership and usage tracking are incomplete.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 8, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org