Table of Contents
Last week I closed with this: patching is the drift people remember, because it shows up as a CVE alert or a failed compliance scan. Identity lifecycle is the drift people look away from, because nothing forces them to look at it.
And it’s where the gap between “designed” and “operated” gets genuinely dangerous.
This week I want to make that case properly, and workload identity lifecycle is the clearest example I’ve got.
What It Looks Like on Paper
If you’ve read my post on Entra Workload Identities Explained, you’ll know the design guidance is settled and sensible:
- One identity per workload, with no sharing across applications or environments
- Managed identities by default for workloads running in Azure
- Federated identities for workloads outside Azure that support OIDC
- Service principals with secrets treated as legacy and phased out where possible
- Least-privilege access, regular reviews, monitored sign-ins and documented ownership
I’ve also covered the security side of this in more depth in Secure Workload Identities in Entra ID, including automating secret rotation through Key Vault and Event Grid.
None of that is wrong. It’s good guidance, and if you follow it, your identity estate is probably in a strong position on the day you design it.
The problem isn’t what the identity looks like on day one.
The problem is what it looks like twelve months later.
What Actually Happens
Here’s the pattern I keep running into, and I’d guess most people reading this have seen some version of it too.
Someone on the team creates a service principal. Or an app registration gets created as part of a pipeline run. It supports a specific project, integration or proof of concept that quietly becomes load-bearing.
The identity gets scoped, permissions get assigned and everything works.
Then the person who built it leaves. Or moves teams. Or the project ships and attention moves somewhere else.
The identity doesn’t leave with them.
It has no dependency on the person who created it, so it keeps authenticating and keeps holding whatever permissions it was granted. It might run every day, once a month, or only during a particular business process. From the platform’s point of view, nothing is wrong.
Nobody revokes it because nobody is certain whether it is still needed. Nobody reviews it because the only person who understood it is gone. The identity still exists, but the context around it has disappeared.
This is the bit that makes identity lifecycle different from patching.
A missing patch is visible. Someone can run a scan and produce a list. An orphaned workload identity doesn’t announce itself in the same way. It looks like another functioning identity in the tenant until somebody deliberately investigates it, an audit asks for evidence of ownership, or an incident forces the question.
By then, the identity may have been sitting there for years.
Why This Rots Quietly
Patching drift and identity drift come from the same root cause: the platform was designed with an assumption of ongoing care, but the operating model never delivered that care.
They fail differently, though.
Patching drift degrades visibly. An unpatched system becomes progressively riskier, and eventually something makes noise. A scanner flags it, a vendor announces an end-of-life date, an audit calls it out, or the software stops being supported.
Identity drift doesn’t necessarily break anything.
The authentication keeps working. The permissions remain valid. The pipeline stays green. But the justification for those permissions gets weaker over time. The workload changes, the team changes and the original purpose becomes harder to prove.
There are tools that can help surface parts of the problem. Entra sign-in data can show whether a service principal is still authenticating, and Entra recommendations can flag applications that appear unused. But those signals aren’t the same as ownership.
An identity authenticating successfully doesn’t prove that it should still exist.
An identity that hasn’t authenticated recently doesn’t prove that it can be safely deleted either. Some workloads run quarterly, annually or only during an incident. Usage is evidence, not a decision.
Someone still has to understand what the identity is for, what depends on it and who is accountable for deciding what happens next.
That’s why identity debt survives. There’s no operational trigger unless you deliberately create one, so the work sits at the bottom of the backlog indefinitely.
Two Different Problems That Get Treated as One
There’s another issue that compounds this, and it’s worth pulling apart because I see it conflated constantly: orphaning and credential management are not the same problem, and they don’t have the same fix.
In-house applications running inside your tenant have very little excuse for using secrets anymore. If the workload runs in Azure, use a managed identity. If it runs outside Azure but supports OIDC, use workload identity federation.
That removes the stored credential. There’s nothing for a developer to paste into a configuration file, nothing to expire unexpectedly and nothing that needs to be manually rotated.
But it does not remove the lifecycle problem.
A user-assigned managed identity can outlive the resources that used it. Its permissions can become excessive as the application changes. Role assignments can remain after an identity has been deleted. A managed identity still needs a purpose, an accountable owner, periodic review and an eventual retirement path.
Managed identity solves credential management. It doesn’t solve governance.
Third-party and external applications are a different story. Plenty of SaaS integrations, vendor tools and external services either can’t federate through OIDC or only support client secrets and certificates.
For this category, the answer isn’t “eliminate the secret.” It’s “manage the credential properly.”
That means shorter expiry periods, monitoring well before expiry, secure storage, and automated rotation wherever the integration supports it. Rotation needs to be end to end as well. Creating a new value in Key Vault is only half the job if the external platform is still configured to use the old one.
The mistake I keep seeing is platform teams treating all of this as one problem with one universal answer. They roll out a “no more service principal secrets” policy and apply it everywhere.
Then they either quietly exempt third-party integrations without documenting why, or they refuse to exempt them and end up with brittle workarounds that nobody is particularly proud of.
You need to know which category an identity belongs to and build an operating model that supports both.
The Ownership Gap
This connects back to something I’ve written about before: most platform failures aren’t technical failures, they’re ownership failures.
An app registration created by a Terraform apply doesn’t have a natural human owner. It has a creator, but creators leave.
If you don’t require an explicit and durable owner at the point of creation, separate from whoever happened to run the pipeline that day, you’re building workload identity lifecycle debt into the platform by default.
The fix isn’t complicated in principle. Require an accountable team, service name, environment and review date as inputs to the module or request process. Record enough information that somebody who wasn’t involved in the original deployment can work out why the identity exists.
The important part is enforcement.
A wiki page telling engineers to document ownership isn’t a control. An optional field on a request form isn’t a control. If the pipeline works without ownership information, it will eventually run without ownership information.
The cost doesn’t appear at creation time, which is why this is so easy to ignore. The identity works perfectly well without a documented owner.
The cost appears later, when someone has to decide whether it is safe to disable and discovers there is nobody left to ask.
Someone Leaving Should Be a Lifecycle Event
If the title of this post has a practical point, it’s this: somebody leaving should be a trigger.
Most organisations already have a leaver process for user identities. Accounts are disabled, sessions are revoked, devices are recovered and group memberships are removed.
Workload identities associated with that person rarely receive the same attention.
Before an employee leaves, you should be able to identify the applications and service principals for which they are the only recorded owner or maintainer. Responsibility should then be transferred to another person or, preferably, to an accountable team.
If nobody is willing to accept ownership, that tells you something important. It doesn’t automatically mean the identity is unused, but it should start an investigation rather than allowing the object to remain untouched indefinitely.
The same should happen when a project closes, a service is decommissioned or a vendor contract ends. These are all lifecycle events, and each one should trigger a review of the identities, credentials and permissions attached to it.
Without those triggers, “temporary” identities become permanent simply because nothing ever asks them to leave.
What Operating This Well Actually Requires
Splitting orphaning from credential management gives you two workstreams rather than one generic checklist.
For ownership and orphaning:
- Require an accountable team, service, environment and review date when the identity is created
- Prevent production identities from being created without that information
- Check for identities whose recorded owners have left or moved teams
- Include workload identity ownership in employee offboarding and service decommissioning
- Review sign-in data and Entra recommendations for inactive applications, while remembering that inactivity alone isn’t proof that something can be deleted
- Require owners to actively confirm continued use instead of sending them a report that nobody has to answer
- Escalate identities that repeatedly fail review rather than allowing “unknown” to become a permanent status
For permissions:
- Revalidate what the identity can access, not just whether the identity still exists
- Compare current permissions with the workload’s current purpose
- Remove permissions that were added for migrations, troubleshooting or temporary project work
- Include Azure role assignments, Microsoft Graph application permissions and access granted directly in downstream systems
- Check for role assignments left behind after identities or resources are deleted
For credentials:
- Move eligible Azure workloads from secrets to managed identities
- Use workload identity federation for external platforms that support OIDC
- Give migration work a deadline rather than leaving it as an aspiration
- For integrations that can’t avoid credentials, use shorter expiry periods and alert well before expiry
- Keep credentials in an appropriate secrets store rather than application configuration or pipeline variables
- Automate rotation end to end wherever the external integration allows it
- Document exceptions so they remain visible and reviewable
For retirement:
- Confirm the identity’s dependencies before removing it
- Remove unnecessary permissions first
- Where the impact is uncertain, disable the identity for an agreed observation period before deleting it
- Monitor for authentication failures or broken dependent processes during that period
- Delete the application, service principal, credentials and remaining role assignments once retirement is confirmed
- Record the decision so the same investigation doesn’t have to be repeated later
That last workstream is the one most identity guidance skips. Creation gets documented in detail. Deletion gets a sentence.
But an identity lifecycle without a retirement process isn’t a lifecycle. It’s an accumulation process.
The Test Is What Happens When the Owner Leaves
The real test of a workload identity lifecycle operating model isn’t whether the identity was created correctly.
It’s whether the organisation knows what to do when the person, project or system associated with it disappears.
Managed identity and federation remove much of the credential-management burden, but they don’t remove the need for ownership, review and eventual retirement. An identity that no longer has a purpose is still identity debt, even if it has no secret to expire.
The platform needs to answer three simple questions for every workload identity:
- Why does it exist?
- Who is accountable for it?
- What causes it to be reviewed or retired?
If you can’t answer those questions without finding the person who originally created it, you don’t have a lifecycle. You have knowledge attached to an employee account and an identity that will probably outlast it.
That’s the difference between designing workload identity securely and operating it securely.
Creation is the easy part.
The quality of the platform shows in whether every identity still has a purpose, an accountable owner and a defined way to leave.
Next time I want to look at a different kind of drift: Terraform operational debt. The gap between the modules you wrote on day one and the ones you’re still running two years later, and what happens when nobody’s kept the two in sync.