Non-human identity security now requires lifecycle governance

At a glance

What this is: This is an independent analysis of why non-human identity security has become a governance problem, with the key finding that human-centric IAM, IGA, and PAM controls do not fully cover NHIs.

Why it matters: It matters because IAM teams now have to govern machine identities with the same lifecycle discipline they apply to people, while also accounting for cloud, SaaS, and audit requirements.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Oasis Security's analysis of why non-human identity security matters now

Context

Non-human identity security is the discipline of governing service accounts, API keys, tokens, certificates, and similar machine identities with ownership, context, and lifecycle controls. The problem is not simply that these identities exist in large numbers, but that many are created continuously, distributed across cloud and SaaS environments, and left outside the normal visibility of IAM and IGA programmes.

That matters because the usual enterprise model assumes identities are human, reviewable, and tied to a stable owner or employee lifecycle. Once the identity is a service principal, secret, or certificate, the governance model has to cover discovery, assignment, least privilege, rotation, and offboarding across operational and audit workflows. The article's central point is that many organisations still treat NHIs as exceptions when they now represent a core control plane issue.

Key questions

Q: How should security teams handle non-human identities that do not fit human IAM workflows?

A: Treat non-human identities as first-class governed assets, not exceptions. Assign ownership, discover them continuously, and place them into lifecycle workflows for provisioning, review, rotation, and retirement. Human IAM controls alone do not provide the context or evidence needed for service accounts, tokens, and certificates.

Q: Why do service accounts and API keys increase governance risk?

A: They often exist outside interactive controls such as MFA and SSO, and many are created with standing access that is never reviewed. That combination creates persistent exposure, weak accountability, and a large attack surface when secrets are copied into code, CI/CD, or cloud services.

Q: What breaks when non-human identities are not included in recertification?

A: Access remains active even after the business need changes, so expired service accounts and unused keys continue to represent live privilege. Without recertification, teams cannot prove ownership, cannot justify access, and cannot confidently retire identities without risking outages.

Q: Who should own non-human identity offboarding and rotation?

A: The application or service owner should own the business decision, while IAM or security should enforce the workflow and evidence. That split prevents orphaned credentials, ensures accountability, and makes retirement defensible in audit and incident response.

Technical breakdown

Why human-centric IAM misses non-human identities

Traditional IAM was built around people, not machine identities. Human controls such as SSO, MFA, and user recertification depend on interactive authentication, an accountable subject, and a known lifecycle. NHIs often bypass those assumptions because they authenticate with secrets, certificates, or tokens and are frequently created inside applications, pipelines, or cloud services. That makes discovery harder and ownership less obvious. When the identity layer cannot tell who created the credential, who consumes it, or where it is used, the result is governance blind spots rather than just excess inventory.

Practical implication: map every NHI population to a control owner and a discovery source before trying to automate remediation.

How secrets, vaulting, and rotation change the attack surface

Secrets are the operational proof that a non-human identity can act, so their storage and rotation behaviour directly shape risk. A hard-coded key, an unrotated token, or a certificate without expiry becomes standing access that can survive long after the original business need. Vaulting helps, but only when it is paired with context about usage and dependency. Otherwise, rotation can break production or leave unknown consumers untouched. The real control problem is not just where the secret lives, but whether the organisation can safely change it without losing service continuity.

Practical implication: build rotation around dependency mapping and service-owner sign-off, not just around vault policy.

Why NHI lifecycle governance belongs in the same programme as human access reviews

Lifecycle governance is the bridge between discovery and control. For NHIs, that means provisioning, ownership assignment, recertification, and offboarding must be part of the same governance fabric that already exists for humans. The difference is that machine identities may be created by developers, vendors, or automation pipelines and then forgotten. If they are not folded into access review and attestation workflows, they stay active indefinitely. That is why the issue is not just secret management. It is a governance model that stops at the human boundary.

Practical implication: extend access reviews and deprovisioning workflows to service accounts, keys, and certificates with the same audit evidence you use for users.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The identity paradox is really a governance paradox. The article's core claim is that organisations can no longer assume the identity subject is a person, because NHIs now carry sensitive access and often evade the protection layers built for humans. That changes the question from who logged in to what identity class is actually acting. The implication is that IAM programmes must classify identity by behaviour and lifecycle, not by familiarity.

Human-centric IGA breaks at the point of ownership. The article correctly points out that many IGA programmes are built around joiner, mover, leaver workflows for employees, while NHIs may be created in code, cloud services, or vendor integrations. Context gaps are the failure mode: without usage, consumer, and owner context, the programme cannot certify or retire the identity with confidence. Practitioners should treat ownership resolution as the first governance control, not a downstream cleanup task.

