NHI Lifecycle Automation: Request to Retirement

Service accounts, API keys, app registrations and workload identities are still created by hand, rotated when someone remembers and retired almost never, which is why long-lived, ownerless machine credentials keep turning up in breaches. Human identities have had joiner, mover and leaver automation for years; non-human identities mostly have tickets. This guide shows how to run the whole NHI lifecycle as a workflow: a request with an owner and purpose, policy-checked creation, automatic rotation, periodic recertification and automated retirement, with platform guardrails in Entra ID, AWS, Google Cloud and secrets managers that stop people working around it. It is for IAM, platform engineering and cloud security teams. Stage-specific depth is in the NHI Offboarding and Decommissioning Guide and the AI Agent Credential Lifecycle and Rotation Guide.

Key takeaways

Make the workflow the only door. Automation helps only if platform policies block the manual route: no client secrets in Entra, no service account keys in Google Cloud, no IAM users with access keys in AWS outside the pipeline.
Capture owner, purpose and expiry at request time. These three fields drive every later stage, from rotation to recertification to retirement.
Prefer credentials that need no rotation. Managed identities, workload identity federation and dynamic secrets with short leases remove whole stages of the lifecycle.
Rotation must be tested, not just scheduled. A rotation that is not verified by the consuming application turns into an outage or a silent rollback.
Retirement is triggered by events, not audits. Owner leaves, project ends, last use older than the threshold, or expiry reached: each should start a workflow automatically.

The lifecycle as a workflow

Stage	Trigger	Automated steps	Evidence produced
Request	Service catalogue form, pull request or API call	Validate owner exists and is active, purpose and environment given, permissions chosen from approved roles, expiry set	Request record with approver
Approve	Request submitted	Auto-approve low-risk templates; route privileged or production requests to owner's manager and security	Approval decision and reason
Create	Approval	Infrastructure as code creates the identity with standard name and tags, binds roles, issues the credential straight into a vault or uses federation	Identity ID, tags, credential reference (never the value)
Rotate	Schedule or event (leak, owner change, incident)	Generate, deploy, test, promote, revoke old version	Rotation log with test result
Recertify	Every 90 to 365 days by risk tier	Owner confirms need, permissions trimmed using last-used data	Attestation record
Modify	Owner change, permission change request	Re-run approval for added rights; transfer ownership	Change record
Retire	Expiry, owner leaver, inactivity, project closure	Disable, wait, revoke credentials, delete, remove from inventory	Retirement record

Use a single naming and tagging scheme so automation can find owner, environment and expiry on any platform. See the Machine Identity Naming and Tagging Standard Template and NHI Ownership Guide.

Minimum fields in the request record

Field	Why automation needs it
Named human owner and backup owner	Recertification, leaver-triggered transfer, incident contact
Purpose and consuming system	Recertification decisions; finding consumers before retirement
Environment and risk tier	Approval route, rotation interval, review frequency
Permissions from an approved role template	Least privilege without free-text grants
Credential type and justification for any static secret	Drives rotation workflow or exemption
Expiry date	Triggers renewal or retirement without an audit

Choosing the credential type at creation

Credential	Rotation needed	Use when
Managed identity or attached role (Azure managed identity, AWS IAM role for compute, Google attached service account)	No: platform handles it	Workload runs on the same cloud as the resource
Workload identity federation	No secret to rotate; trust configuration reviewed	Workload runs elsewhere with its own OIDC issuer (CI, Kubernetes, another cloud). See the Workload Identity Federation Guide
Dynamic secret with lease	Expires by TTL; renew or reissue	Databases and cloud credentials issued per job or session
Certificate	Yes, automated renewal	mTLS and signing. See the Machine Identity, PKI and Certificate Lifecycle Guide
Static secret or API key	Yes, scheduled and event-driven	Third-party SaaS APIs with no alternative

HashiCorp Vault attaches a lease with a TTL to every dynamic secret; a lease can be renewed or revoked, revocation invalidates the secret immediately, and vault lease revoke -prefix revokes every lease under a path, which is useful when one backend is compromised. See the HashiCorp Vault Guide.

Platform guardrails that force the workflow

Microsoft Entra ID: app management policies can block password (client secret) addition with passwordAddition, cap secret lifetime with passwordLifetime, cap certificate lifetime with asymmetricKeyLifetime and restrict certificates to trusted issuers with trustedCertificateAuthority (API only). Apply them tenant-wide, with exclusions for the provisioning service principal that the workflow uses.
Google Cloud: organisation policy constraints iam.managed.disableServiceAccountKeyCreation and iam.managed.disableServiceAccountKeyUpload block keys; iam.serviceAccountKeyExpiryHours limits key lifetime (1 to 2,160 hours) where keys must exist; iam.managed.preventPrivilegedBasicRolesForDefaultServiceAccounts stops Editor and Owner on default service accounts. Google documents that the legacy key creation and upload constraints are enforced by default for organisations created on or after 3 May 2024.
AWS: use service control policies to deny iam:CreateUser and iam:CreateAccessKey outside the pipeline role, and keep remaining secrets in Secrets Manager with rotation. Secrets Manager supports managed rotation for many services and Lambda-based rotation that creates a pending version, sets it in the target, tests it and then promotes it to current. See the AWS Access Keys Security Guide.
Kubernetes: use projected, time-bound service account tokens rather than long-lived token secrets. See the Kubernetes Service Account Token Guide.

