TL;DR: A low-privileged legacy service principal, over-permissive app roles, PIM group activation, and certificate-based authentication can be chained to reach Global Administrator access in Entra ID, bypassing passwords and MFA, according to Semperis research. The real failure is not one control, but the assumption that individually scoped permissions cannot combine into tenant-wide trust collapse.
At a glance
What this is: This is a Semperis scenario analysis showing how Entra ID misconfigurations can be chained from leaked service principal credentials to tenant-wide compromise through certificate-based authentication.
Why it matters: It matters because identity teams must treat app ownership, privileged role paths, and authentication policy changes as one control surface, not separate admin tasks.
Context
Entra ID misconfigurations become dangerous when individually limited permissions can be chained into a tenant-wide trust failure. In this scenario, the primary identity problem is not one bad setting but the way service principal ownership, app roles, and authentication policy administration interact.
Certificate-based authentication adds another layer of complexity because it can satisfy authentication requirements while bypassing the practical protections teams assume passwords and MFA provide. For identity governance, that means configuration drift in application identities can turn into account takeover without touching a human user’s credentials.
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 can app-only permissions create tenant takeover risk even without directory roles?
A: Because some app roles change the tenant trust model rather than directly managing users. Permissions that modify authentication policy, organization settings, or certificate trust can convert a limited application identity into a control plane actor. The risk is not just what data the app can read, but what identity decisions it can rewrite.
Q: What signs show certificate-based authentication is being misused in Entra ID?
A: Look for unexpected certificate authority uploads, authentication policy changes, new certificate bindings, and privileged sign-ins that do not match normal enrolment patterns. When CBA is enabled or altered outside standard change windows, it can indicate a trust boundary is being repurposed for impersonation rather than legitimate access.
Q: How should identity teams govern PIM when group activation changes authentication policy access?
A: Treat PIM eligibility as a control path into sensitive configuration, not just a temporary elevation for support work. If group activation can unlock authentication policy administration, then eligibility review, justification quality, and role separation must be governed like privileged production access, because the downstream effect can be tenant-wide trust change.
Technical breakdown
How service principal ownership becomes a privilege bridge
A service principal can own another service principal, and ownership can confer credential management rights even when no directory role is assigned. In this scenario, the attacker uses Application.ReadWrite.OwnedBy to manage only the owned application object, then adds a secret and pivots into a second identity with broader tenant impact. The mechanism matters because ownership is often treated as an administrative convenience, not as a delegated trust relationship with escalation value.
Practical implication: inventory ownership chains for application identities and treat them as potential escalation paths, not just metadata.
Why tenant-wide configuration permissions are more dangerous than they look
Organization.ReadWrite.All does not directly grant user or role administration, but it can still alter tenant-wide authentication settings. That distinction is exactly why these permissions are often underestimated. Once the attacker reaches a service principal with org-wide configuration capability, the path opens to changing authentication policy state rather than attacking accounts directly. The control failure is not raw privilege breadth alone, but the ability to modify identity trust settings through an identity that appears operationally scoped.
Practical implication: review app roles for indirect control over authentication policies and tenant trust configuration.
How certificate-based authentication can become a trust boundary bypass
Certificate-based authentication is only as trustworthy as the certificate authority and binding policy that back it. Here, the attacker enables CBA, uploads a rogue root certificate authority, and forges a client certificate for a privileged account. Because the tenant then accepts that certificate as a valid identity proof, the attacker can authenticate in a passwordless, MFA-compliant way. That is not a failure of certificates themselves, but of letting tenant trust expand to an attacker-controlled issuer.
Practical implication: govern certificate authorities, binding modes, and authentication method policy as high-risk trust infrastructure.
Threat narrative
Attacker objective: The attacker aims to obtain Global Administrator access to the Entra ID tenant and maintain durable privileged access through trusted certificate authentication.
- Entry occurs through leaked hardcoded client credentials for a legacy service principal found in an old PowerShell repository.
- Privilege escalation follows when the attacker uses ownership of one service principal to add a secret to another identity with broader permissions.
- Escalation continues as the attacker activates a PIM-eligible group, enables tenant-wide certificate-based authentication, and uploads a rogue root certificate authority.
- Impact is full Entra ID tenant takeover through forged certificate authentication as a privileged user, with passwordless access that persists until trust settings are remediated.
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.
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
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
Identity ownership is a privilege boundary, not an administrative detail. The article shows that one service principal can own another, and that ownership can expose credential management rights even when directory roles appear absent. That means governance models that track roles but ignore object ownership miss a real escalation channel. Practitioners need to treat ownership edges as part of the effective attack surface.
Tenant trust collapses when app-only permissions can rewrite authentication policy. Organization.ReadWrite.All looks narrow if teams think only in terms of user administration, but here it becomes a path to alter authentication settings at tenant scope. The broader lesson is that identity permissions must be evaluated by the trust state they can change, not by their label alone. That is a governance failure in permission interpretation, not just permission assignment.
Certificate-based authentication is a trust boundary, not merely an authentication method. Once a tenant accepts an attacker-uploaded root certificate authority, passwordless and MFA-compliant access can be forged inside the tenant’s own trust fabric. The named concept here is authentication policy trust expansion: when policy control over CBA turns an identity setting into an issuer trust decision. Practitioners should recognise that certificate governance now sits at the centre of tenant integrity.
Layered misconfigurations create trust-chain collapse. The key failure is not any single setting, but the assumption that scoped permissions, PIM activation, and authentication method controls remain safely separated. In practice, those controls combine into a path that converts legacy automation debt into tenant-wide impersonation capability. Identity programmes should map these chains end to end, because the exploit works at the seams.
Entra ID governance must move from permission review to trust-path review. This scenario shows why isolated control checks miss the real issue: a limited identity can become a trusted issuer, then a privileged user, then a persistent foothold. The practitioner conclusion is simple. Review how trust is created, delegated, and reissued across application identities, authentication policy, and certificate authorities.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Read next: Active Directory and Entra ID Hardening Guide
What this signals
Authentication policy trust expansion: This scenario shows that certificate-based authentication is not just another login method. When a tenant allows untrusted certificate authorities or weak binding governance, the authentication layer itself becomes a control plane for privilege escalation.
Identity teams should stop reviewing service principals only as workload accounts. Ownership relationships, delegated app roles, and PIM-backed admin paths now need to be analysed together because the attack chain succeeds by crossing those boundaries, not by breaking any one of them.
The most important operational shift is to treat tenant trust settings as high-value identity infrastructure. Once certificates can be introduced as trusted issuers, the question is no longer whether the account is privileged, but who can rewrite the rules that decide what the tenant trusts.
For practitioners
- Map service principal ownership chains Trace which application identities own other application identities and flag any ownership relationship that can alter credentials or secrets.
- Review app roles for tenant-wide trust impact Examine app-only permissions such as Organization.ReadWrite.All for the ability to change authentication policy, not just data access scope.
- Restrict certificate-based authentication administration Limit who can enable CBA, change binding mode, or upload certificate authorities, and treat those rights as tenant trust controls.
- Hunt for legacy automation secrets Search old repositories and scripts for hardcoded client credentials tied to service principals, then revoke and replace any exposed secret material.
- Reassess PIM group eligibility for authentication policy roles Audit whether temporary group activation can unlock authentication method administration and remove unnecessary eligibility from sensitive roles.
Key takeaways
- The breach pattern is a chained identity failure, not a single bad permission, and it turns application ownership plus authentication policy access into tenant takeover.
- The attack demonstrates that passwordless and MFA-compliant sign-in can still be malicious when a rogue certificate authority is trusted inside the tenant.
- The practical control gap is governance over ownership chains, certificate authorities, and tenant trust settings, because those are the points where limited access becomes full compromise.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded service principal credentials in a legacy repository are the entry point in this attack chain. |
| NHI-03 — Vulnerable Third-Party NHI | The owned service principal chain shows how one application identity can be abused to pivot into another. | |
| NHI-05 — Overprivileged NHI | Organization.ReadWrite.All and CBA administration rights enable tenant-wide trust changes beyond the app's apparent scope. | |
| Recommendation — Scan repositories and scripts for exposed machine secrets and revoke any leaked credentials immediately. Map service principal ownership and remove third-party or inherited trust paths that enable credential abuse. Review application permissions for tenant-wide trust effects and remove rights that exceed operational need. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The scenario depends on incorrect identity entitlements and authorization paths across apps and admin roles. |
| Recommendation — Review entitlements for application identities and privileged groups to ensure authorization paths match actual business need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The attack pivots on secrets, client certificates, and authentication method governance. |
| Recommendation — Enforce authenticator lifecycle controls for service principals and certificate-based sign-in material. | ||
| MITRE ATT&CK | TA0006;TA0004;TA0008 — Credential Access; Privilege Escalation; Lateral Movement | The attack uses credential theft, escalation through ownership, and movement across identity objects. |
| Recommendation — Map the sequence to credential access, privilege escalation, and lateral movement to prioritise detections. | ||
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.
- Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
- Authentication Policy Trust Expansion: The widening of trust when a policy setting allows additional issuers, binding modes, or authentication methods to satisfy sign-in. It becomes dangerous when configuration rights let an attacker turn the identity platform into a trust issuer for privileged access.
- PIM Activation Path: A just-in-time elevation route created when temporary group or role activation unlocks privileged configuration rights. For identity governance, the important issue is not only who is eligible, but what high-impact settings become available after activation.
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