The identities nobody is watching

When you picture "user accounts," you picture people. But open up any modern environment and the people are the minority. Behind every human login sits a crowd of non-human identities — service accounts, API keys, CI/CD tokens, OAuth grants between SaaS tools, deploy bots, monitoring agents — and they typically outnumber human users several times over. They authenticate constantly, often with broad privileges, and almost none of them have what every human account gets: an owner, an expiry, MFA, and a credential that ever changes.

That asymmetry is the gap. You run access reviews on people, enforce MFA on people, and offboard people when they leave. Meanwhile a service account created for a one-off integration three years ago is still live, still holding a production key, still owned by an engineer who left last spring. Non-human identities are where least privilege quietly stops applying — and attackers have noticed.

Why machine identities are the harder problem

A non-human identity isn't just a user account without a face. The properties that make it useful are exactly the ones that make it dangerous:

  • They rarely expire. A person leaves and someone (hopefully) offboards them. A service account is forever — created for a project, never decommissioned when the project ends, accumulating into a population of orphaned credentials nobody can account for.
  • They're over-permissioned by default. Granting a token exactly the access it needs is fiddly, so people grant it broad or wildcard permissions "to make it work" and never tighten them. An over-privileged machine identity is an asset with a blast radius far larger than its job.
  • They usually can't do MFA. A bot can't tap a phone prompt, so its security rests entirely on a static secret — a key or token that, once stolen, grants access with nothing standing in the way.
  • They're owned by no one. The most common finding in any machine-identity review is a service account nobody can name an owner for. An ownerless credential is one nobody rotates, nobody reviews, and nobody will notice being abused.

The risk isn't theoretical. A leaked CI token or a hard-coded API key is one of the most direct paths into a modern environment — no phishing, no malware, just a valid credential found in a repo, a log, or a misconfigured cloud bucket. And because the identity is "supposed" to be making automated calls at odd hours, the abuse blends right into normal traffic.

Bring them into the same discipline as people

The fix isn't a new product category — it's applying the access hygiene you already practice on humans to the identities you've been ignoring:

  • Inventory them. You cannot govern what you cannot see. Every service account, API key, and token belongs on the asset inventory alongside human identities — this is the attack surface you've been omitting because it doesn't have a face.
  • Give every one an owner. A named human accountable for each machine identity is the single highest-leverage step. The owner answers "is this still needed, and is its access still right?" — and an identity with no answer to that question is a finding.
  • Scope to least privilege. A token should get exactly the access its job requires and no more, so a leaked credential lands in a broom closet rather than a vault — the same blast-radius logic that governs human least privilege.
  • Rotate and expire on a schedule. Static credentials that live forever are the core problem; short-lived, automatically rotated tokens are the cure. Where a system supports it, prefer ephemeral credentials over long-lived keys, and treat rotation as part of routine secrets management, not an emergency.
  • Monitor for anomalies. A service account suddenly used interactively, calling from a new region, or reaching systems it never touched before is one of the clearest signals in your log and detection pipeline — because a bot's behavior is predictable, deviation is loud.

They belong in the program, not beside it

A machine identity that's over-permissioned, unowned, or never rotated is a finding like any other — routed to an owner with a severity and a deadline, ranked by what it can reach, using the same exposure-first triage as the rest of your work. And the population drifts constantly: a new integration mints a token, a deploy pipeline creates a service account, an engineer leaves and their personal access token keeps working. "What fraction of our non-human identities have an owner, least-privilege scope, and a rotation schedule?" is a measured dimension of your posture score, not a one-time cleanup.

It feeds the audit, too. Frameworks increasingly expect that all access — human and machine — is governed: SOC 2's access controls, ISO 27001's identity and key-management requirements. A current inventory of service accounts with owners and rotation status is exactly the evidence an assessor wants, and it drops into the same continuous-verification loop as everything else.

One honest caveat: a platform can inventory your non-human identities, surface the ones missing an owner, least-privilege scope, or rotation, and keep that evidence current for an auditor — it organizes, tracks, and proves the work. It does not create, scope, rotate, or revoke your tokens and service accounts, make you compliant, or grant or guarantee any certification; the actual provisioning and rotation are operational steps your team owns, and which obligations apply is a question for counsel.

Your environment is mostly run by identities that aren't people — and they outnumber your team, never expire, and rarely rotate. Bring them into the same discipline you already apply to humans: inventory them, give each an owner, scope them tight, rotate them, and watch them. The credential nobody owns is the one an attacker is hoping you forgot.