The meeting starts with a simple question: “Can anyone tell me what this service account actually does?” Three people glance at the dashboard, then at each other, and nobody wants to be the first to guess. The account has domain admin permissions, has not rotated credentials in years, and shows sporadic logins at odd hours. It was created “for a migration” by someone who left two reorganizations ago, and the system it talks to has been renamed twice. That awkward silence is what “immortal” infrastructure users feel like in real life: everyone is slightly afraid of them, and no one really owns them.
This Wednesday “Headline” feature in Bare Metal Cyber Magazine is about those accounts. Not the shiny single sign-on flows or the elegant policy-as-code repositories, but the non-human identities that quietly outlive their owners, projects, and even entire platforms. They sit in cloud subscriptions, directories, Kubernetes clusters, and CI pipelines with broad permissions and stale secrets, and they are almost always cheaper to ignore than to fix. Until the day they are not, and they become the pivot point in an incident, the reason an audit gets ugly, or the blocker that makes a critical migration far more painful.
For security and technology leaders over the next few years, this is less a tooling story and more an infrastructure hygiene story. The organizations that treat service accounts as first-class identities, with real lifecycles and owners, will have a very different risk profile from those that keep doing one-off cleanup projects every time an auditor or red team finds something embarrassing. The work is long, boring, and critical, but it is also one of the most leverage-rich ways to turn identity from a fragile dependency into a durable control surface. The question is whether you are willing to redesign the system that keeps creating immortal users in the first place.
The Graveyard Under Your Cluster
If you ask for a full list of non-human identities in most environments, what you get back is less a roster and more a graveyard. In a typical mid-size enterprise, there are service accounts created for long-finished initiatives, “temporary” integration users that quietly became permanent, and mysterious entries with names that made sense to someone three years and two platforms ago. They live in cloud identity stores, on-prem directories, Kubernetes namespaces, CI pipelines, and third-party SaaS admin consoles. Very few are tied cleanly to a current business capability, a current owner, and a current set of access expectations. Even fewer have a clear plan for when they should be retired.
You see this most starkly in infrastructure layers that move fast. A Kubernetes cluster might have a handful of well-understood workloads today and dozens of stale service accounts left behind by old Helm charts, experiments, and internal tools. A cloud subscription often accumulates service principals created for proof-of-concept projects that never quite died, backup jobs that were replaced but never decommissioned, and “break-glass” accounts that no one can remember ever testing. CI pipelines carry their own fossils: build bots, deployment identities, and test harness users that kept their permissions when the architecture changed under them. The pattern is the same: account creation happens in a hurry; cleanup never makes it into the sprint.
At the identity layer, the story is no better. Directories are full of “svc_” or “app_” prefixed accounts that were created with good intentions and minimal documentation. The ticket to create them might reference a system name that no longer exists, a project code that nobody uses, or an owner who has since moved on. Permissions often ratchet upward over time because each new dependency is solved by adding a role or group, not by revisiting the design. From a leader’s perspective, the crucial point is that this graveyard is not just clutter: it is a dense, poorly mapped web of credentials and permissions that an attacker, or a misconfigured automation, can exploit.
What makes this graveyard especially dangerous is how invisible it is in day-to-day decision making. Dashboards usually focus on human accounts, MFA adoption, and privileged access reviews for admins. Service accounts sit in their own category, often excluded from standard controls because “they are automated” or “they will break if we touch them.” The result is an identity surface where some of the most powerful and least monitored users are the ones no one thinks about. Understanding how we got here is the first step to changing it, because the root cause is not a lack of technology, but a system that encourages creating immortal accounts and punishes anyone who tries to kill them.
Why Service Accounts Never Die
Service accounts do not become immortal by accident; they become immortal because the path of least resistance keeps them alive. Creating a new non-human identity is almost always easy. An engineer opens a ticket or runs a CLI command, gets the access they need, wires the credentials into a pipeline or config file, and ships. The incentives are all aligned around unblocking delivery. The work of defining a sensible scope, tying the account to a lifecycle, and documenting who owns it feels like friction, especially when the project is “just a quick integration” or “only for this migration.” Nobody is rewarded for designing the death of an account that does not exist yet.
Deletion, on the other hand, is expensive and scary. By the time someone questions an account, the person who created it might be gone, the system diagrams are out of date, and the only thing anyone knows for sure is that production still works. Turning it off feels like defusing a bomb with no schematic. If the account underpins a brittle legacy integration or a revenue-critical process, the default decision is to leave it alone “until we have more time.” That time never arrives. Instead, teams wrap more change around the same account, widening its blast radius and increasing the cost of every future decision involving it.
There is also a structural gap in most join-move-leave processes. Human identities are wired into HR events, manager changes, and access reviews. Non-human identities are wired into backlogs and release notes, if at all. When a project ends, a platform is replaced, or a contractor leaves, nothing in the system automatically asks, “Which service accounts can die with this change?” Responsibility falls into the cracks between teams: infrastructure assumes application teams will clean up, application teams assume platform will handle it, and security teams are left running point-in-time campaigns that barely make a dent. As a leader, you are not fighting individual bad decisions; you are fighting a system that bakes immortality into the way you ship.
Finding the Immortals That Actually Matter
Once you accept that you cannot clean up everything at once, the next move is to decide which immortal accounts actually matter. A naive approach tries to inventory every non-human identity and treat them all as equal. That usually collapses under its own weight, leaving a spreadsheet graveyard next to the account graveyard. A more practical approach starts by assembling just enough data to sort service accounts into meaningful buckets. You do not need a perfect catalog on day one; you need a view that helps you say, “These ten are obviously dangerous, these fifty are worth a deeper look, and the rest can wait.” The goal is not completeness, but risk-weighted visibility.
The strongest signal is usage. Accounts that have not authenticated in months, or whose credentials have not been rotated since the previous CIO, are low-hanging candidates for investigation. Combine that with permission scope and proximity to sensitive systems: an unused account with read-only access to a test environment is a different animal from an unused account with broad access to production databases. You can also look at origin and context. Accounts created by automated patterns, with clear naming and ownership, are more likely to be manageable. Accounts created ad hoc in the middle of an incident, with vague descriptions and “temporary” in the ticket, are prime suspects. Leaders should push for views that overlay these signals, not separate reports that no one has time to reconcile.
From there, triage is about framing decisions instead of chasing perfection. One useful pattern is to sort accounts into three paths. The first is “safe to kill with rollback”: accounts that appear unused, can be disabled behind a guardrail, and monitored for impact. The second is “needs staged cleanup”: high-risk accounts that are still active but clearly over-privileged, where the right move is to wrap them in compensating controls and plan a refactor. The third is “architectural redesign required”: identities wired so deeply into legacy systems that the only real fix is part of a larger modernization effort. By naming these categories and agreeing how they are handled, you turn an overwhelming cleanup problem into a portfolio of risk decisions that can be owned, funded, and tracked.
Designing a Real Lifecycle for Non-Human Identities
If immortal accounts are a product of your current system, the only durable fix is to change the system. That starts by treating non-human identities as first-class citizens of your Identity and Access Management (IAM) program, not as a miscellaneous category. A real lifecycle has a beginning, a middle, and an end. At the beginning, every service account request should be tied to a clear workload, owning team, and risk classification. In the middle, there should be standards for how secrets are stored, rotated, and monitored. At the end, there should be an explicit retirement path when a project ends, a platform changes, or an integration is replaced. If you cannot point to those three stages today, you do not have a lifecycle; you have a ticket queue.
One powerful shift is binding identities to workloads instead of people or vague purposes. In cloud and container platforms, that means using managed identities, workload identities, or similar constructs that are issued and scoped automatically based on where the code runs. Credentials live in a secrets management system, not in config files or environment variables passed around by hand. Short-lived tokens replace long-lived passwords, so the default state is “no standing access” unless the workload is running. When you tear down the workload, the identity goes with it. That design does not eliminate risk, but it makes immortality much harder to achieve. It also gives platform teams a concrete set of patterns to promote, instead of asking every project to invent its own.
The lifecycle also needs to be wired into change processes leaders already care about. New service accounts should be part of change approvals, architecture reviews, and deployment templates, not side conversations in chat. Decommissioning should be a required step in project closure and platform migrations, with specific checks for non-human identities: which accounts will be removed, which will be replaced by different patterns, and who confirms completion. Periodic reviews should cover service accounts alongside human users, with clear expectations that owners either justify continued existence or schedule retirement. Leaders do not need to design every rule, but they do need to insist that every account has a story for how it is born, how it lives, and how it dies.
Making Cleanup Stick: Owners, Governance, and Metrics
The hardest part of cleaning up immortal service accounts is not the first campaign; it is stopping the problem from quietly regrowing afterward. That is a governance problem, not a scanning problem. To make cleanup stick, leaders need to make non-human identity hygiene someone’s real job, not a side quest for whoever cares most. In practice, that means assigning clear ownership at two levels. At the platform level, a team owns the patterns, guardrails, and shared services that define how service accounts are created and managed. At the application or domain level, teams own specific accounts and the workloads they support. When an account shows up on a dashboard, it should be obvious which team is accountable for its existence and health.
Governance is where you shift from “please do better” to “this is how we work.” Access policies should distinguish between approved patterns and exceptions. For example, service accounts that do not follow platform patterns, or that use long-lived credentials outside secrets management, are treated as exceptions that require explicit approval and an expiry date. Architecture review boards and security champions can reinforce this by asking the same questions every time a new integration or system shows up: which identities will it introduce, how are they scoped, who owns them, and how will they be retired. Over time, this normalizes the idea that an integration is not complete until its identity story is complete.
Metrics are how you keep attention on the problem without resorting to fear or anecdotes. Useful measures are simple and trendable. How many non-human identities exist relative to human users? What percentage have a clearly identified owner and documented purpose? How many have not been used in the last ninety days? What is the growth rate of service accounts month over month, and how many are being retired versus created? You do not need a perfect answer on day one, but you do need a small set of numbers that show whether your environment is trending toward more immortal accounts or fewer. When leaders review those metrics alongside incident rates, audit findings, and platform performance, they send a clear signal: service account lifecycle is part of running the infrastructure, not an optional cleanup sprint.
Where Leaders Go From Here
At its heart, this topic is about whether you treat non-human identities as real parts of your infrastructure or as background noise. Immortal service accounts are not a quirk of individual teams; they are the natural outcome of a system that makes creation cheap, retirement risky, and ownership ambiguous. The graveyard under your clusters, directories, and pipelines is a mirror of your incentives and processes. When a leader chooses to see that graveyard clearly, it stops being an embarrassing mess and becomes a roadmap for reducing silent, compounding risk.
Closing the loop means returning to that awkward meeting where nobody wants to touch the mysterious admin account. In an organization that has redesigned its lifecycle, that silence is replaced with a simple, shared playbook. Owners are known, patterns are standard, and the decision is not “do we dare turn this off” but “which of our three paths does this account follow: safe kill, staged cleanup, or architectural redesign.” Service accounts are created through consistent workflows, retired as part of planned change, and continuously measured like any other critical asset. The result is not perfection, but a steady reduction in surprises and a more honest understanding of where your real dependencies lie.
For leaders, the real shift is mental. Immortal infrastructure users are no longer seen as boring maintenance work to be delegated away, but as leverage points for resilience. When you internalize that, conversations change: migration plans include identity cleanup, legacy risk is framed as concrete accounts and privileges, and teams learn that “it just works, do not touch” is not an acceptable long-term state. The next time you look at a dashboard full of service accounts, a useful question to ask your team is simple: “Which of these identities are we willing to bet the company on, and which ones are we finally going to let die?”
