Non-Human Identity Lifecycle: Stages, Owners and Controls

The non-human identity lifecycle is the process of discovering, approving, issuing, monitoring, changing and retiring identities used by software rather than people. An effective lifecycle assigns an accountable human to each identity, limits its permissions and preserves evidence that access was reviewed and eventually removed. It covers service accounts, application principals, workload identities, automation bots and their associated credentials.

A secret isn't the same thing as an identity. An application might keep its service principal while a certificate changes, or it might obtain a temporary token without storing any long-lived key. Treating every credential rotation as a new identity creates duplicate records. Focusing only on secrets misses access grants and orphaned service principals that hold no secret at all. The lifecycle must track both, but it shouldn't confuse them.

What are the stages of the non-human identity lifecycle?

The non-human identity lifecycle has six practical operating stages: discover, authorize, provision, operate, change and retire. Those stages aren't a universal standard. They're an actionable way to assign controls and evidence to work that otherwise gets split across cloud IAM, SaaS administration, DevOps and security teams.

Stage	Trigger	Accountable role	Minimum evidence	Exit condition
Discover	New workload, scheduled reconciliation or alert	Identity governance lead	Identity ID, source system, workload and owner	Inventory record linked to real source
Authorize	New identity or access request	Application owner and access approver	Purpose, scope, expiry and approval	Least-privilege access approved
Provision	Approved deployment	Platform or system administrator	Provisioning record and credential method	Workload authenticates as intended
Operate	Identity in active use	Workload owner	Usage logs, review date and health signals	Access remains justified
Change	Release, incident, owner move or secret expiry	Workload owner and platform team	Change ticket, rotation test and revised permissions	New state tested and recorded
Retire	Workload shutdown or purpose ends	Workload owner with system administrator	Disable test, revocation proof and closure approval	No residual access remains

Some frameworks combine authorization with provisioning or treat rotation as its own stage. That isn't a disagreement about the control objective. What matters is whether every change has a named owner, a technical executor and evidence of the resulting state. OWASP's Non-Human Identities Top 10 explicitly identifies improper offboarding and secret leakage as risks, which is why retirement and credential handling can't be afterthoughts. The OWASP NHI Top 10 lists them as NHI1:2025 and NHI2:2025.

A lifecycle isn't complete because a dashboard shows green. A successful close means the underlying system agrees with the record, the affected workload's been checked and someone with authority accepted the result. Your inventory's a control ledger, not just a list of usernames.

Which objects belong in the inventory?

The inventory should represent the identity, the credentials it uses and the access it holds as related but distinct objects. A single workload can have several identities across cloud accounts and SaaS applications. A single identity may have multiple credentials during a safe rotation. Each access grant needs its own scope and review decision.

Object	Example	What you track	What can change independently
Workload	Billing export job	Repository, environment, business purpose, runtime	Owner, deployment, shutdown
Identity	svc-billing-export-prod	Provider ID, principal type, creation event	Role grants, active status
Credential	Client certificate or API key	Secret reference, issuer, expiry, rotation state	Value, expiry, revocation
Entitlement	Read access to billing bucket	Resource, action, condition, approver	Scope and permission
Human accountability	Billing platform owner	Named primary and backup, review due	Team transfer or departure

Don't put passwords, tokens or private keys into a spreadsheet. Store a vault reference or a provider-side identifier instead. The register should answer where the credential lives, not reveal it. A secret's identifier can be sensitive too, so limit who can export the register and avoid copying it into public tickets.

Identity versus credential example: A nightly export runs as a Microsoft Entra service principal and authenticates with a certificate. When the certificate's replaced, the principal and its role grants might stay unchanged. The credential record changes and the rotation evidence is updated. If the export's retired, both the principal's access and any remaining credentials must be addressed. A certificate-only cleanup wouldn't close the identity's lifecycle.

How do you discover and assign ownership to existing identities?

Discover existing identities by reconciling authoritative cloud and SaaS exports with workload records, then require a human owner to confirm purpose and dependencies. An unassigned service account isn't proof of compromise, but it's a governance exception that needs an owner or a controlled retirement decision.

1. Collect identity exports

   Export service principals, service accounts, automation users and API integrations from each in-scope system. Record the export timestamp and source.

2. Normalize stable identifiers

   Match by provider object ID and environment, not by display name alone. Keep original identifiers for audit traceability.

