the identity you can't offboard

A platform engineer at a 400-person company ran a script in late 2025 to inventory every non-human identity in the environment. The output was a CSV with 2,847 rows. The engineer was expecting a few hundred.

The rows broke down roughly like this. Eight hundred were AWS IAM roles and users tied to specific applications and services. Six hundred were service accounts in the company’s Google Workspace, most of them created for specific integrations. Four hundred were Active Directory service accounts for on-prem systems, many dating back to before the cloud migration. Three hundred were API keys and OAuth apps registered against the company’s own SaaS tools for internal automation. The remaining seven hundred were a mix of CI/CD runners, monitoring agents, backup processes, and “I don’t know what this one does” accounts that nobody on the current team could identify.

Fewer than half of the 2,847 identities had a documented owner. Fewer than a quarter had been touched, meaning rotated, reviewed, or modified, in the last year. About fifteen percent had permissions that exceeded any reasonable current-state need. Seven specific accounts had been flagged during the exercise as “this looks concerning, someone should investigate” and had not yet been investigated three months later.

This inventory is fairly typical for a company of that size. The non-human identity population is usually larger than the human population by a factor of three to ten, depending on how cloud-native the company is. It is also, almost universally, worse managed than the human population.

Human identity problems at least have a workflow. HR creates the employee, IT provisions access, SCIM flows updates, offboarding happens on a Friday. The workflow is imperfect, but it’s named, and it’s owned by someone. Non-human identities have no such workflow. They are created by engineers, for engineering reasons, typically at 3 a.m. during an incident, with the full intention to clean up later. Later arrives eight years after the engineer has left the company.

This essay is about that population, what it is, where it comes from, why it’s broken, and what to do about it.

the service account is created in a hurry

The typical service account origin story goes like this. An engineer needs to automate something. The automation requires access to a system, a database, an API, a cloud resource. Using the engineer’s personal credentials is a bad idea, for reasons the engineer understands. The engineer creates a service account.

The service account gets a name that makes sense at that moment. Maybe etl-pipeline-prod or backup-service or monitoring-readonly. The account gets permissions sufficient to do the job. Often, for expedience, it gets more permissions than the job strictly requires, because figuring out the minimum set would take another hour and the automation needs to be running before the next standup.

The credentials for the service account, an API key, a password, a certificate, get stored somewhere. Ideally in a secrets manager. Often in an environment variable. Sometimes in a config file checked into a private repo. Sometimes in a Slack DM between two engineers, because it was faster than spinning up vault access for a quick test.

The automation runs. The service account does its job. The engineer moves on to the next thing.

Eight years later, three engineers have come and gone, the automation has been rewritten twice, the secrets manager has been adopted and the credentials have been migrated into it at some point, and the service account is still there. Its permissions are the same as they were on day one. Its credentials have been rotated exactly zero times, because rotation was never wired into anything. Nobody currently at the company remembers why the permissions are what they are, so nobody feels authorized to reduce them.

This pattern, multiplied by the number of engineers times the number of automations times the age of the company, produces the non-human identity sprawl every mature company eventually discovers.

a person and a service account, side by side

a person

has a lifecycle

• HR record, manager, start and end date
• Multi-factor authentication
• Reviewed when they move or leave

a service account

has none of it

• Created in a hurry for one job
• Keys that never expire unless someone rotates them
• Permissions that only grow, and an owner who left

credentials that don’t expire

Human credentials, for all their problems, at least have a rotation cycle. Password policies force periodic change. MFA adds a second factor that rotates on every use. Even when the cycles are weak, there is usually some cycle.

Non-human credentials frequently don’t have a cycle at all. An API key issued in 2019 is, by default, a perpetual credential. It does not expire. It does not rotate. It is valid until someone explicitly revokes it or issues a replacement, neither of which happens spontaneously, because the automation using it works fine with the current key.

The reason rotation doesn’t happen for service accounts is that rotation is inherently risky for automation. Changing a credential in a running system requires coordinating the change with every consumer of that credential. If the automation is simple, one service using one key, the coordination is easy. If the automation is a web of services that have been extended over years, the coordination is complex. The risk of a rotation breaking something is high. The risk of leaving the credential in place looks, day to day, like zero.

So the credentials sit. An audit of any mature environment will find service account credentials that predate the current engineering leadership. Credentials where the person who originally generated them has left the company. Credentials where the system the credential was designed for has been decommissioned, but the credential wasn’t revoked, because the revocation ticket sat in a backlog and never got to.

The specific consequence is that a single leaked service account credential can remain exploitable indefinitely. Credential leaks happen all the time, a config file pushed to the wrong repo, a screenshot taken during a debug session, a backup archive left in the wrong S3 bucket. If the leaked credential never rotates, the leak is permanent.

permissions that never shrink

Service accounts are even more vulnerable to permission creep than human accounts, for a specific reason. Humans occasionally ask for permission reductions, when they change roles, when an access review prompts them, when they no longer need something. Service accounts ask for nothing. They execute their configured operations and return.

