Workload Identities Are the Real Perimeter
The Incident Nobody Wants to Admit
The call comes in on a Tuesday afternoon. A security engineer has been chasing an alert for two hours and has hit a wall. There is lateral movement inside a cloud environment, but none of the conditional access logs show anything. No failed MFA prompts. No impossible travel. No anomalous sign-in risk scores. Just a service principal, quietly reading from a key vault it probably should not have touched, moving tokens it definitely should not have had, and authenticating without friction to three additional subscriptions.
When the incident team asks who owns the app registration, the answer is silence. The original developer left eighteen months ago. The team that inherited the project assumed it was “platform’s thing.” Platform assumed it belonged to the application team. Nobody had reviewed its permissions since it was granted Contributor on a subscription to unblock a deployment sprint two years prior.
The punchline is not that the attackers were clever. The punchline is that Conditional Access did not even apply. The org had spent eighteen months tightening MFA enforcement, building phishing-resistant auth flows, and tuning sign-in risk policies. None of it touched this path. They had governed humans; workloads owned them.
The Uncomfortable Reality: Conditional Access Is Not the Control Plane for Workloads
Let us be direct about something that is easy to gloss over in architecture reviews: Conditional Access is an execution engine for interactive, human-initiated sign-ins. It was designed to evaluate session context for users. When a service principal authenticates using a client secret, a certificate, or a federated credential, that flow does not traverse the same policy engine. The signals CA relies on, device compliance, location, sign-in risk, session controls, are simply not present.
This is not a bug or a vendor oversight. It reflects the fundamental difference between human authentication, which is interactive and context-rich, and workload authentication, which is designed to be fast, automated, and non-interactive. Those properties make workloads useful. They also make workloads invisible to most of your compensating controls.
The failure pattern in most enterprises looks like this: a service account or service principal gets excluded from a Conditional Access policy because including it would break automated processes. The exclusion is documented as a temporary exception. The exception never expires. Six months later, the exclusion list has forty entries, nobody remembers why half of them are there, and each one represents an authentication path with no runtime controls around it.
Security teams respond to this by adding more CA policies, tightening conditions, chasing down exclusion justifications. That is reasonable for the human sign-in surface. But workloads need their own governance model entirely. Layering more human-focused controls on top of a path that those controls cannot touch is not defense in depth. It is the appearance of defense without the substance.
The shift required here is conceptual before it is technical. Workload identities are not a special category of user identity that needs a different policy. They are a separate class of identity with different risk characteristics, different lifecycle dynamics, and different governance requirements. Treating them as an afterthought inside the human identity governance framework is how you end up with a service principal holding Contributor rights to a production subscription with a two-year-old secret and no known owner.
What Counts as a Workload Identity (and Why the Category Matters)
Enterprise security teams often have a loose, informal understanding of what workload identities are. That looseness is part of the problem. When you cannot clearly define the category, you cannot inventory it, govern it, or defend it.
In practical enterprise terms, workload identities include service principals and app registrations, which are the primary mechanism for granting non-human access in cloud identity platforms. They include managed identities, which are platform-bound and credential-free, making them lower-risk but not zero-risk. They include service accounts in traditional directories, often carrying legacy permissions from before the cloud migration. They include pipeline identities, whether those are long-lived tokens stored in CI/CD variables or short-lived OIDC-federated credentials issued per-run. And they include certificates and secrets used for machine-to-machine authentication, often distributed across multiple systems, sometimes shared with vendors, sometimes stored in places your secrets management platform does not know about.
What makes all of these dangerous is not any single property but the combination of several.
First, there is no human friction. A service principal authenticating at 3 AM generates no MFA prompt, no push notification, no anomalous sign-in alert tied to a user’s baseline. If the credential is valid, the authentication succeeds.
Second, permissions tend to be broad. Not because engineers are malicious, but because scope is easier to expand than to narrow. When a deployment fails because a service principal lacks a permission, the fix is to add the permission. When the deployment succeeds, nobody goes back to remove it.
Third, credentials are long-lived. Secrets and certificates expire on schedules that engineering teams set and then forget. A ninety-day secret is renewed before expiry, then renewed again, then renewed again, eventually becoming a perpetual fixture. Managed identities avoid this problem, but they are not universally available, and they do not solve the permissions problem.
Fourth, ownership is opaque. Unlike user accounts, which have a human attached, workload identities often have an organization or a project as their nominal owner. When that project ends or the responsible engineer leaves, the identity becomes a ghost in the system with full credentials and no accountable human.
This combination, no friction, broad permissions, long-lived credentials, and opaque ownership, is precisely what makes workload identities an attractive lateral movement path for attackers who have gained initial access to any environment that trusts them.
The Three Ways Workload Identities Quietly Become Tier 0
Permissions Creep and “It Just Needs Contributor”
It starts reasonably enough. A pipeline needs to deploy infrastructure. The engineer scopes it to the resource group and moves on. Three months later, the pipeline needs to read from a key vault in a different resource group. The cleanest fix is to add the key vault access explicitly, but the fastest fix is to bump the principal to Contributor at the subscription level and close the ticket. Nobody flags it. The principal now has write access to every resource in the subscription, including log analytics workspaces, storage accounts, and every other key vault.
Over the next year, the same principal gets referenced in two additional pipelines because it already has the permissions and creating a new one takes approvals. It touches seven resource groups. It has implicit read access to diagnostic logs. Nobody who works there today knows the full blast radius if that credential is compromised. What started as a scoped deployment identity has become a de facto Tier 0 principal without anyone making a deliberate decision to elevate it.
Permissions creep happens because the friction is asymmetric. Adding permissions is a two-minute task. Scoping them down requires understanding dependencies you may not have documented. The path of least resistance is accumulation.
Credential Sprawl and “We’ll Rotate Later”
The secret is generated. It gets pasted into three places: a CI/CD variable, a config file in a developer’s local environment for testing, and a shared document that was supposed to be temporary. One of those three places is not in your secrets management platform.
The rotation date is set for ninety days. At eighty-nine days, a different engineer extends it by another year because the rotation process was not documented and there is a release happening. The rotation happens eventually, but the old secret stays valid for a week during the transition window and nobody removes it from the config file, which has since been committed to a repository that three vendors have access to.
This is not negligence. This is the normal entropy of engineering at scale. Secrets management is a discipline that requires sustained investment, tooling, and process. Most enterprises have the tooling. Fewer have the process. Almost none have enforcement that catches secrets in places the tooling does not scan.
Long-lived credentials distributed across environments that your secrets management platform does not cover are breached credentials waiting to happen. The credential is valid. It has permissions. It has no MFA. And nobody knows where all the copies are.
Shadow Ownership and the Orphaned App Problem
This failure mode is slower and quieter than the other two. An app registration is created for an integration with a third-party system. The engineer who built it moves to a different team, then leaves the company. The integration continues working. The principal continues authenticating. Nobody reviews it because nothing is broken.
Eighteen months later, the integration with the third-party system has been replaced by a different tool. The old app registration was not decommissioned because nobody was sure what would break. Now you have a principal with valid credentials, permissions in production, and no owner, no documentation, and no clear purpose.
These orphaned principals accumulate in every mature environment. They represent a permanent, unmonitored attack surface. An attacker who obtains the credential inherits all the permissions and generates no anomalous behavior, because the expected behavior of the principal is “unknown.” You have no baseline to detect against.
Security drift is the default state of any environment where ownership is unclear and reviews are infrequent. Entropy is always working against you. Without active governance, the direction of travel is toward more orphaned principals, more broad permissions, and more long-lived credentials, regardless of how well-designed your architecture was at launch.
Why Workload Identity Governance Fails in Most Enterprises
The root cause is almost never technical. The technical controls exist. The problem is organizational.
Ownership is genuinely unclear. Identity and access management teams consider workload identities a development concern. Application teams consider it an infrastructure concern. Platform and cloud teams consider it a security concern. In practice, nobody has clear decision rights, so nobody owns the outcome. This is not a cultural failure so much as a structural one. When nobody is accountable for the lifecycle of a principal, the default behavior is to create and never deprovision.
Reviews are not embedded in delivery processes. Access reviews for human identities are increasingly standard. Workload identity reviews are not. They tend to happen after an incident, during a compliance audit, or when someone is asked to pull an inventory and is shocked by what they find. Reviews that happen once a year, in response to external pressure, are not governance. They are a checkbox.
Exceptions are easier than redesign. When a governance policy gets in the way of a delivery deadline, the path of least resistance is an exception. Exceptions are approved. Exceptions are not revisited. Over time, the exception list becomes the operational reality, and the policy becomes theoretical. This is how identity is the new perimeter becomes a slogan rather than a practice.
The deeper issue is that most enterprises were not built to govern non-human identities with the same rigor they apply to human identities. The tooling, the process, and the culture all developed around the assumption that the primary risk was users doing bad things. Workload identities were treated as infrastructure, not as identity. That assumption has not caught up with the actual threat landscape.
The Minimum Viable Governance Model
The goal here is not a perfect governance program. The goal is a governance program that is sustainable, that catches the worst failures, and that does not collapse under the weight of operational reality. Here is what that looks like in practice.
Inventory as a Control
The inventory is not a spreadsheet. A spreadsheet is a snapshot. What you need is a live record that is part of your identity management process, updated automatically where possible and manually verified on a defined cadence.
For each principal, you need to track: the principal identity and type, the permissions it holds and at what scope, the credential type and rotation schedule, the last authentication timestamp, the owning team and the specific human accountable for it, and the services or pipelines that depend on it.
The last item is the one most inventories skip and the one that matters most when you need to decide whether to remove or rotate something. If you cannot answer “what breaks if this goes away,” you cannot govern it.
Automated tools can pull most of this data from your cloud provider and identity platform. The hard parts are ownership and dependency mapping, which require human input and are worth the effort to establish once, at the time of creation, rather than trying to reconstruct it after the fact.
Decision Rights and Cadence
One of the most practical things you can do is define, explicitly, who can approve what. This is the decision rights and cadence question that governance programs routinely leave vague.
Who can grant tenant-wide roles to a service principal? This should require written approval from a named identity authority, not just a ticket from the requesting team. Tenant-wide roles have blast radius across your entire directory.
Who can create new federated credentials or add certificate-based authentication to an existing principal? Same level of scrutiny. Credentials are the attack surface.
Who can approve Contributor or equivalent at subscription scope? This should require an architectural review, not just a manager approval. Contributor at subscription scope is effectively Tier 0 in most environments.
These approvals should be documented, time-bound, and linked to the inventory. If a principal’s permission grant cannot be traced to an approval, it should be flagged immediately.
Reviews with Teeth
A review cadence means nothing if the consequence of a failed review is “we’ll follow up.” Reviews need a default outcome: if the review is not completed with evidence of business justification, the principal is suspended.
For high-privilege principals, monthly review. For standard principals, quarterly. The evidence required is not a checkmark. It is last-used logs showing active authentication, a dependency map showing what uses the principal, and a named owner who can attest to the continued need.
Time-bounding is the most powerful mechanism here. If a principal’s permissions are granted for twelve months with an explicit renewal requirement, the renewal becomes an active decision rather than a passive non-decision. Most of the orphaned principals in your environment exist because nobody made a decision to remove them. Time-bounding forces the decision.
Guardrails That Prevent Reintroducing the Problem
Governance at the review stage is necessary but insufficient. You also need guardrails that prevent the bad patterns from being introduced in the first place.
Pipelines should require approved identity patterns. If your CI/CD platform can authenticate via short-lived OIDC tokens, that should be the required pattern, not a recommendation. Long-lived secrets in pipeline variables should require an exception, not be the default.
Least-privilege role templates make it easier to do the right thing. If there is an approved role for “deployment pipeline to resource group X,” engineers will use it. If the only option is “Contributor at subscription scope,” that is what they will request. Make the secure path the easy path.
Time-bound credentials where possible. Where credential rotation is not automated, set expiry and treat non-renewal as an implicit revocation. The friction of renewal is a feature, not a bug. It creates a forcing function for review.
Break-glass procedures for automation should be documented and exceptional. When a pipeline needs emergency access that bypasses the normal model, that should require approval, logging, and post-incident review. Emergency access is not an argument for permanent broad permissions.
How to Start in 30 Days Without Boiling the Ocean
The governance model above is not a project you complete in a month. But you can make meaningful progress in thirty days by focusing on scope rather than comprehensiveness.
Pick one subscription, one platform team, or one critical workload. Not your entire environment. A single scope where you can do the work properly is worth more than a partial inventory of everything.
Pull the top twenty principals in that scope by privilege level and permission scope. You are looking for anything with subscription-level access, directory roles, or access to secrets and key management infrastructure. These are your Tier 0 workloads, whether or not anyone labeled them that way.
For each of those twenty, assign an owner. A real human with a name and a team, not a distribution list. Get them to confirm the principal is still needed and document what it does.
Rotate or replace the worst credentials. Anything with a secret older than twelve months that has not been through an automated rotation process should be treated as potentially compromised and replaced. This is not paranoia; it is hygiene.
Establish a review loop. Even a simple quarterly review of those top twenty principals, with a named reviewer and an explicit “justify or suspend” outcome, is a governance loop. It closes the “nobody ever checks” gap.
Finally, establish a rule: no new principals without an owner assignment at creation. You cannot fix the orphaned principal problem retroactively at scale, but you can stop creating new ones. That rule, enforced at the pipeline and deployment level, stops the entropy from compounding.
Your Identity Perimeter Is Only as Strong as Your Least Governed App
The assumption that identity is the new perimeter is correct. What most enterprises have not fully internalized is that the perimeter is defined by the weakest governed identity, not the average one.
You can have flawless Conditional Access enforcement for every human in your directory. You can have phishing-resistant MFA, continuous access evaluation, and session anomaly detection. All of it is bypassed by a service principal with a two-year-old secret, Contributor rights at subscription scope, and no known owner. That principal is not a gap in your human identity controls. It is a separate attack surface that your human identity controls were never designed to address.
If you can’t explain who owns these decisions and how exceptions expire, you don’t have controls, you have intentions. It is building a governance model for workload identities that matches the rigor you apply to privileged user accounts. That means inventory, ownership, reviews with consequences, and guardrails that prevent the patterns from recurring.
The enterprises that get this right will not get there by finding the perfect tooling. They will get there by deciding that workload identities are not infrastructure someone else governs. They are identity. They carry privilege. They have blast radius. And they deserve the same accountability structures you have built for your most sensitive human access.
The question is not whether you have workload identity risk in your environment. You do. The question is whether that risk is visible, owned, and governed, or whether it is accumulating quietly in the background while your attention stays focused on the human identity surface that attackers have already learned to route around.