3. Connect identities to workloads

   Map repositories, scheduled jobs, hosts, pipelines, SaaS integrations and resource owners. Record uncertain mappings as unresolved.

4. Nominate accountable owners

   Ask application or business owners to accept responsibility. Assign a backup and escalate unclaimed production identities.

5. Reconcile credentials and grants

   Record secret references, authentication method, last observed use and effective permissions without copying secret values.

6. Approve or remediate exceptions

   Document owners, deadlines and evidence for orphaned, overprivileged, stale or duplicate identities.

Cloud providers offer useful starting points but don't give you a cross-platform owner by default. AWS credential reports expose access-key state and last-used fields for IAM users. Microsoft Entra separates service principal sign-ins from managed identity sign-ins. Google Cloud documents service-account usage analysis and recommends disabling unused service accounts before deleting them. These are discovery signals, not final ownership decisions.

A name such as svc-prod-legacy doesn't tell you whether a batch job is still essential. Trace the execution path. Search deployment manifests and scheduled tasks, compare recent authentication with expected schedules and ask the application owner to confirm what'll break if the identity disappears. A monthly job might've shown no activity in a short observation window. Low usage alone isn't a safe deletion rule.

For a reusable owner register, see our service account inventory template and service account ownership matrix. The register below extends those resources with lifecycle state and retirement evidence.

What does a usable lifecycle register look like?

A usable lifecycle register joins the technical identity to an accountable owner, a permission decision and a next action. It needs enough detail to support an access review without exposing credentials. Copy the register below into a controlled spreadsheet or governance system. The example identities and dates are fictional planning data, not observed production assets.

Template

Non-human identity lifecycle register

Copy this into a controlled spreadsheet. Identities, owners and dates are fictional planning data.

Identity ID	Provider	Workload	Environment	Human owner	Backup owner	Auth method	Credential reference	Access scope	Last use observed	Review due	Lifecycle state	Next trigger	Approval evidence	Retirement evidence
svc-billing-export-prod	AWS	Billing export	Production	Billing platform lead	Cloud operations lead	IAM role	None	S3 read for billing export	2026-10-26	2026-11-30	Operate	Quarterly access review	CHG-EXAMPLE-101	Not applicable
app-warehouse-sync	Microsoft Entra	Warehouse sync	Production	Data engineering lead	IT operations lead	Certificate	Vault ref EXAMPLE-02	Read warehouse API	2026-10-27	2026-11-15	Change	Certificate renewal	CHG-EXAMPLE-102	Not applicable
legacy-campaign-hook	SaaS	Retired campaign connector	Staging	Marketing systems lead	Security lead	API token	Vault ref EXAMPLE-03	Webhook integration	Unknown	2026-10-29	Retire	Dependency confirmation	CHG-EXAMPLE-103	Pending disable test

Store credential references only, never secret values.

Use Identity ID as the stable provider identifier or a stable local key linked to that identifier. Human owner is accountable for business need, while Backup owner ensures a transfer doesn't leave the account ownerless. Auth method describes the mechanism; Credential reference points to a managed secret or says none. Access scope names the resources and actions, not a vague label such as admin. Last use observed must include its observation window in the underlying evidence, because missing logs aren't the same as no activity.

The Lifecycle state column should use controlled values: Discover, Authorize, Provision, Operate, Change, Retire and Closed. Next trigger identifies a date or event that forces a decision. Approval evidence links to the authorized grant. Retirement evidence links to a completed disable, revocation or removal check. If your organization needs a separate exception register, connect it by identity ID rather than adding free-text risk narratives to every row.

How should provisioning work for a new workload?

Provision a new non-human identity only after its purpose, owner, environment, required actions and retirement trigger have been approved. The platform team should prefer an identity that's tied to the running workload instead of issuing a reusable secret when the environment supports that pattern.

A production deployment request should state the workload's repository or deployment identifier, its business owner, the resources it needs and the exact actions it performs. Security or the designated access approver checks the proposed scope. Platform engineering creates the identity through a controlled deployment path and returns only the reference required by the workload. The application team tests both successful access and a deliberately denied action.

Prefer a secretless path where it fits. AWS recommends IAM roles and temporary security credentials for many application scenarios rather than persistent access keys. Microsoft Entra supports workload identity federation for supported external workloads. Google Cloud's workload federation guidance explains exchanging external identity credentials for short-lived Google access tokens. SPIFFE offers workload identity documents that can include short-lived X.509 certificates. These mechanisms reduce the need to distribute reusable secrets, but they don't remove the need to review permissions, trust relationships or owners.

