Service principals and managed identities solve a real problem in cloud security. Applications and workloads need a way to authenticate without relying on human credentials. That’s the whole point of them.
But removing the password doesn’t remove the privilege.
As cloud environments grow, non-human identities sit behind more and more things. Applications, virtual machines, automation workflows, APIs, hybrid infrastructure, management services — the list keeps growing. Each identity can look appropriately scoped when you review it on its own. The trouble starts when another user, application, resource, or admin function can control that identity indirectly.
A low-privileged foothold can become a high-privileged cloud path. That happens whenever a compromised resource can act on a more powerful identity’s behalf. It might execute as that identity, modify it, impersonate it, or grab its tokens.
That gap between visible privilege and effective privilege matters. It’s exactly where service principals and managed identities start to matter in offensive security.
Executive TL;DR
Here’s the short version, before we get into how these paths actually form:
- Service principals and managed identities are essential to cloud environments. But they create privilege paths that access reviews often miss.
- The real question isn’t only what permissions an identity has. It’s also who or what can control that identity.
- Microsoft explicitly warns that certain application administrators can add credentials to an application and impersonate it. That can mean reaching privileges beyond what was granted to the administrator’s own account.
- Cloud management capabilities can turn control-plane privilege into operating-system execution. Mandiant has observed attackers abusing Azure Run Command in real intrusions.
- MITRE ATT&CK tracks this behaviour as Cloud Administration Command (T1651).
- Azure Arc research shows how compromising a machine-level component can extend into that machine’s Azure identity. From there, it can reach that identity’s RBAC permissions.
- Effective security means mapping identity relationships and reachable privilege. It’s not enough to review administrators, role assignments, and workload identities in isolation.
Non-Human Identities Are Now Part of the Privilege Model
Modern cloud environments can’t run entirely on human user accounts. Applications need to authenticate to APIs. Automation needs to reach infrastructure. Virtual machines need to talk to storage, databases, Key Vaults, management services, and everything else.
Microsoft Entra Workload ID exists to manage and secure the identities used by digital workloads like applications and services. Service principals and managed identities both fall under this umbrella.
The model itself is sound. Instead of embedding a user’s username and password into an application, the application gets its own identity. Managed identities take it further, cutting down the need for developers to manage credentials by hand.
The Privilege Doesn’t Stay Put
The security problem isn’t that these mechanisms exist. It’s that an identity’s privilege doesn’t necessarily belong only to that identity.
Another principal might be able to modify the application or add credentials to it. They might execute code inside the workload, control the infrastructure hosting it, or trigger a management capability under its authority. Any of those gives an indirect path to the workload identity’s permissions. A permissions review that only looks at the final identity can miss the path entirely.
Visible Privilege Is Not the Same as Effective Privilege
Picture an administrator whose assigned Entra role looks limited to application management. On paper, it looks far less powerful than Global Administrator or another highly privileged directory role. But that doesn’t necessarily describe what the administrator can actually do.
Microsoft warns that Application Administrators and Cloud Application Administrators can add credentials to applications. They can then use those credentials to impersonate the application’s identity. Microsoft even notes that the application itself may hold permissions that amount to an elevation over the administrator’s own account.
That creates an important distinction. Assigned privilege is what the administrator can do directly. Reachable privilege is what the administrator can ultimately do through identities or resources they control.
Say an administrator can’t directly modify a sensitive directory object. They can, however, manage an application that holds powerful Microsoft Graph permissions. The role alone doesn’t tell the full story. The real path looks like this: administrator, to application control, to application credentials, to service principal, to downstream permissions.
Every individual permission in that chain may have been granted legitimately. The escalation lives in the relationship between them, not in any single grant.
An Old Problem in a New Place
This resembles the problem of shadow administrators in Active Directory. Accounts don’t always need an obvious administrator label to have administrator-equivalent power. In cloud environments, service principals, application-management rights, and workload control create similar gaps between visible and effective privilege.
That’s why identity reviews built mainly on role names and direct assignments tend to underestimate exposure. The question isn’t simply who is privileged. It’s who can reach privilege.
Managed Identities Shift the Credential Problem
Managed identities fix a real operational weakness. Applications no longer need developers to embed and rotate static credentials the old way.
But the identity still has permissions. And something still controls the workload using it.
From an offensive perspective, that changes the target rather than removing it. An attacker may not even need to steal a long-lived secret. They just need to compromise a resource capable of obtaining and using access tokens for the identity.
This fits a broader shift in modern credential theft. Attackers increasingly go after tokens, sessions, application credentials, and identity artifacts. Usernames and passwords alone are no longer the main target.
The Boundary Moves Into the Workload
For managed identities specifically, the security boundary extends beyond Entra ID and into the workload itself. A virtual machine, application service, automation platform, hybrid-management agent, or other Azure resource can join the identity attack surface. That happens whenever controlling that resource gives access to a more privileged identity context.
This is also why token theft can undermine otherwise trusted sessions. Authentication may have happened correctly the whole time. The attack just targets the authority that comes after it.
The question worth asking is simple: what can an attacker get once they’ve compromised the workload?
A Local Foothold Can Become a Cloud Identity
Recent research into Azure Arc shows exactly how this plays out. In 2026, Cymulate Research Labs disclosed CVE-2026-26117, an Azure Arc vulnerability chain involving local privilege escalation and cloud identity takeover.
According to the researchers, a low-privileged local user could manipulate communications between Azure Arc components. That let them escalate privileges to NT AUTHORITY\SYSTEM. From there, they could take control of the machine’s Azure identity. Where that identity held Azure RBAC permissions, the compromise could reach cloud resources accessible through those permissions.
The significance goes beyond one vulnerability. It shows how local access, the management agent, the machine identity, and Azure RBAC connect to each other. That relationship can turn a host-level problem into a cloud privilege path.
The Same Trust Boundary Keeps Coming Up
This isn’t a new pattern. NIST’s National Vulnerability Database records CVE-2025-47989, an improper-access-control vulnerability in earlier versions of the Azure Connected Machine Agent. It could let an authorised local attacker elevate privileges.
These are different vulnerabilities. But they point to the same strategic issue. Hybrid management infrastructure creates a relationship between local systems and cloud authority. It’s the same kind of trust chain we’ve covered in broader hybrid identity attacks against Active Directory and the cloud. Compromising one side of that relationship can affect the other.
None of this means managed identities are inherently unsafe. It means their security depends partly on the security of everything capable of exercising their authority.
When the Control Plane Becomes the Execution Plane
Identity risk gets more serious once cloud permissions start granting administrative control over downstream infrastructure. Azure Run Command is a good example.
The feature lets administrators execute scripts on Azure virtual machines through the Azure management plane. That’s legitimate, useful administrative functionality. It’s also useful to an attacker who gets hold of the right cloud permissions.
Mandiant documented intrusion activity where threat actors used Azure Run Command. It let them move from compromised cloud management environments into the underlying virtual machines. The researchers saw it used for reconnaissance, code execution, and credential harvesting.
MITRE ATT&CK formalises this as T1651: Cloud Administration Command. It describes how adversaries abuse cloud-management services like Azure Run Command and Runbooks to execute commands inside virtual machines.
Trusted Tools, Untrusted Hands
This is a cloud variation of a familiar offensive-security problem. Attackers don’t always need custom malware or an exotic exploit. Sometimes legitimate administrative functionality can be repurposed for malicious activity instead. The capability itself is trusted. The problem is who can invoke it, what it can reach, and what happens after it runs.
This matters because cloud privilege and endpoint privilege are often reviewed by separate teams. A role may look like it only grants infrastructure-management permissions. Operationally, though, those permissions can translate directly into code execution inside the managed system.
The effective attack path looks like this: cloud identity, to management permission, to Run Command, to privileged guest execution. An organisation can have well-hardened endpoint authentication and still expose an alternative execution path through the cloud control plane. The control can work exactly as designed. The surrounding trust relationship can still hand an attacker a usable path.
Legitimate Cloud Workflows Can Also Create Detection Gaps
Cloud-native attack paths don’t stop at virtual machines. DevOps platforms, automation services, deployment pipelines, and other control-plane systems can connect identities to infrastructure with real downstream authority.
Research presented at Black Hat Europe made this point in Azure DevOps. The paper is titled Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules. It walks through reconnaissance, privilege escalation, persistence, and defence evasion inside Azure DevOps Services. Some of the techniques even bypass default Microsoft Sentinel analytic rules.
The strategic point goes well beyond Azure DevOps, though. Trusted cloud services can modify infrastructure, trigger deployments, run automation, or interact with privileged identities. When they do, security teams need more than a login record. They need to know what trusted service acted next.
A legitimate workload performing a legitimate operation can still be carrying out an attacker’s intent. That’s what makes this hard to monitor. Malicious activity can hide inside normal APIs and administrative workflows, rather than showing up as obviously malicious tooling.
The Identity You Can See May Not Be the Only Identity Acting
Visibility is its own challenge here. Security teams typically focus on the service principals and managed identities created inside their own tenant. Those can be inventoried, assigned owners, given RBAC roles, and reviewed on a normal cadence.
But cloud platforms also need identities of their own to act on behalf of customers. In 2026, Vectra researcher Kat Traxler documented a class of Azure-managed identities. She called them “Platform-Level Managed Identities” — her own term, not an official Microsoft classification.
Identities You Don’t Own but Still Grant Access To
The research describes Azure backend services operating through identities managed by Microsoft, rather than the customer. Customers may grant these identities RBAC access to resources. Even so, the identity itself sits outside the customer’s normal management boundary.
That creates a different kind of threat-modelling problem. The organisation controls the permission assignment, but it doesn’t necessarily control the identity lifecycle behind it. None of this means such identities are a vulnerability by default. It does mean cloud threat modelling must account for actors and trust relationships that a normal inventory might miss. That’s the kind of inventory usually built only for conventional human and workload identities.
For security teams, the terminology matters less than the principle underneath it. Cloud authorisation can involve principals that sit outside the boundaries where identity governance teams usually look.
Metadata and Internal Services Extend the Identity Attack Surface
Managed identity risk also overlaps with application-security weaknesses, and Server-Side Request Forgery (SSRF) is a clear example.
In 2023, Orca Security disclosed SSRF vulnerabilities affecting four Azure services. Those were Azure Digital Twins, Azure Functions, Azure API Management, and Azure Machine Learning. Some of these could be exploited without authentication, and the researchers demonstrated access to internal endpoints and services.
The interesting detail here is what didn’t happen. Orca tried to reach Azure Instance Metadata Service endpoints. But they reported that Microsoft’s mitigations stopped them in these particular cases. That distinction matters — this research shouldn’t be read as proof those vulnerabilities exposed managed identity tokens. What it does show is why internal metadata and identity endpoints get treated as sensitive attack surfaces in cloud environments.
A vulnerability that looks purely application-layer can become far more serious in the wrong context. That happens when the vulnerable workload sits near privileged internal services or identity mechanisms. The path security teams should think through is broader than the bug itself. It runs from application compromise, to workload context, to internal services, to identity authority, to downstream access. Not every vulnerability will complete that chain — offensive testing is how you find out which ones can.
Why Mature Security Programmes Still Miss These Paths
Most mature environments already have controls for privileged access in place. They review administrator roles, implement least privilege, and monitor privileged accounts. They run vulnerability-management programmes and deploy endpoint protection and cloud-security tooling.
And yet service-principal and managed-identity attack paths can still slip past all of it. Here’s why.
Identity Inventories Show Objects, Not Relationships
An inventory might correctly list every service principal in the tenant. What it won’t reveal is who can add credentials to it, or who owns or can modify the underlying application. It also won’t show which workload can execute as it, or what resources that workload touches. Nor will it show what Azure RBAC and Microsoft Graph permissions it holds. And it won’t tell you whether another identity can change its configuration, or what downstream systems trust it.
The object sits in the inventory. The attack path sits between the objects — and inventories don’t draw that line for you.
Permission Names Can Understate Operational Impact
A role called Contributor sounds less sensitive than Administrator. But the real impact depends on what the principal can contribute to. If the role permits modifying a workload that executes as a stronger managed identity, that’s a problem. The effective privilege can exceed what the role name suggests.
If a cloud role enables remote execution against a production VM, infrastructure-management privilege can quietly become operating-system execution. Names are a starting point, not a verdict. Security teams need to evaluate capabilities, not labels.
Workload Identities Can Outlive Their Original Purpose
Applications get replaced. Automation changes. Projects wrap up. Teams move on. The identity, though, can stick around.
Ownership, purpose, credentials, and required permissions need regular reassessment. Without it, an identity built for a legitimate purpose can quietly become an overlooked privilege holder. This is part of what fuels attacker persistence after the original point of compromise has been remediated. Removing the initial access route doesn’t automatically remove the credentials, identities, trust relationships, or alternative paths built up around it. A forgotten service principal or an unnecessary application credential can be more than technical debt. It can preserve access long after the door you thought you closed.
Different Teams Own Different Parts of the Chain
Identity teams manage Entra ID. Cloud teams manage Azure resources. Developers manage applications. Infrastructure teams manage virtual machines. SOC teams monitor activity. Security architecture sets policy.
An attacker doesn’t respect any of those boundaries. A path that crosses three administrative domains can look low-risk to each individual team. Viewed end to end, though, it can turn out to be highly privileged.
That fragmentation is one reason configuration compliance can’t be the only measure of cloud identity security. The same lesson shows up in day-to-day Microsoft 365 red teaming. Misconfigurations there rarely stay inside one team’s part of the tenant. CISA’s Microsoft Entra ID Secure Configuration Baseline is a genuinely useful baseline for privileged roles, administrative controls, and identity configuration. But no baseline can account for every organisation-specific combination of applications, workloads, administrators, machine identities, and downstream permissions. An attacker might still chain them together.
What Offensive Security Should Validate
The goal shouldn’t just be finding the most privileged service principals — that’s inventory work. An offensive assessment should determine whether an attacker could actually reach and use that privilege.
Map Control Relationships, Not Only Role Assignments
For each sensitive service principal or managed identity, figure out what can control it, directly or indirectly. That means users, applications, groups, resources, and administrative roles. Ask who can modify the identity, and who can obtain or create credentials for it. Ask which resources can execute as it, who can modify those resources, and what the identity itself controls. The output should be an attack-path view, not another identity list.
Compare Visible Privilege With Reachable Privilege
Don’t treat a low-privileged principal as low risk just because its direct permissions look limited. Test whether it can modify an application, automation workflow, function, VM, deployment process, or management service. What matters is whether that resource operates through a more privileged identity. Assigned access alone isn’t the point. It’s the maximum privilege reachable through the trust chain.
Assess Workload Compromise as an Identity Event
When a workload uses a managed identity, compromising that workload can carry cloud-authorisation implications. Testing should check whether code execution inside the workload opens access to identity-backed resources beyond the workload’s own environment. This is exactly where cloud testing and application testing need to intersect.
Review Cloud-Management Execution Paths
Identify which principals can use Run Command, automation services, extensions, deployment systems, and other remote-management capabilities. Then validate whether those permissions open an unexpected route from cloud access to privileged execution on the underlying systems.
Detection deserves the same scrutiny. MITRE recommends monitoring cloud administrative commands and correlating control-plane activity with execution inside workloads. An assessment should find out whether the organisation can spot the API call. More importantly, can it spot the attacker behaviour that follows?
Test Hybrid Boundaries
Azure Arc and similar hybrid-management technologies connect systems outside Azure to the Azure control plane. That connectivity creates real value, and real trust. Assessments should determine whether a compromise on either side of that relationship can affect the other. This matters especially where machine identities carry meaningful RBAC permissions.
What Security Leaders Should Change
None of this requires eliminating service principals or managed identities. It requires treating them as first-class privileged identities, not background infrastructure.
Build an Ownership Model
Every workload identity should have a documented owner, a defined purpose, and known dependencies. It also needs expected permissions, an expected lifetime, and a review process behind it. An identity without a current owner should be treated as a governance problem, full stop.
Review Privilege From Both Directions
Traditional access reviews ask what an identity can access. Add the inverse question: who can control this identity? Both matter. This is the difference between inventorying permissions and actually understanding attack paths.
Prioritise Effective Privilege
Map application ownership, credential-management rights, workload-control permissions, Azure RBAC, API permissions, and management capabilities together. The highest-risk principal may not be the one with the strongest role. It may just be the one that offers the shortest path to it.
Reduce Standing Administrative Capability
High-impact management permissions should go to the smallest practical population. They should activate only when needed, wherever just-in-time controls exist. This matters most for permissions capable of turning cloud administration into remote execution.
Monitor Non-Human Identities as Identities
Service-principal and managed-identity activity shouldn’t fade into background automation noise. Security teams need behavioral baselines for expected workloads, resources, API access, and administrative actions, so unusual activity actually stands out. A service principal performing an administrative action it’s never done before deserves scrutiny. It shouldn’t get a pass just because no human logged in.
Validate the Entire Path
Finally, test the assumptions. A configuration may comply with policy. A permission may be legitimately assigned. An application may genuinely need its access. A managed identity may be functioning exactly as designed. None of those facts, on their own, prove the resulting trust chain is actually secure.
The Real Question Is Who Can Become Whom
Service principals and managed identities aren’t edge cases in modern cloud security anymore. They’re part of the operating model.
As organisations automate more infrastructure and connect more services, applications, DevOps workflows, and hybrid systems, non-human identities gain real authority. That authority used to belong mainly to administrators. This changes how privilege should be assessed.
The security question is no longer simply who has privileged access. It’s who can control something that has privileged access. And after that: what can that privilege reach next?
Those paths can cross application ownership, workload execution, Azure RBAC, cloud-management capabilities, metadata services, deployment systems, and hybrid infrastructure. And they can do it without any single control failing outright. That’s exactly why offensive validation matters. A permissions review can show what should happen. An offensive assessment tests what an attacker can actually make happen.
At wizlynx group, penetration testing, red teaming, and adversary simulation examine these relationships from an attacker’s perspective. The goal is testing whether legitimate permissions and trusted systems combine into paths that isolated control reviews may not reveal.
Because in a modern cloud environment, the most important privileged identity may not be the one labelled administrator. It may be the identity an attacker can reach from somewhere nobody thought to consider privileged.
Frequently Asked Questions (FAQs)
Why should leadership care about non-human identities when they’re not user-facing?
Non-human identities now hold real privilege inside the cloud. They can access data, execute code, and reach infrastructure just like a human account can. Leadership already treats privileged human accounts as a governance priority. Service principals and managed identities deserve the same attention. They’re often exempt from that scrutiny simply because no person logs in with them.
What’s the actual business risk if service principals and managed identities go unmanaged?
The risk is a privilege path nobody mapped. An attacker who compromises one low-privileged resource can potentially reach a far more powerful identity behind it. That can mean unauthorised access to sensitive data, production systems, or customer environments. The business impact looks the same as any other breach: downtime, data loss, regulatory exposure, and reputational damage. The path there is just harder to see.
How do we know if this applies to our organisation?
If your organisation uses Azure, Entra ID, or any cloud platform with automated workloads, it applies. Most environments already have dozens or hundreds of service principals and managed identities in place. Few of those have been reviewed for who can control them, not just what they can access. A short discovery exercise usually reveals more exposure than teams expect.
What should a CISO ask their team to find out where these paths exist?
Start with one question: who can control our most sensitive identities, not just what those identities can access? Ask which teams own application credentials, workload permissions, and management capabilities like Run Command. Ask whether anyone has mapped those relationships end to end. If the honest answer is “we’re not sure,” that’s the starting point for an assessment.
Is this a compliance issue, a technical issue, or both?
Both. A compliance programme can confirm that roles and permissions match written policy. It can’t confirm that those permissions don’t chain together into something riskier. That gap is exactly why frameworks like CISA’s Entra ID baseline are useful but incomplete on their own. Effective privilege is a technical question that compliance checklists aren’t built to answer.
What’s a reasonable first step, and what does it cost to get started?
Start with an inventory of your highest-value service principals and managed identities. Then ask who can control each one, not just what it can access. Many organisations can do this internally with existing tooling and a few days of focused work. Cost scales with environment size and complexity. An external assessment is a natural next step once internal gaps are clearer.
How is this different from a standard access review we’re already doing?
A standard access review asks what an identity can do. This approach adds the reverse question: who or what can control that identity? Most reviews stop at the first question. That’s exactly the gap attackers use. The two approaches complement each other; neither replaces the other.
What should we expect from an offensive security engagement on this?
Expect an attack-path view, not another list of permissions. A good assessment maps which identities are reachable from a low-privileged foothold. It tests whether that path actually works, rather than assuming it does. The output should tell you which paths are real, which are theoretical, and where to invest first.
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specialises in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.