The Non-Human Identity Lifecycle

Quick answer
The lifecycle has six stages: request, issuance, use, rotation, review, and revocation, with decommission as the final state.
Most teams have issuance and use, and little else, which is why credentials accumulate without owners.
Every identity needs an owner, a purpose, a scope, and an expiry at creation, or none of the later stages can be enforced.
Rotation without revocation leaves old credentials valid; review without disable rights changes nothing.
The lifecycle should be enforced by the platform where possible, because a policy document does not revoke anything.

What are the stages of the NHI lifecycle?

Request: someone states what the identity is for and who owns it. Issuance: the platform creates the identity and credential with a scope and an expiry. Use: the workload authenticates, and the platform records last-used time and source. Rotation: the credential is replaced without changing the identity. Review: an owner confirms the identity and its scope are still needed. Revocation: access is removed and the credential is invalidated.

Decommission is the end state, and it is the stage most often missing. An identity whose service no longer exists should be removed, not merely unused. Without that step, the inventory only grows, and the review becomes a search for needles in an ever-larger haystack.

What should be recorded at creation?

Owner, purpose, environment, scope, expiry, and where the credential is stored. These fields are the minimum that makes later automation possible: expiry drives rotation, owner drives review, and storage location drives revocation. If the provider supports tags or descriptions, use them so the metadata lives with the identity rather than in a spreadsheet.

Record the consumer as well. Knowing that a credential belongs to the payments service is useful; knowing which deployment and which repository consume it is what lets you revoke safely. A credential with no known consumer cannot be removed without risking an outage, so it stays forever.

How do rotation and review actually work?

Rotation creates a new credential, deploys it, verifies use, then revokes the old one. The overlap must be short and monitored, and the old credential must actually be revoked rather than left to expire. Rotation that only adds a new key doubles the number of valid credentials until someone cleans up.

Review is a decision, not a report: keep, reduce, or revoke. Each identity gets a decision from its owner within a deadline, and no response defaults to revoke or disable. That default is what makes the process converge. Reviews that default to keep produce the same list every quarter.

Minimum record per non-human identity
  id / credential reference
  owner (person or team)
  purpose (service + environment)
  consumer (repo, workload, deployment)
  scope (resources + actions)
  issued_at / expires_at / last_used_at
  storage (secrets manager path, CI variable, KMS)
  review_due / decision

How do you enforce it without a manual process?

Push as much as possible into the platform: maximum credential lifetime, automatic expiry, required tags, deny-by-default role assignment, and alerts on unused credentials. A policy that a credential expires after ninety days is enforced only if the provider refuses to issue a longer-lived one.

For the parts the platform cannot enforce, use a small scheduled job: list identities missing an owner, missing an expiry, or unused for a threshold, and open a ticket against the owner. The job is more reliable than a quarterly meeting, and it produces a record of what was decided.

Where this bites vibecoders
AI-assisted setup creates identities as a side effect: a database user here, a cloud key there, a platform token during a deploy. None of them arrives with an owner field filled in. A single rule — every new credential is tagged with the service and a person before it is used — prevents most of the lifecycle debt.

Where AI coding assistants get this wrong

Creating credentials without recording an owner or purpose.
Rotating by adding a new key and never revoking the old one.
Running reviews that default to keep when nobody responds.
Issuing credentials with no maximum lifetime because the provider allows it.
Forgetting to decommission identities when a service is removed.
Tracking lifecycle data in a spreadsheet that nobody updates.

Checklist

Require owner, purpose, scope, and expiry at creation.
Set a maximum credential lifetime in the platform.
Alert on credentials unused for 90 days.
Rotate with a short monitored overlap, then revoke the old key.
Default to revoke when an owner does not respond to review.
Decommission identities when their service is removed.

FAQ

How is this different from secrets management?

Secrets management stores and injects credentials. The lifecycle is broader: it covers who requested the identity, what it may do, when it is reviewed, and how it is removed. A secrets manager is one stage’s tool, not the whole process.

Who should own a non-human identity?

The team that operates the workload, not the security team and not the person who created the credential. Ownership must survive staff changes, so a team or a role is better than an individual. The owner’s job is to answer the review question, not to hold the secret.

What is a sensible maximum credential lifetime?

It depends on the credential type: minutes for workload tokens, days for CI credentials, and a bounded period for static keys where the provider offers nothing better. The principle is that the lifetime should be no longer than the interval at which you can reliably rotate and verify.

Do short-lived credentials remove the need for review?

No. They reduce the window of exposure, but an identity that no longer needs its permissions still has them every time it requests a token. Review covers scope and necessity; short lifetimes cover leakage. The two controls address different failures.