A federated identity can still be overprivileged. The workload may hold no static key yet have permission to read an entire storage account. Your approval should examine the principal's entitlements and the trust configuration, not just whether a secret was avoided. For external workloads, check token issuer, subject and audience matching. An overly broad trust condition can undermine an otherwise sound credential strategy.

When a legacy integration genuinely requires an API token, use a supported secret store, scope the token to the integration and define who can revoke it. Record the expiry or review trigger and rehearse how the consuming application receives a replacement. A vault isn't a substitute for an owner.

How do you operate, review and rotate non-human identities safely?

Operate non-human identities through usage monitoring, permission reviews, credential-health checks and controlled changes. Review the identity's business need separately from the credential's age. Rotating a secret doesn't prove that the principal still needs access, and it won't catch an abandoned integration.

A useful review packet contains the stable identity ID, current owner, workloads, access grants, observed use, credential method, last change and requested decision. The reviewer should choose retain, reduce, replace or retire, then sign against evidence. If a reviewer can't identify the workload, it should be escalated rather than silently approved.

For static secrets, OWASP's Secrets Management Cheat Sheet recommends rotation and revocation when a secret is no longer required or may be compromised. The rotation schedule should follow the credential's purpose, provider constraints and organizational policy. Don't copy a universal day count from a cloud compliance rule and apply it to every certificate, OAuth grant and managed identity. AWS Config's access-key rotation rule has a configurable default of 90 days for IAM user keys; that setting isn't a blanket NHI standard.

Safe rotation sequence: identify consumers, create a replacement, distribute it through the approved mechanism, verify successful authentication, observe failures, revoke the old credential and retain the test record. If a provider permits overlapping keys, use that window for a controlled switchover. If it doesn't, plan a maintenance window and rollback path. A rotation isn't complete while the previous credential still works without an approved overlap exception.

Microsoft Entra's service principal sign-in logs can help identify authentication activity by app or principal. AWS provides last-used data for access keys. Neither proves the identity's owner approved the access. Keep the decision record alongside the logs, and define a review cadence based on privilege, change rate and business criticality rather than treating every identity as identical.

What changes when an owner leaves or an application is redesigned?

An owner departure or application redesign should trigger an identity reassessment even if the credential hasn't expired. Non-human identities often outlive the engineer who's created them. The right response is to reassign accountability, recheck entitlements and decide whether the workload still needs the identity.

Use an explicit handoff. The departing owner's manager identifies the replacement application owner. The new owner confirms purpose and dependent workloads. IT checks the current permissions, and security reviews any elevated or unexplained grants. The transfer record should include the new owner, acceptance date and unresolved exceptions. Simply changing the contact email doesn't prove that anyone accepted responsibility.

A platform migration deserves similar treatment. When a job moves from a long-lived key to a managed identity, the team should create the new trust relationship, validate application behavior and retire the old credential and its unnecessary principal. Keep both identities visible during the migration so that access doesn't disappear from the inventory while the old route remains usable.

For AI agents, track the runtime principal, the agent's delegated authority and the human or team accountable for its deployment. An agent that calls an external tool shouldn't inherit blanket privileges merely because the orchestration service has them. Review the tools, scopes and delegation chain as part of each material change. The agent's prompt or display name isn't a reliable security boundary.

How do you retire a non-human identity without breaking production?

Retire a non-human identity by confirming dependencies, stopping new use, disabling or revoking access, watching for failures and only then deleting what can safely be removed. Retirement must address the principal, its credentials, grants and downstream integrations. Deleting a vault secret alone may leave a valid account with another authentication path.

1. Confirm the retirement trigger

   Record the decommissioned workload, ended vendor integration or approved replacement and name the owner who authorized retirement.

2. Map dependent consumers

   Check jobs, pipelines, runtime configuration, third-party connections and usage history. Treat incomplete telemetry as a reason for more validation.

3. Prepare rollback and communications

   Schedule the change, record the restoration owner and define observable failure signals before disabling access.

4. Disable or revoke access

   Disable the account or credential using provider-supported controls. Capture the resulting state and change ticket.

5. Observe the expected workload cycle

   Check service health, authentication errors and downstream handoffs across the relevant run schedule.

6. Remove residual grants and close

   Delete or permanently revoke when safe, update inventories and attach proof of removal and owner approval.