Designing rotation that does not break things

Overlap versions: issue the new credential while the old one still works, deploy it, then revoke the old one. For databases, an alternating-users pattern avoids the window where the password has changed but clients have not.
Have consumers read from the vault at runtime rather than from config files, so rotation needs no redeploy.
Test with the real consumer: a health check that authenticates with the new version before promotion.
Roll back automatically to the previous version if the test fails, and alert the owner.
Revoke and verify: confirm the old credential is rejected. Rotation without revocation leaves two valid secrets.
Rotate on events, not only on schedule: leak detection, owner departure, vendor breach and incident response should call the same workflow.

The cost of skipping event-driven rotation is well documented: after the October 2023 Okta breach, Cloudflare left one service token and three service accounts unrotated because it believed they were unused, and an attacker used them in November to reach Atlassian systems and source code. See the Cloudflare Thanksgiving Breach 2023. Cloudflare then rotated more than 5,000 production credentials.

Recertification and retirement automation

Last-used data: pull last sign-in or last API call per identity and per credential (Entra service principal sign-in logs, AWS IAM last accessed information, Google Cloud service account usage) to pre-fill recertification and flag unused permissions. See the NHI Dormancy Detection guide.
Owner events: subscribe to HR leaver and mover events; when an owner leaves, the workflow assigns the manager as interim owner and opens a transfer task with a deadline.
Expiry: 30 and 7 days before expiry, notify the owner; at expiry, disable unless renewed through the workflow.
Staged retirement: disable, wait a fixed quiet period while monitoring for failed authentication, revoke credentials, then delete. Failed authentications during the quiet period identify hidden consumers.
Inventory reconciliation: daily comparison of identities found on each platform against the workflow's records; anything not created by the workflow becomes a finding with an owner.

Decision guidance

Build or buy: an IGA or NHI platform gives discovery, ownership and recertification across platforms; infrastructure as code plus a secrets manager covers creation and rotation well. Most organisations need both, with the IaC pipeline as the only creation path.
Small organisations: start with three things: block new long-lived keys by policy, put remaining secrets in one vault with rotation, and a quarterly owner attestation from a spreadsheet inventory. See the Service Account Inventory Template.
Large organisations: risk-tier identities (production, privileged, external) and set recertification frequency and approval depth by tier. Use the NHI Risk Scoring Guide.
Legacy systems: where a credential cannot be rotated automatically, record a compensating control and an exception with an expiry, rather than leaving it outside the inventory.

Detection and measurement

Metric	Target
Share of NHIs created through the workflow	Rising towards 100 percent
Share of NHIs with an active owner and expiry	100 percent for production
Share of credentials that are federated, managed or dynamic	Rising
Static secrets past their rotation date	Zero
Rotation success rate without manual fix	Above 95 percent
Median days from trigger (owner leaves, expiry) to retirement	Falling

Alert on identities and credentials created outside the workflow: new Entra application secrets not made by the provisioning principal, CreateAccessKey by any other caller, and Google Cloud CreateServiceAccountKey events. See the Detection Engineering for Non-Human Identities Guide.

Framework mapping

Framework	Reference	Relevance
OWASP Non-Human Identities Top 10 2025	NHI1 Improper Offboarding, NHI2 Secret Leakage, NHI5 Overprivileged NHI, NHI7 Long-Lived Secrets	Risks the lifecycle closes
NIST SP 800-53 Rev. 5	AC-2, AC-2(1), AC-2(3), IA-4, IA-5, CM-8	Automated account management, disabling, identifier and authenticator management, inventory
NIST CSF 2.0	PR.AA-01, PR.AA-05, ID.AM-08	Managing identities and credentials, access policy, lifecycle management
CIS Controls v8.1	Safeguards 5.1, 5.3, 6.2	Account inventory, disable dormant accounts, revoking access
ISO/IEC 27001:2022 Annex A	5.16, 5.18, 8.5	Identity management, access rights, secure authentication
MITRE ATT&CK	T1078.004, T1098.001, T1552.001	Abuse of valid cloud accounts, added cloud credentials, credentials in files

Common failure patterns

Workflow without guardrails: the catalogue exists, but engineers still create keys in the console because nothing blocks them.
Owner as a team alias: nobody is accountable at recertification, so everything is re-approved.
Scheduled rotation, no revocation: old secrets stay valid and copies in config files keep working.
"Unused" assumed, not measured: as Cloudflare found, credentials believed unused were exactly the ones an attacker used.
Deletion without a quiet period: production breaks, the identity is recreated by hand outside the workflow and the inventory loses it.
Agents and SaaS integrations left out: OAuth grants and agent credentials are NHIs too and need the same stages. See the Identity Governance for AI Agents Guide.

Practitioner checklist

Define one request form or API with mandatory owner, purpose, environment, permissions and expiry.
Make infrastructure as code the only creation path and deliver credentials straight into a vault.
Apply platform guardrails: Entra app management policies, Google Cloud key constraints, AWS SCPs.
Default to managed identities, federation or dynamic secrets; justify every static secret.
Automate rotation with overlap, consumer testing, rollback and verified revocation.
Wire HR leaver events, expiry dates and inactivity thresholds to retirement workflows.
Run risk-tiered recertification pre-filled with last-used data.
Reconcile platform inventories daily and alert on identities created outside the workflow.

NHI lifecycle automation: Request, create, rotate and retire machine identities by workflow