TL;DR: A compromised low-privilege user can pivot through owned service principal access, add a client secret, and use app-only authentication to reset a Global Administrator account, bypassing user-centric controls like MFA and Conditional Access, according to Semperis. The lesson is that application ownership is itself a privileged control surface, and unmanaged service principals can collapse the boundary between delegated and app-only access.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Semperis's blog post: Service principal ownership can be abused to pivot from a low-privilege user into Global Administrator compromise in Entra ID.
Why it matters: IAM and PAM teams need to treat application ownership, role assignment, and app-only authentication as governed access paths, not just admin conveniences.
Context
A service principal is the tenant-local security identity for an application in Microsoft Entra ID. When ownership of that identity is left with an unprivileged user, the owner can often manage credentials and influence the app’s effective access, which turns ownership into a privilege boundary rather than a simple administrative label.
This article uses a deliberately vulnerable EntraGoat scenario to show a realistic escalation chain, starting with a compromised user and ending with tenant takeover. The primary governance problem is not the application itself, but the assumption that delegated user controls remain sufficient once app-only authentication is available.
For identity teams, the core lesson is that application ownership must be governed as part of the broader NHI and Entra ID lifecycle, especially where enterprise apps hold directory roles or can be used to bypass user-centric security controls.
Key questions
Q: What breaks when a user can own a privileged service principal?
A: A user who owns a privileged service principal can often change credentials, pivot into app-only authentication, and exercise the application’s assigned role without using the user account directly. That turns ownership into an indirect privilege-escalation path. The control failure is not just excess permission, but lack of governance over who may influence the application identity.
Q: Why do MFA and Conditional Access not stop this attack path?
A: Those controls govern human interactive sessions, not every app-only authentication flow. Once an attacker can authenticate as the service principal itself, the app’s permissions and assigned roles govern access instead of the user’s session policies. That is why human-centric enforcement can be bypassed when application credentials are introduced.
Q: What are the signs that service principal ownership is being misused?
A: Watch for non-admin users owning apps with directory roles, new client secrets added to enterprise applications, and a sudden switch from delegated user activity to app-only authentication. Those signals indicate that a user has moved from ordinary access into the application’s security context, which is where privilege escalation begins.
Q: Should organisations treat service principal ownership as privileged access?
A: Yes. If an owner can change credentials or influence a role-bearing application, ownership is a privileged capability and should be governed accordingly. Recertify it, limit who can hold it, and align it with the app’s effective blast radius rather than with application convenience.
Technical breakdown
How service principal ownership becomes an escalation path
In Entra ID, an application registration defines the app, but the service principal is the security object enforced in the tenant. Owners of the service principal can often add credentials, change configuration, and alter how the app authenticates. That matters because the service principal, not the user, becomes the actor once client credentials are added. If that identity is granted a role such as Privileged Authentication Administrator, ownership effectively becomes a path into directory control. This is why app ownership is not a cosmetic metadata field. It is an access-bearing control surface that can turn ordinary users into administrative pivots when governance is weak.
Practical implication: treat service principal ownership as privileged access and review who can own, edit, and credentialise enterprise apps.
Delegated access versus app-only authentication
Delegated authentication represents a user and inherits that user’s policy context, including MFA and Conditional Access. App-only authentication represents the application identity itself and is evaluated through its own permissions and roles. That distinction changes the enforcement model completely. A user who cannot satisfy an admin control path may still abuse an application they own if they can mint a secret or certificate and switch into app-only access. The danger is not just broader privilege, but a different trust boundary. Many identity controls are designed for humans and do not travel cleanly into machine-authenticated contexts.
Practical implication: separate human-session controls from app-only governance and verify which controls actually apply to non-human identities.
Why privileged roles amplify ownership mistakes
A misowned service principal is dangerous on its own, but the impact becomes severe when the app holds a directory role. In this scenario, the role allowed authentication-management actions that could reset a password or assign a Temporary Access Pass, which then enabled interactive compromise of the Global Administrator account. The key technical issue is that the app’s effective privilege is determined by both ownership and assigned role scope. Once those combine, the attacker no longer needs to remain inside the original compromised user context. The service principal becomes the bridge from low privilege to tenant control.
Practical implication: inventory app role assignments and prioritise every service principal that can influence authentication, account recovery, or directory-wide control.
Threat narrative
Attacker objective: The attacker’s objective is to convert low-privilege user access into full Entra ID tenant control through a service principal with privileged role access.
- Entry occurred through a compromised low-privilege user account, giving the attacker an initial Entra ID session.
- The attacker enumerated owned enterprise applications and found a service principal with elevated directory role assignment.
- The attacker added a client secret, authenticated as the application, and used the app-only context to perform privileged account actions.
- The attacker reset the Global Administrator credentials and used a Temporary Access Pass to complete interactive tenant takeover.
Breaches seen in the wild
- Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).
- 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.
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
Application ownership has become a privileged control surface. Ownership over a service principal is not administrative housekeeping when the app can mint its own credentials and inherit tenant roles. The governance model breaks when ownership is assigned without role sensitivity, because the owner can effectively steer the application’s security identity. Practitioners need to treat app ownership as part of privileged access governance, not just application administration.
The boundary between delegated and app-only access is where user-centric security assumptions fail. MFA and Conditional Access protect human sessions, but they do not control an application that authenticates with its own secret or certificate. That means a control stack designed around interactive users can be bypassed once the attacker moves into the app identity. The implication is that identity governance must explicitly separate user-session enforcement from non-human authentication paths.
Misowned enterprise apps create identity blast radius that is larger than most access reviews assume. Access reviews often ask who has access, but here the question is who can transform an ordinary app into a privileged actor. That is a different governance problem, because the risk comes from credential creation plus role inheritance, not from static membership alone. The field needs a stronger model for application ownership recertification that focuses on effective power, not just assigned labels.
Owned service principals with authentication-management roles should be treated as a latent tenant-takeover condition. The scenario shows that a single compromised user can become an app operator, then a directory administrator, then a full tenant attacker. This is the classic failure mode of excessive trust in decentralized app ownership. The practical conclusion is that role-bearing service principals require the same scrutiny traditionally applied to highly privileged human admins.
Ephemeral app trust debt is the right concept for this class of risk. Once an owned application can accumulate secret-based access and retain elevated permissions, governance debt compounds across both ownership and role assignment. The article demonstrates that the dangerous part is not only the secret, but the persistence of an app identity that can be repurposed without strong lifecycle control. Practitioners should read this as a lifecycle and privilege design problem, not a one-off misconfiguration.
What this signals
Application ownership needs the same governance mindset as privileged account stewardship. The scenario shows that a low-privilege user can become the operator of a role-bearing identity if ownership is not recertified with the app’s effective access in view. For IAM and IGA teams, that means the meaningful question is not who created the app, but who can turn it into an administrative path.
Delegated and app-only access now need separate policy treatment. Many programmes still assume that if human access is controlled, the surrounding application context is safe by extension. This article shows the opposite. Once an app can authenticate on its own, the control point shifts from the user’s session to the service principal lifecycle, which requires a different governance model.
Service principal ownership is a lifecycle issue, not a one-time configuration check. If ownership changes, role assignments change, or credentials are added without review, the app’s trust profile changes too. That is why application ownership should be included in joiner-mover-leaver and recertification workflows for the identities that actually execute access.
For practitioners
- Review service principal ownership for privilege-bearing apps Identify every enterprise application owned by non-admin users and flag any app with directory roles, authentication management rights, or tenant-wide operational scope.
- Separate app ownership from credential control Restrict who can add secrets or certificates to service principals, and ensure those rights are not implied by routine application ownership.
- Recertify role-bearing applications as privileged assets Put enterprise apps with authentication or directory roles into the same review cycle as privileged accounts, with explicit sign-off on continued ownership and purpose.
- Detect app-only pivots from low-privilege users Alert when a user session is followed by new client secrets, app-only authentication, or unusual role activity on a service principal the user owns.
- Remove dormant enterprise apps and orphaned ownership paths Decommission unused applications and verify that no non-admin owner can still introduce credentials into a service principal that remains role assigned.
Key takeaways
- Service principal ownership can be a privilege escalation path when the owner can add credentials and control an app with sensitive roles.
- The attack works because app-only authentication follows a different trust model than delegated user sessions, so MFA and Conditional Access do not cover the pivot.
- Governance should focus on who can transform an application identity into a high-impact security actor, not only on who can use the app.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The service principal becomes an overprivileged identity once ownership and directory role combine. |
| NHI-10 — Human Use of NHI | A human owner uses the service principal as a vehicle for app-only abuse. | |
| Recommendation — Review and reduce privilege on owned service principals before they can be used as escalation pivots. Block users from turning owned non-human identities into proxies for administrative action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The attack depends on adding and using client credentials on the service principal. |
| AC-6 — Least Privilege | The escalation works because ownership and role scope exceed what least privilege would allow. | |
| Recommendation — Apply authenticator management controls to limit who can add or reuse NHI credentials. Constrain ownership and role assignment so non-admin users cannot influence privileged app identities. | ||
| MITRE ATT&CK | TA0006;TA0004;TA0008 — Credential Access; Privilege Escalation; Lateral Movement | The scenario moves from credential abuse into privilege escalation and tenant-wide pivoting. |
| Recommendation — Map the ownership-to-app-only chain to ATT&CK and hunt for credential addition plus privilege jumps. | ||
Key terms
- Service principal ownership: The permission relationship that lets one identity manage another application object. In Entra ID, ownership can quietly create a privilege path because it may allow credential changes or other administrative actions on the owned object, even when the caller lacks broad directory rights.
- App-only Authentication: App-only authentication is access performed by the application’s own identity rather than a human user. It typically uses secrets or certificates, and it can operate outside the user controls that normally shape interactive sessions, which makes governance and monitoring essential.
- Delegated Authentication: Delegated authentication is the practice of outsourcing sign-in, session creation, and related credential handling to an external identity service. The application still enforces access, but the trusted identity workflow lives outside the codebase, which changes where security reviews, logging, and revocation need to focus.
- Temporary Access Pass: A Temporary Access Pass is a short-lived credential used to let a new user sign in once and enroll a stronger authenticator. In practice, it is an enrollment bridge, not a standing password. Its security value depends on tight expiry, limited use, and removal from the user journey after registration.
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 June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org