Bare Metal Cyber

The meeting starts with a simple question: can anyone explain what this one service account actually does?

Three people stare at the same dashboard, then glance at each other. Nobody wants to guess. The account has broad permissions, its password has not changed in years, and it logs in at odd hours from systems no one quite recognizes. It was created for a migration by someone who left two reorganizations ago. The system it connects to has been renamed twice.

That awkward silence is what an immortal infrastructure user feels like in real life. Everyone is slightly afraid of it, and no one really owns it.

You are listening to a Wednesday Headline feature from Bare Metal Cyber Magazine, developed by Bare Metal Cyber, titled “Service Accounts Never Die: Cleaning Up the Immortal Infrastructure Users.”

This is about the long, boring, critical work of dealing with non-human identities that outlive their owners, projects, and sometimes entire platforms. These accounts sit in cloud subscriptions, directories, Kubernetes clusters, build pipelines, and third-party tools. They often have powerful permissions and stale secrets. They are almost always cheaper to ignore than to fix, right up until the day they become the pivot point in an incident or the reason an audit becomes uncomfortable.

The question for leaders is simple. Will you keep inheriting this risk, or will you redesign the system that creates it?

If you pulled a full list of non-human identities in most organizations, you would not see a clean roster. You would see a graveyard. There are accounts created for long-finished projects, temporary integration users that 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-premises directories, Kubernetes namespaces, deployment pipelines, and vendor consoles. Very few are tied cleanly to a current business capability, a current owner, and a current access expectation. Even fewer have a clear plan for how and when they should be retired.

The problem is especially visible in fast-moving infrastructure. A Kubernetes cluster may have a few well-understood workloads today, but dozens of stale service accounts left behind by old charts, experiments, and internal tools. A cloud subscription may contain principals created for proof-of-concept projects, replaced backup jobs, or emergency access that nobody remembers testing. Build systems often carry old bots and deploy users that kept broad permissions even as the architecture changed around them.

Account creation happens in a hurry. Cleanup rarely makes it into the sprint.

Directories are not much better. Many environments are full of service or app accounts created with good intentions and minimal documentation. The original request may reference a system name that no longer exists, a project code nobody uses, or an owner who moved on years ago. Over time, permissions ratchet upward. Each new dependency gets solved by adding another role or group, not by revisiting the original design.

This is not just clutter. It is a poorly mapped web of credentials and permissions that an attacker, or even a broken automation, can exploit.

What makes the graveyard especially dangerous is how invisible it is in daily decision-making. Dashboards usually focus on human users, multifactor authentication, and privileged access reviews for named administrators. Automated accounts sit in a separate category. They are often excluded from standard controls because they are automated, or because people fear they will break if touched.

The result is an identity surface where some of the most powerful and least monitored users are the ones no one thinks about.

Service accounts do not live forever by accident. They live forever because the path of least resistance keeps them alive.

Creating a non-human identity is usually easy. Someone opens a ticket or runs a command, gets the access they need, wires the credentials into a pipeline or configuration file, and moves on. The incentives are all about unblocking delivery. Defining scope, tying the account to a lifecycle, and documenting ownership all feel like friction.

Very few people are rewarded for designing the death of an account that does not exist yet.

Removal is different. Removal is expensive and scary. By the time someone questions an account, the creator may be gone, diagrams may be outdated, and the only hard fact anyone has is that production still works. Turning it off feels like defusing a bomb without a schematic.

When an account supports a brittle legacy integration or revenue-critical process, the default decision is to leave it alone until there is more time. That extra time almost never arrives. Instead, teams build more change around the same identity, increasing its blast radius and making future cleanup even harder.

There is also a structural gap in most identity processes. Human accounts are tied to hiring, job changes, manager reviews, and departures. Non-human accounts are tied to backlogs and release notes, if they are tracked at all.

When a project ends, a platform changes, or a contractor leaves, nothing automatically asks which service accounts should disappear too. Infrastructure teams assume application owners will clean up. Application owners assume platform teams will handle it. Security teams are left running one-off cleanup campaigns that barely make a dent.

The issue is not a few bad decisions. It is a system that makes account creation one-way and account retirement optional.

Once you accept that you cannot fix everything at once, the next question is which immortal accounts matter most. A naive approach tries to inventory every non-human identity and treat them all equally. That usually becomes a giant spreadsheet nobody trusts.

A better approach is to gather enough data to sort accounts into useful buckets. You do not need a perfect catalog on day one. You need enough visibility to say, these accounts are clearly dangerous, these need deeper investigation, and these can wait.