This asymmetry means the natural direction of service account permissions is strictly upward. Any time a service account needs to do something new, a new permission gets added. Any time a service account’s scope expands, because the automation it supports expanded, or because it was extended to cover a new use case, new permissions get added. Old permissions, from phases of the automation that are no longer relevant, remain.

A common pattern: a service account originally created for a backup job has backup-write permissions. Over time, the backup job gets extended to also verify backups, so verify permissions are added. Then the backup job is extended to trigger alerts on failure, so alerting permissions are added. Then the backup system itself is rewritten and no longer needs the original service account, but the account is retained “just in case,” with all of its permissions intact, because decommissioning it feels riskier than leaving it alone.

Ten years of this pattern produces service accounts with permission sets that look like a museum of every use case the account ever had. The current use case might be 10% of the total permissions held. The other 90% are archaeological.

In the event of a credential compromise, the attacker gets the whole museum. The attacker doesn’t care that only 10% is currently justified. The attacker takes advantage of the full set.

the ownership vacuum

The biggest single problem with non-human identities in most environments is that nobody owns them.

A human account is owned by the human. The human’s manager has some secondary ownership. When the human leaves, the manager is notified and makes decisions about the account.

A service account has no human attached. It was created by an engineer, but the engineer may have left. The team that “owns” it may have been reorganized three times. The automation it supports may have been inherited by a different team, or may have been rewritten in a way that doesn’t actually use the service account anymore.

In practice, a large fraction of service accounts in mature environments have no identifiable owner. The name on the account is the name of the engineer who created it, which may or may not map to a current employee. The Slack channel that supposedly owns the system it supports has been archived. The wiki page documenting its purpose is three years out of date.

When nobody owns the account, nobody is responsible for maintaining it, which means rotations don’t happen, reviews don’t happen, decommissioning doesn’t happen. The account enters a steady state of being perpetually alive and perpetually unmonitored. It does its job, year after year, without anyone noticing.

If the account is compromised, the incident response team has to figure out, on the fly, what the account does, what it should have access to, and what would break if it were disabled. The answers to those questions are unknown in real time, because they were never documented, and the person who would have known is no longer at the company.

what good looks like

The pattern for actually managing non-human identities well is known and has three main moves.

Every non-human identity gets a named human owner. The owner is a current employee, not a departed one. When the owner leaves, the account is flagged for re-ownership. An account that can’t be re-owned within a fixed window is a candidate for disablement.

Every non-human identity has a declared purpose, stored in a place that the current team can find. Ideally the purpose is in the metadata of the account itself, or in a linked registry. When someone audits a service account, the first question, “what does this do?”, should have a trustworthy answer on the first query.

Every non-human credential has a rotation cycle, enforced technically. Short-lived credentials are better than long-lived ones. Automated rotation, wired into the secrets management infrastructure, is better than manual rotation. The goal is that any credential issued today has a maximum lifetime measured in days or weeks, not years.

None of these moves is technically difficult. All of them are operationally expensive, because they require the company to acknowledge that service accounts are a first-class identity category deserving of the same lifecycle hygiene as human accounts. Most companies have not acknowledged this. Most companies are still operating on the assumption that service accounts are a low-risk technical detail, rather than the largest identity population in the environment.

what a service account's life should look like

1. 1created with an owner and a purposeOne named person, one sentence on what it's for.
2. 2scoped to that jobOnly the permissions the workload uses today.
3. 3credentials that expireShort-lived keys or tokens, rotated automatically.
4. 4reviewed on a scheduleOwner confirms it's still needed and still the right size.
5. 5retired with the workloadWhen the job ends, the identity ends with it.

the exercise that will embarrass you

Here is the audit that will produce the most actionable list you’ve run this quarter.

Pull every non-human identity in your primary cloud provider. For AWS, that’s IAM roles, IAM users, and cross-account roles. For GCP, service accounts across all projects. For Azure, service principals and managed identities. Export this to a spreadsheet.

For each identity, pull three data points: the last time the identity authenticated (or for roles, the last time it was assumed), the current permission set, and the creator (where available).

Sort by last authentication, oldest first.

Everything that has not authenticated in more than 90 days is a candidate for disablement. It is actively doing no work. The risk of disabling it is bounded by “maybe something breaks and we turn it back on.” The benefit of disabling it is permanent.

For everything that has authenticated recently, sort by permission scope. The identities with the broadest permissions, admin access, write access to multiple services, cross-account roles, are the ones that warrant the most scrutiny. Review each one against the declared purpose. If the permissions exceed the purpose, reduce them.

For identities created by employees who have left the company, reassign ownership to a current employee or disable the identity. No identity should be owned by a departed person.

You will, in most environments, find a double-digit percentage of your non-human identities are in one of these three categories: dormant, over-permissioned, or orphaned. That percentage is the surface you’ve been carrying without seeing.

The human accounts at your company are monitored because humans notice when something changes. The non-human accounts are not monitored, because nothing notices. The compromise that uses a service account credential is the compromise that has the longest dwell time, because there’s no human behavior pattern to deviate from, the account was always running scripts at odd hours, and the attacker is just running more.

The first identity review every security program does is on the human population. The identity review that would actually reduce your risk surface is on the population three to ten times larger that nobody is looking at.

Run that one next.