Entra ID certificate bypass shows how misconfigurations enable tenant takeover

At a glance

What this is: This is an Entra ID attack-path analysis showing how misconfigured service principals, privileged app roles, and certificate-based authentication can be chained into full tenant takeover.

Why it matters: It matters because identity teams have to govern service principals, PIM, and authentication policy as one attack surface, not as isolated admin tasks.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Semperis' EntraGoat scenario on certificate bypass and Global Admin access

Context

Certificate-based authentication in Entra ID is only as safe as the trust chain behind it. When service principal ownership, application permissions, and authentication policy management are weakly governed, a low-privileged identity can become a path to tenant-wide compromise.

This scenario sits squarely in NHI governance because the abusing actor is a service principal, not a human user. The issue is not certificate authentication itself, but the combination of unmanaged credentials, excessive app permissions, and policy controls that can be reconfigured by a compromised identity.

Key questions

Q: What breaks when service principal ownership is not governed tightly?

A: Ownership can become a credential-management backdoor, not just an administrative label. If one service principal owns another, the first may be able to add secrets or alter the owned object in ways that create a pivot path. That makes ownership review as important as role review in NHI governance.

Q: Why do app permissions become dangerous when combined with PIM-eligible roles?

A: Because a limited app permission can become a route to tenant-wide change once a human activation step unlocks a privileged group. The risk is the combined control path, not the individual permission. IAM teams need to review those combinations as a single escalation chain.

Q: How do security teams know whether certificate-based authentication is over-trusted?

A: A tenant is over-trusting CBA when a small number of role holders can change binding modes, add trusted certificate authorities, or make certificate sign-in satisfy MFA requirements. Those are trust-anchor changes, so they should be monitored as privileged identity events, not routine configuration updates.

Q: Who is accountable when authentication policy changes enable tenant takeover?

A: Accountability sits with the teams that govern directory roles, authentication methods, and application ownership together. If those controls are split across separate reviews, no one sees the full escalation path. Frameworks such as Zero Trust and identity governance only work when policy mutation rights are explicitly owned.

Technical breakdown

How legacy service principal credentials become an initial foothold

The attack starts with hardcoded client credentials for an outdated automation service principal. Once those credentials are exposed, the service principal becomes a reusable non-human identity with whatever app permissions and ownership links it already carries. In Entra ID, that matters because application-level permissions are often treated as narrow when they are actually sufficient to manipulate other application objects. The crucial technical feature here is ownership-based delegation: if an app owns another service principal, it can manage that object without broader directory control. That turns old automation debt into a pivot point.

Practical implication: inventory service principal ownership chains and eliminate hardcoded credentials before they become a pivot into other app identities.

Why app roles and PIM can combine into tenant-wide policy control

The path from application permissions to tenant compromise runs through combinations, not single privileges. Application.ReadWrite.OwnedBy lets the caller modify owned app objects, while Organization.ReadWrite.All can alter tenant-wide configuration settings. Separately, neither looks like full admin control. Together, they create a route into authentication policy management, especially when a user is PIM-eligible for a group holding Authentication Policy Administrator rights. That is a classic governance failure in Entra ID: privilege appears compartmentalised, but the effective control plane is shared across app, group, and tenant policy objects.

Practical implication: evaluate permission combinations and PIM eligibility together, not as separate review exercises.

How certificate-based authentication can be abused as a trust issuer

Certificate-based authentication becomes dangerous when a tenant can be taught to trust a malicious root certificate authority. Once the attacker enables CBA and uploads a rogue root CA, the tenant accepts forged client certificates as valid identity assertions. If the binding mode is set to single-factor, that may still leave MFA controls intact for privileged access. But once the binding is changed to multi-factor, certificate sign-in can satisfy stronger authentication requirements as well. The technical weakness is not just login abuse. It is the ability to redefine the trust anchor inside the tenant.

Practical implication: protect authentication method configuration and root CA trust changes with the same rigor as privileged role assignment.

Threat narrative

Attacker objective: The attacker wants to convert low-privileged service principal access into trusted authentication for a Global Administrator account and then hold persistent control of the tenant.

1. Entry begins with leaked hardcoded client credentials for a legacy automation service principal stored in an old repository, giving the attacker a valid non-human identity foothold.
2. Escalation follows when the attacker uses owned-service-principal rights, app-role combinations, PIM activation, and authentication policy changes to become trusted inside the tenant.
3. Impact occurs when a rogue root certificate authority and forged certificate allow passwordless, MFA-compliant Global Administrator sign-in, resulting in full tenant takeover and persistence.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity policy assumed to be safe because it is modular was designed for isolated permissions. That assumption fails when a service principal can chain ownership, app roles, and policy rights into a single trust path. This scenario shows that Entra ID misconfigurations are dangerous not because any one control is absent, but because the control plane itself is composable. The implication is that identity governance has to model permission combinations, not just individual entitlements.

