The accounts that own everything and belong to no one

Somewhere in your environment is an account with more privilege than your CTO. It has no second factor. Its password was set during an implementation by someone who no longer works there. It authenticates several times an hour, and nothing alerts when it does, because constant use is exactly what everyone expects from it.

Ask three people what it is for. See how far you get.

The four kinds

Break-glass. Emergency administrative access, deliberately held outside the normal path so a failure of the identity provider does not lock you out of your own environment. Entirely correct to have. Usually created once and never looked at again.

Service accounts. Non-human identities running automation, integrations, scripts and scheduled work. Some were designed. Most started as a convenience and quietly became load-bearing.

Integrations under a personal login. An administrator connects two systems while signed in as themselves. The connection persists, carrying their authorization, long after anyone remembers it was made that way. It is one of the hardest cases to spot because from the outside it can look like an ordinary employee account.

Shared operational credentials. The registrar, DNS, the certificate authority, billing portals, vendor consoles, the mobile carrier account, whatever owns the cloud tenancy. Typically held by two or three long-serving people, often with a recovery address that belongs to one of them personally.

The registrar deserves its own sentence. Control of the domain sits upstream of your email, your authentication, your single sign-on and many of your recovery paths. It can be one of the most consequential accounts in the estate while receiving far less lifecycle attention than ordinary user access.

Why lifecycle cannot see them

This is structural, not sloppy.

Many automated lifecycle rules begin with a person record. Department, employment type, manager, location and title drive what should be created or removed. A non-human identity has no natural employee event behind it, so unless it is deliberately placed into a separate lifecycle, ordinary joiner-mover-leaver automation has nothing to act on.

Access reviews can inherit the same blind spot. Reviews built around people and their managers may exclude non-human identities entirely or leave them in an unmatched bucket that nobody has been made accountable for clearing.

So the population tends to grow. Accounts get added when something needs to work. Removing one requires knowing what depends on it, and that knowledge often disappears long before the account does.

The exemption that never got reviewed

Many of these accounts have been excluded from a control at some point because the control broke the automation or emergency path.

A multi-factor requirement a script cannot satisfy. A conditional access rule that rejects connections from a data center. A rotation schedule that took an integration down at three in the morning. The exclusion resolves the incident, and it is never revisited.

Leave those exceptions unreviewed for years and the combination can become dangerous: high privilege, weaker authentication requirements, no device or location constraint, no interactive user who would notice something odd, and little useful alerting because regular use is expected by design.

Some of those exclusions are legitimate. Break-glass access is meant to work when the identity provider does not. The problem was never the exemption. It is an exemption with nothing attached to it.

Four ordinary disasters

The integration that leaves with its creator. An administrator departs, offboarding runs correctly, a pipeline stops. Or worse, offboarding gets softened to avoid the outage, and a departed person's authorization stays live indefinitely.

The credential nobody dares rotate. The password is known to be old. Nobody can enumerate what depends on it. Rotation gets deferred, then deferred again, until the age of the credential is an audit finding rather than a decision anyone made.

The break-glass account that has never been opened. Untested since creation. When it is finally needed, the password sits in a vault reachable only through the authentication path that is currently down, or a factor is registered to a retired phone, or a dormancy cleanup disabled it eleven months ago.

The registrar with a personal recovery address. The person who set it up has left. Recovery runs through a mailbox nobody controls. What should be a support ticket is now a legal exercise, and your domain is the thing being negotiated over.

Ownership is the control

The instinct is to reach for tooling. Vaults, secret managers, workload identity, short-lived credentials. All useful, several of these problems have proper technical answers, adopt them.

But the failure here was not that a credential was stored badly. It was that no named human was accountable for the account existing, so nobody was ever responsible for asking whether it still should.

Ownership is not operation. The owner is accountable for the account being justified, scoped and current. Usually a team lead or system owner, not the engineer whose script happens to call it. It has to be a named individual, because assigning it to a team is a way of assigning it to nobody.

What follows from that:

• Non-human accounts are named for their function, never after a person, so the name itself tells you what you are looking at.
• Service accounts are prevented from interactive sign-in where the platform supports it, and are scoped to what the automation actually calls rather than handed administrative rights for convenience.
• Integrations are created under a purpose-built identity rather than an administrator's personal account. It is one of the highest-return habits on this list.
• Break-glass access is protected independently of the normal SSO path, monitored on every use, and tested on a schedule that includes the identity provider being unavailable. Dual control can be appropriate in higher-risk environments, but not if it makes emergency access unusable when it is actually needed.
• Every exemption from a security control is recorded with its reason, its compensating control, an owner and a review date.

The register

The deliverable is a list, and it is usually worth more than any change you make afterwards, because most of the remediation becomes obvious the moment the list exists.

For every non-human and shared account: what it is, what it is for, what depends on it, what privilege it holds, where the credential lives, how it rotates and when it last did, what controls it is exempt from and why, whether its use is monitored, who owns it by name, and when someone last confirmed it is still needed.

Those last two fields are the ones that keep the list alive. Everything else describes today. Those two decide whether anyone opens the file again.

The check worth running

Pick the automation your business would notice fastest if it stopped. Ask whose credential it runs as.

If the answer is a person, ask what happens when they resign. If the answer is a service account, ask who owns it, when its credential last changed, and what would alert if somebody else used it tonight.

Explore this expertise: Identity & Access Management

All technical notes