The non-human identity lifecycle.

The four-stage lifecycle

Every non-human identity, regardless of type, passes through the same four stages. The stages are not always clean or well-demarcated; an NHI can skip provisioning formalities and go straight from "someone wrote a script" to "in production." But conceptually, these four stages are the frame against which lifecycle controls are designed.

Stage 1, Discovery

Discovery is the act of identifying that an NHI exists. In a mature programme, discovery happens at the point of creation: an engineer creates a service account, the provisioning system records it, the inventory updates in real time. In a reactive programme, discovery is retroactive, a scanning tool sweeps the environment and surfaces NHIs that nobody is currently tracking.

The gap between these two modes is where "shadow NHIs" accumulate. An engineer needs a quick integration for a POC, creates an API key in GitHub, puts it in a config file, and moves on. The integration outlives the POC, and the NHI outlives anyone's awareness of its existence. Discovery sweeps find these retroactively, but by then they've often been live for months.

Discovery sources to cover

• Directory services (Active Directory, Entra ID, LDAP, local Unix accounts)
• Cloud IAM (AWS IAM roles/users, Azure service principals/managed identities, GCP service accounts)
• Kubernetes (service accounts and their tokens, bound cloud identities via workload identity)
• SaaS tools (OAuth applications, integration users, admin API tokens)
• CI/CD systems (GitHub Actions, GitLab CI, Jenkins)
• Secret stores (Vault, AWS Secrets Manager, cloud KMS, Akeyless, Doppler)
• Developer tools (personal access tokens in GitHub/GitLab/Atlassian)
• Database service accounts and database-native users
• Certificate inventories (PKI, Let's Encrypt, internal CAs)

Stage 2, Provisioning

Provisioning is where the NHI is brought into existence, credentials issued, permissions assigned, ownership recorded. Three decisions at provisioning time shape the identity's entire risk profile:

1. What authentication mechanism? Static password? Long-lived API key? Short-lived token? Certificate? Workload identity federation? The further right on this list, the better the risk posture.
2. What permissions? Broad admin for convenience, or narrowly scoped to the exact task? Right-sizing later is harder than starting right.
3. Who owns it? An individual, a team, or no-one? Individual ownership fails on employee turnover; team ownership requires the team itself to outlive the NHI.

A mature provisioning pattern enforces all three at creation time: workload identity where possible, narrow permissions by default, and no creation without a nominated owner. Each of the three is a policy-as-code gate in modern infrastructure.

Stage 3, Operation

Operation is the longest stage, often years. During operation, the NHI authenticates, performs actions, and generates logs. The controls that matter during operation:

• Credential rotation. On schedule, not just when exposure is known. Automated rotation is the only rotation that scales.
• Periodic access review. Does the NHI still need what it has? Has its permission scope drifted? Who is the current owner?
• Behavioural monitoring. Does the NHI's behaviour this week match its behaviour last month? Unusual geographies, unusual APIs, unusual volume all warrant a look.
• Health checks. Is the NHI still in use? An NHI that has not authenticated in 90 days is a decommissioning candidate.

Stage 4, Decommissioning

Decommissioning is the stage where the NHI's credentials are revoked, its permissions are removed, and the identity record is archived. In a well-run programme, decommissioning is completed within days of the event that triggered it. In most programmes, decommissioning is incomplete or never happens.

The reason is simple and hard to fix: there is usually no natural trigger. A human leaves the company, HR fires an event. An application is retired, nobody fires an event. An integration is removed, nobody fires an event. The NHI lives on because nobody remembered to kill it.

Why offboarding is the stage that fails

Microsoft's Storm-0558 breach is the canonical orphaned-NHI case: a Microsoft Services Account signing key from 2016 was used in 2023 to forge authentication tokens for 60,000 US State Department emails. Between 2016 and 2023, the key should have been rotated, then retired. Seven years is a long time for an identity to live past its useful purpose.

The pattern is architectural:

• NHIs are created for purposes (integrations, applications, scripts).
• Purposes end.
• The end of a purpose does not produce a signal that can be acted upon.
• Without a signal, decommissioning depends on memory.
• Memory degrades with time and employee turnover.

Event-driven offboarding, the fix

The way out of this is to generate the signals that the architecture doesn't naturally produce. Pragmatic triggers that mature programmes use:

The pattern is always the same: connect a pre-existing signal (an HR event, a CMDB field change, a log gap) to an NHI action (flag for review, rotate, retire). This requires integration work but turns decommissioning from a memory problem into a workflow problem.

Controls by lifecycle stage, quick reference

• Discovery: continuous auto-discovery, inventory reconciliation across all source systems, shadow-NHI scanning.
• Provisioning: owner-required creation, permission-boundary enforcement, workload-identity-by-default, naming conventions.
• Operation: scheduled credential rotation, quarterly access review, behavioural baselining, activity monitoring.
• Decommissioning: event-driven retirement triggers, inactivity-based retirement, credential revocation verification, archival with audit trail.

Frequently asked questions

What is the non-human identity lifecycle?

It is the sequence a non-human identity passes through from creation to retirement: request and justification, provisioning with a scoped credential, assignment of an accountable owner, periodic review and recertification, credential rotation, and finally decommissioning. Unlike the human joiner-mover-leaver lifecycle, none of these stages is triggered automatically by an HR system, which is why NHIs accumulate and why lifecycle management has to be designed deliberately.

How is NHI lifecycle management different from human identity lifecycle management?

Three differences dominate. There is no authoritative source of record equivalent to an HR system, so creation and retirement have no natural trigger. There is no manager, so accountability has to be assigned rather than inherited. And the scale is different by one or two orders of magnitude, so processes that work when a human reviews 1,000 identities annually do not survive 100,000 machine identities. Access-review concepts extend; the trigger model does not.

Can non-human identity lifecycle management be automated?

Discovery, credential rotation, expiry enforcement and decommissioning of unused identities can all be automated, and should be. Ownership attribution and the decision about what an identity is allowed to do cannot be fully automated, because both are judgements about business intent. In practice the automatable portion is large but it sits on top of an ownership model that has to be established by people first.

What is the hardest stage of the NHI lifecycle?

Decommissioning, and by a wide margin. Creating an identity has a requester and a deadline; retiring one has neither, and the person who would know it is safe to remove has usually left. This is why orphaned identities belonging to departed staff appear in almost every audit, and why bounded credential lifetimes are so effective: expiry forces a retirement decision that nobody would otherwise make.

How often should non-human identities be reviewed?

Tie the interval to blast radius rather than applying one cadence uniformly. Identities that can write to production data or that cross a boundary into a third party warrant quarterly review; low-privilege internal identities can reasonably run annually. The interval matters less than whether the review results in executed revocations, which is the evidence an auditor will actually test.

What triggers offboarding for a non-human identity?

In a mature programme, four triggers: the owner leaving the organisation, the identity going unused past a defined threshold, the credential reaching expiry without renewal justification, and the decommissioning of the system it served. Most organisations implement none of these, which is why the practical starting point is usually expiry-driven retirement rather than event-driven offboarding.