The Lifecycle of a Service Account Nobody Owns

Human accounts have a lifecycle everyone understands: someone is hired, gets access, changes roles, and is offboarded. Service accounts — the non-human identities that let software talk to software — are supposed to have one too. In practice, theirs is a story that starts in a hurry and never ends.

What a service account is

A service account is an identity used by a program rather than a person: a script that pulls a report at midnight, an app that reads a database, a CI job that deploys code, an integration that syncs two systems. It needs to authenticate, so it has credentials — a password, an API key, a certificate, or a token. Unlike a human, it doesn't have a phone for MFA and doesn't sit at a keyboard; it just presents its secret and acts.

That makes service accounts powerful and quiet. They often hold broad, standing access, and they never log in from a suspicious location because they don't "log in" in the human sense at all.

The lifecycle, as it's supposed to go

1. Creation. Someone needs system A to talk to system B, so they create an account, give it credentials, and grant it permissions.
2. Scoping. Its access should be the minimum required for its job, and no more.
3. Operation. It runs, authenticating with its secret.
4. Rotation. Its credentials are rotated periodically, so a leaked secret has a short useful life.
5. Ownership. A specific human or team owns it — knows it exists, what it does, and whether it's still needed.
6. Decommission. When its purpose ends, it is disabled and removed.

Where it actually breaks

Every step above is where reality diverges, and the divergence is predictable:

• Created in a hurry, over-permissioned. Under deadline, the easy path is to grant broad rights so the integration "just works." Scoping is meant to be tightened later. It rarely is. The account keeps standing access far beyond its real need.
• The secret is hardcoded. The credential gets pasted into a script, a config file, a repository, or a network share — because that's the fast way to make it run. Now the secret is copyable by anyone who can read that file.
• Never rotated. Rotating a service account's secret means finding every place that uses it and updating them in lockstep, with downtime risk. So it doesn't happen. The same credential lives for years.
• The owner leaves. The person who created it changes teams or leaves the company. The account keeps running. Now no one knows what it's for, whether it's safe to touch, or whether it's still needed — so no one touches it.
• Never decommissioned. Because no one owns it and no one is sure it's unused, it is never removed. It sits there: privileged, with a stale secret, watched by nobody.

The end state is the dangerous one. A powerful identity, with broad access, whose credential is old and possibly sitting in a file, that no human is accountable for and no monitoring is aimed at. It is the softest target in the environment precisely because it fell out of everyone's attention.

What good looks like

The fixes are unglamorous and continuous, which is why they get skipped:

• Inventory. Maintain a list of service accounts: what each is for, what it can reach, and who owns it. You can't manage what you can't see.
• Least privilege, enforced over time. Scope tightly at creation and review scope on a schedule, not just at birth.
• No static secrets where you can avoid them. Prefer short-lived, brokered credentials issued on demand, so there's nothing durable to hardcode or leak.
• Rotation you've practiced. Make rotating a service account's secret a known, rehearsed operation, not a feared one.
• A named owner, always. Every service account has a human or team accountable for it. When that person leaves, ownership transfers as part of offboarding — the same way their human access does.
• An end date. Give integrations and their accounts a decommission trigger, and actually retire the ones whose purpose is gone.

The takeaway

A service account isn't a fire-and-forget convenience; it's a standing identity with real power and no instinct for self-preservation. Its whole lifecycle — scope, rotate, own, retire — is day-2 work that no product does for you. Skip it, and you don't get a small problem later. You get a forgotten, over-privileged credential that an attacker will find before you do.