The strongest signal is usage. Accounts that have not authenticated in months, or whose credentials have not rotated in years, deserve attention. Then you compare that with permission scope and proximity to sensitive systems. An unused account with read-only access to a test environment is very different from an unused account with broad access to production databases.

You can also look at origin and context. Accounts created through approved automation, with consistent naming and clear ownership tags, are usually easier to manage. Accounts created ad hoc during an incident, with vague descriptions and the word temporary in the request, are prime suspects.

From there, triage becomes more practical. One useful model sorts accounts into three paths.

The first path is safe to kill with rollback. These are accounts that appear unused, can be disabled behind a guardrail, and can be monitored for impact.

The second path is staged cleanup. These are active but overprivileged accounts. The right move is to add compensating controls, reduce permissions, improve monitoring, and schedule a refactor.

The third path is architectural redesign required. These are identities wired so deeply into legacy systems that the only real fix is tied to broader modernization.

Naming these paths gives everyone a shared language. It turns cleanup from an endless argument into a set of decisions that can be owned, funded, and tracked.

If immortal accounts are products of your current system, the durable fix is to change that system. That starts by treating non-human identities as first-class parts of your Identity and Access Management program, not as a miscellaneous exception bucket.

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, an owning team, and a basic 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.

Without those stages, you do not have a lifecycle. You have a queue of one-way creations.

One powerful shift is binding identities to workloads instead of people or vague purposes. In cloud and container platforms, that means using managed or workload identities that are issued and scoped automatically based on where code runs.

Credentials should live in a secrets management system, not inside configuration files scattered across repositories. Short-lived tokens should replace long-lived passwords wherever possible. The default state should be no standing access unless the workload is running.

When the workload is removed, its identity should go with it. That design does not eliminate risk, but it makes immortality harder to achieve.

The lifecycle also needs to connect to the change processes leaders already care about. New service accounts should be part of change approvals, architecture reviews, and deployment templates. They should not be created through side conversations in chat.

Decommissioning should be a required step in project closure and platform migrations. Teams should identify which accounts will be removed, which will be replaced, and who confirms completion. Periodic access reviews should include service accounts alongside human users, with clear expectations that owners either justify continued access or schedule retirement.

Every account needs a story. How it is born. How it lives. How it dies.

The hardest part is not the first cleanup campaign. The hardest part is stopping the problem from quietly returning after everyone relaxes. That is a governance issue, not just a scanning issue.

To make cleanup stick, someone has to own non-human identity hygiene as a real responsibility. In practice, ownership usually works at two levels. At the platform level, one 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 the specific accounts and workloads they support.

When an account appears on a dashboard, it should be obvious which team is accountable for its existence and health.

Governance is where the organization shifts from polite requests to a standard way of working. Access policies can distinguish approved patterns from exceptions. For example, service accounts that use long-lived credentials outside secrets management can be treated as exceptions requiring 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 appears. Which identities will it create? How are they scoped? Who owns them? How will they be retired?

Over time, this normalizes a simple idea: an integration is not complete until its identity story is complete.

Metrics help keep attention on the problem without relying on fear. Useful measures are simple and trend over time. How many non-human identities exist compared with human users? What percentage have a clear owner and documented purpose? How many have not been used in the last ninety days? How many were created this month, and how many were retired?

The goal is not perfect precision. The goal is to understand whether the environment is drifting toward more immortal accounts or fewer, and to make that trend visible in leadership conversations.

At its heart, this topic is about whether you treat non-human identities as real infrastructure or background noise. Immortal service accounts are not a quirky by-product of a few messy projects. They are the natural outcome of a system that makes creation cheap, retirement risky, and ownership unclear.

The graveyard under your clusters, directories, and pipelines is a mirror of your incentives and processes. When you choose to see it clearly, it stops being an embarrassing mess and becomes a roadmap for reducing silent, compounding risk.

Imagine returning to that earlier meeting with the mysterious admin account nobody wants to touch. In an organization with a real lifecycle, the silence is replaced by a shared playbook. Owners are known. Patterns are standard. The decision is not whether anyone dares to turn the account off. The decision is which path it follows: safe kill, staged cleanup, or architectural redesign.

Service accounts are created through consistent workflows, retired as part of planned change, and measured like any other critical asset. The organization does not get perfection, but it does get fewer surprises and a more honest understanding of where its real dependencies live.

For leaders, the real change is mental. Immortal infrastructure users stop being boring maintenance work and become leverage points for resilience. Migration plans include identity cleanup. Legacy risk is described in terms of specific accounts and privileges, not only abstract technical debt. Teams learn that “it just works, do not touch” is not an acceptable long-term state for anything that can make or break the business.

A useful question for your next review is simple. Which of these identities are you truly willing to bet the company on, and which ones are finally going to be allowed to die?