Certificate-based authentication is a trust boundary, not just an authentication option. When a tenant can accept a newly uploaded root CA, the issuer of identity assertions becomes part of the attack surface. That shifts the problem from sign-in assurance to trust-anchor governance, which is a much harder control boundary to monitor after the fact. Practitioners should treat CBA configuration as a privileged identity control, not an admin preference.

Service principal ownership creates a hidden privilege graph that most IAM programmes do not map well enough. Ownership is often treated as metadata, but in practice it can permit credential management and backdoor creation across linked app objects. This is a classic NHI governance blind spot because the exploit path is not visible in role reviews alone. The lesson is to govern ownership as a first-class privilege.

PIM eligibility does not remove risk when the activated role can reconfigure authentication policy. Time-bound elevation still becomes tenant takeover if the resulting role can alter binding modes or trust settings. That means access governance for Entra ID must join together standing app permissions, just-in-time human activation, and policy mutation rights in one review model. Separate reviews create false confidence.

Privilege chaining across app, policy, and trust objects is the real failure mode. This attack worked because each step looked bounded in isolation, but the combined path was unconstrained. Organisations should stop asking only whether a permission is admin-like and start asking whether it can help manufacture a trusted identity issuer. That is the governance question this scenario exposes.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why hidden ownership chains keep turning into escalation paths.
• If you are mapping the same exposure patterns in your environment, review 52 NHI Breaches Analysis for the control failures that most often turn identity debt into incident impact.

What this signals

Privilege chaining is now the key Entra ID governance problem. Teams are no longer dealing with isolated app permissions or isolated authentication settings. They are dealing with a control plane where ownership, PIM activation, and trust anchors can be combined into one escalation route, so review processes need to model the full path, not the parts.

Certificate trust should be treated as a privileged identity lifecycle event. If an organisation lets a small set of roles alter certificate-based authentication bindings or trusted root CAs, it has effectively delegated issuer control. That is a narrow control surface, but it has outsized blast radius, so it belongs in the same oversight stream as role assignment and key management.

The governance signal is clear: service principal visibility, ownership mapping, and authentication policy change control need to converge. Once privileged app roles and human PIM activation can influence the same trust boundary, separate control owners will keep missing the compound risk. Practitioners should expect more attacks that exploit policy composition rather than single-control failure.

For practitioners

• Map ownership chains across service principals Identify every service principal that owns another service principal and treat those links as privilege-bearing. Remove stale ownership, then review whether ownership also enables credential addition or policy-adjacent changes.
• Eliminate hardcoded client credentials from legacy automation Search repositories, scripts, and build artifacts for embedded secrets, then rotate and revoke any service principal credentials found there. Legacy automation should be migrated to managed identity or controlled secret storage.
• Review app-role combinations against tenant configuration rights Pair Application.ReadWrite.OwnedBy with Organization.ReadWrite.All and similar combinations to see whether a supposedly limited app can reach authentication settings or other tenant-wide controls.
• Restrict who can change authentication method policy Separate authentication policy administration from broad directory and application administration wherever possible. Changes to certificate-based authentication, binding modes, and trusted root CAs should require tightly scoped approval and logging.
• Audit PIM groups for indirect policy mutation power Check whether group-activated roles can change identity trust settings, not just user objects. If they can, treat the activation path as privileged configuration access and monitor it accordingly.

Key takeaways

• This attack path shows that Entra ID compromise can begin with a non-human identity and end in tenant-wide trust manipulation.
• The scale of the problem is visible in the way hardcoded credentials, ownership links, app roles, and CBA settings combine into one escalation chain.
• The control that matters most is not a single extra safeguard, but governance over privilege combinations, trust anchors, and authentication policy mutation rights.

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: An authentication method that uses client certificates instead of passwords to prove identity. In enterprise identity systems, it becomes sensitive when the tenant can trust new certificate authorities or binding modes can be altered by privileged roles, because trust configuration then becomes part of the attack surface.
• Privileged Identity Management: A governance control that activates elevated access only when needed and for a limited period. It reduces standing privilege, but it does not eliminate risk if the activated role can change identity policy, authentication settings, or trust anchors inside the directory.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: EntraGoat Scenario 6, Certificate Bypass Authority - Root Access Granted. Read the original.