Ephemeral credential trust debt: the article surfaces a common but undernamed problem, which is that credentials persist far longer than the business event that created them. That is not just poor hygiene. It is deferred trust, where the organisation keeps paying risk on an identity whose purpose has already expired. The implication is that lifecycle enforcement must be aligned to actual use, not just issuance.

PAM and CNAPP are necessary but not sufficient for NHI governance. The article shows why privileged controls and cloud posture tools each see only part of the problem. PAM can manage known privileged identities and rotation, while CNAPP can expose posture issues in cloud environments, but neither creates universal identity context across SaaS, on-prem, and application-level consumers. Practitioners should therefore stop treating tool coverage as governance coverage.

NHI governance is now a compliance function, not just an engineering task. The article ties NHIs to onboarding, offboarding, recertification, and audit workflows for frameworks such as SOX, PCI, and HIPAA. That is the right boundary because the question is no longer whether a secret exists, but whether the organisation can evidence who owns it, who approved it, and when it was retired. The practical takeaway is that auditors will increasingly ask for lifecycle evidence, not only access data.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• A separate finding shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents resulting in tangible damage.
• For a broader control baseline, see Top 10 NHI Issues for the recurring failures that drive this gap.

What this signals

Ephemeral credential trust debt: organisations are carrying risk long after a token, key, or certificate has served its purpose, which is why lifecycle evidence matters more than inventory counts alone. The next maturity step is not broader discovery by itself, but the ability to retire identities without breaking production or auditability.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the control problem is already distributed across engineering workflows. That means security teams need to coordinate with platform and application owners, then align those controls to the NIST Cybersecurity Framework 2.0 and the NHI Lifecycle Management Guide.

The practical signal to watch is whether recertification and offboarding can be executed on machine identities with the same evidence trail used for people. If they cannot, the programme has not yet reached true identity governance across human and non-human estates.

For practitioners

• Inventory NHIs across every environment Automate discovery for service accounts, API keys, tokens, and certificates in cloud, SaaS, on-prem, and CI/CD systems. Record owner, consumer, business purpose, and expiry so the inventory is usable for recertification and offboarding, not just reporting.
• Attach NHIs to a governance workflow Route machine identities into access review and attestation processes alongside human identities, with evidence of approval, purpose, and retirement. Use the NHI Lifecycle Management Guide to structure provisioning, rotation, and decommissioning controls.
• Right-size privileges before rotation Review what each secret or service principal can reach, then reduce scope before changing credentials. This avoids rotating a broadly over-permissioned identity that would still expose the same downstream resources if compromised.
• Build safe rotation around dependencies Map every consumer of a credential before rotating it, then stage the change so production services do not fail. Pair the operational runbook with the Ultimate Guide to NHIs for lifecycle and visibility context.
• Tie compliance evidence to identity retirement Keep attestations, offboarding records, and ownership data together so SOX, PCI, or HIPAA reviews can prove when a non-human identity was retired and why. The audit trail should show who approved the access and who removed it.

Key takeaways

• Non-human identity security is a governance problem because machine identities often sit outside the human-centric controls that IAM, IGA, and PAM were built around.
• The scale of the issue is already material, with NHIs vastly outnumbering human identities and offboarding or rotation processes still missing in many organisations.
• The practical answer is to extend ownership, discovery, rotation, and recertification into the same lifecycle workflows used for human access, while preserving audit evidence.

Key terms

• Non-Human Identity: A non-human identity is a machine credential or workload identity used by software, services, or automation rather than a person. In practice this includes service accounts, API keys, tokens, and certificates that authenticate actions and grant access across cloud, SaaS, and on-prem systems.
• Identity Lifecycle Governance: Identity lifecycle governance is the process of managing identity from creation to retirement with clear ownership, review, and evidence. For NHIs, it includes discovery, provisioning, rotation, recertification, and offboarding so credentials do not outlive their business purpose.
• Secret Rotation: Secret rotation is the controlled replacement of credentials before they become stale, exposed, or overused. For non-human identities, rotation must account for dependencies and runtime consumers, otherwise a change that improves security can break applications or leave unknown access paths in place.
• Ownership Resolution: Ownership resolution is the act of assigning a responsible business or technical owner to an identity or credential. For NHIs, it is a prerequisite for governance because without a named owner, security teams cannot justify access, approve changes, or retire the identity with confidence.

Deepen your knowledge

Non-human identity discovery, rotation, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending IAM controls beyond people, it is worth exploring.

This post draws on content published by Oasis Security: Non Human Identity Security - Why Now? Read the original.