Google Cloud explicitly recommends disabling a service account before deletion and waiting at least 24 hours to watch for unintended consequences. That's a provider-specific recommendation, not a universal safe waiting period. A weekly payroll export or quarterly integration may require a longer observation window. The owner must decide based on the workload's actual schedule.

OWASP's NHI Top 10 lists improper offboarding as NHI1:2025. A retired service account with standing privileges isn't harmless simply because nobody remembers using it. Record the final state in the source platform, confirm that related secrets and grants were removed and close the exception only when evidence supports it.

Incident exception: If a credential's suspected to be compromised, don't wait for the normal retirement observation window. Follow incident-response procedures to contain access, rotate or revoke affected credentials and investigate dependent systems. Restoration and evidence retention should be coordinated with the incident commander. Normal change management shouldn't delay containment.

Who owns each lifecycle control?

Each non-human identity needs a human accountable for its business purpose and a technical team able to enforce changes. Security defines guardrails and independently reviews exceptions, but it shouldn't become the default owner of every service account. That'd make approval easier on paper while weakening knowledge of the actual workload.

Control	Accountable	Responsible executor	Reviewer or consulted team
Business purpose and retirement trigger	Application owner	Workload team	Security
Permission request	Application owner	IAM or platform administrator	Access approver
Credential issuance and rotation	Platform lead	Secrets or cloud operations team	Application owner
Usage anomaly response	Security incident lead	SOC and workload team	Platform owner
Owner transfer	Application manager	IT governance	New owner
Decommission approval	Application owner	System administrator	Security or change approver
Evidence retention	Control owner	Governance operations	Audit or compliance

A small IT team may combine execution roles, but it shouldn't let the same person silently request, approve and attest privileged access without a documented compensating control. The aim isn't an elaborate RACI chart. It's a clear answer, backed by proof, to the auditor's simplest request: show who decided this identity was necessary.

What should IT teams measure in a lifecycle program?

Measure non-human identity lifecycle quality with coverage, owner accountability, overdue reviews, residual access and time to revoke. Raw identity count alone isn't a useful success metric. A shrinking count can conceal a blind spot if discovery coverage also shrinks.

Metric	Calculation	Why it matters
Owner coverage	Identities with accepted owner / identities inventoried	Reveals accountability gaps
Workload linkage	Identities tied to a verified workload / identities inventoried	Separates known purpose from guesswork
Review completion	Reviews completed with evidence / reviews due	Tests the operating control
Overprivilege exceptions	Open grants exceeding approved scope	Prioritizes permission reduction
Retirement closure	Approved retirements with verified removal / retirements due	Finds residual access
Credential exceptions	Active static credentials outside policy	Tracks unresolved secret risk

Use the same denominator definition each period. If a scanner adds a new cloud account, the owner-coverage percentage may fall even when the team improved its process. That's useful information, not necessarily a failure. Report discovery scope beside each metric and distinguish unknown from zero. Don't call an account inactive because your logging window missed its execution schedule.

For an initial implementation, focus on production identities with high privileges, unknown owners or evidence of unused access. Build the register, clear the most serious exceptions and integrate owner assignment into new provisioning. Then expand discovery and automate evidence collection. The order's a pragmatic rollout choice, not a compliance deadline.

What are common lifecycle mistakes?

The most damaging lifecycle mistakes confuse identity with credential, assign no owner and retire access without testing dependencies. They can produce either silent exposure or preventable outages.

Rotating without reviewing: A newly issued token can still authorize an abandoned integration. Review whether the identity should exist before approving the next rotation.

Deleting on last-used age alone: Missing telemetry, a quarterly job or an emergency account can make a necessary identity appear dormant. Confirm workload purpose and observe an appropriate cycle.

Counting a vault as governance: A vault can store and rotate secrets, but it doesn't automatically establish who owns the service principal or whether its entitlements are justified.

Reusing shared identities: A shared service account makes it harder to attribute actions and revoke one integration without affecting another. Prefer distinct workload identities where the platform allows them.

Closing a ticket without provider evidence: A change ticket that says “done” isn't proof the account was disabled. Capture the source system's final state and the reviewer decision.

Ignoring the owner lifecycle: When a developer changes teams, their automation may continue to run. Trigger a transfer review rather than waiting for a scheduled annual inventory.

Frequently asked questions about the non-human identity lifecycle

Related identity governance resources

• Non-human identity management best practices
• Service account inventory template
• Service account audit checklist
• Service account ownership matrix