Thanksgiving shows why NHI governance starts with identity inventory

At a glance

What this is: This is a Thanksgiving-themed NHI governance post that argues secure operations begin with knowing every non-human identity, assigning roles, and removing stale access.

Why it matters: It matters because identity teams need the same discipline across NHI, autonomous, and human programmes: discover what exists, define what it can do, and revoke what outlives its purpose.

👉 Read Oasis Security's Thanksgiving-themed post on NHI governance and lifecycle cleanup

Context

Non-human identity governance starts with a simple but often incomplete question: what identities exist, what do they do, and who is accountable for them? In practice, that means inventorying applications, APIs, workloads, service accounts, secrets, and the permissions attached to them before access sprawl becomes normal.

Oasis Security uses a Thanksgiving metaphor to explain the operational problem. The analogy is useful because the security issue is not the holiday theme itself, but the control failure underneath it: undiscovered identities, unclear roles, and leftover access that should have been removed. This is a classic NHI governance pattern rather than an unusual edge case.

Key questions

Q: How should security teams build an inventory of non-human identities?

A: Start by discovering every system that can authenticate without a person present, including workloads, APIs, service accounts, certificates, and tokens. Assign an owner, purpose, and expiration state to each identity. An inventory only becomes useful when it can drive lifecycle actions such as rotation, review, and offboarding.

Q: Why do stale credentials create such persistent NHI risk?

A: Because credentials often remain valid after the business need has ended, which means access continues even when accountability has already drifted. That persistence creates an exposure window for misuse, lateral movement, and accidental overreach. The longer the credential survives, the more governance has already failed.

Q: What do security teams get wrong about NHI role assignment?

A: They often map roles to convenience instead of the actual workload function. That produces broad, inherited permissions that are difficult to audit and easy to overuse. Good role design keeps access narrow, explicit, and tied to a single operational purpose.

Q: Who should be accountable for rotating and revoking machine credentials?

A: The identity owner and the system owner should both be accountable, with clear deadlines for rotation, revocation, and decommissioning. If ownership is ambiguous, credentials tend to survive by default. Accountability works only when the lifecycle state of each identity is tracked and enforced.

Technical breakdown

Identity discovery and the NHI guest list

A secure NHI programme begins with discovery. That means identifying every machine identity that can authenticate, call APIs, run workloads, or exchange secrets. The practical issue is not just enumeration, but completeness across cloud, CI/CD, code, and third-party integrations. If an organisation cannot produce a reliable inventory, it cannot reason about ownership, access scope, or lifecycle state. Discovery is the prerequisite for every later control, including rotation, offboarding, and recertification. Without it, teams are managing assumed identities rather than real ones.

Practical implication: build and maintain a current inventory of all machine identities before attempting policy enforcement or lifecycle remediation.

Role design, policy enforcement, and least privilege

Once identities are visible, the next problem is role definition. NHI roles should reflect task scope, not convenience, because broad permissions turn simple service functions into lateral movement opportunities. Policy-driven automation is useful only when the policy is tied to ownership, purpose, and expected behaviour. In identity terms, this is the difference between a credential that exists and a credential that is constrained. Clear roles reduce confusion, limit accidental privilege overlap, and make governance decisions auditable.

Practical implication: map each NHI to a task-specific role and remove standing permissions that are wider than the workload actually requires.

Stale secrets, leftover credentials, and lifecycle cleanup

The Thanksgiving leftovers analogy maps cleanly to NHI lifecycle failure. Secrets, certificates, API keys, and service account tokens often remain valid long after the business need has ended. That creates a persistence window in which access outlives accountability. The governance problem is not only exposure, but unreclaimed identity state. If credentials are not rotated, revoked, or decommissioned on time, the environment accumulates dormant access paths that still authenticate. Lifecycle cleanup is therefore a security control, not an administrative task.

Practical implication: tie offboarding and rotation to the identity lifecycle so stale credentials cannot remain usable after their intended purpose ends.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Identity inventory is the real starting point for NHI governance. The article gets that basic truth right, even if it uses a holiday metaphor to make the point. Organisations cannot govern what they cannot see, and hidden applications, APIs, workloads, and service accounts create blind spots that undermine every downstream control. The implication is simple: inventory is not documentation, it is the control plane for NHI governance.

Stale credentials are not leftovers, they are unresolved access state. The most durable NHI risk is not complexity, it is persistence. Unrotated secrets and unused credentials keep working after the business reason has disappeared, which means accountability has already failed before an incident occurs. Practitioners should treat credential persistence as a lifecycle defect, not a housekeeping issue.

Policy only works when the role model is accurate. The post correctly links secure operations to clearly defined roles, but that requirement is often undercut by broad, inherited, or ambiguous permissions. NHI governance fails when task scope and access scope diverge. The practitioner conclusion is that role design must be tested against actual workload behaviour, not organisational convenience.

Leftover access is a named failure mode, not a generic hygiene problem. This is the most useful concept in the piece: unused credentials, stale permissions, and unremoved identities create a lingering access estate that attackers can abuse long after ownership has drifted away. That is exactly the kind of lifecycle failure OWASP-NHI and NIST CSF are meant to surface. Teams should frame the problem as access that outlives purpose, because that is where governance breaks.

NHI lifecycle discipline should be applied with the same seriousness as human offboarding. The article points to cleanup after use, but the deeper lesson is that machine identities need explicit joiner-mover-leaver controls. When offboarding is informal, credentials become permanent by accident. Practitioners should treat every NHI as a governed identity with an owner, a scope, and an end date.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That is why the Ultimate Guide to NHIs remains the most relevant reference for identity inventory, rotation, and offboarding discipline.

What this signals

Leftover access is the programme-level signal teams should watch most closely. When permissions, secrets, and service accounts remain active after their intended purpose, the issue is no longer isolated hygiene, it is governance debt. NHI programmes that cannot close that debt will keep accumulating silent risk across cloud and automation estates.

The practical shift is toward lifecycle-led controls rather than one-time cleanup campaigns. Teams need continuous visibility into who owns each machine identity, when it should be rotated, and what happens when the business process ends. That is where NIST Cybersecurity Framework 2.0 style governance mapping becomes useful in practice.

Identity inventory will increasingly be the bridge between human IAM, NHI, and autonomous systems. As environments grow, the same questions recur across all three domains: what exists, who owns it, what can it do, and when should it be removed? The organisations that answer those questions consistently will have the strongest governance posture.

For practitioners

• Build a complete NHI inventory Inventory applications, APIs, workloads, service accounts, secrets, and certificates across cloud, CI/CD, and third-party integrations, then assign an owner to each identity.
• Define task-scoped roles for machine identities Replace broad inherited permissions with narrowly scoped roles that match the actual function of each identity, and review role drift during change management.
• Remove stale credentials on a lifecycle schedule Tie rotation, revocation, and decommissioning to business ownership so unused API keys, tokens, and certificates do not survive past their purpose.
• Treat leftover access as a remediation queue Create an exception process for stale permissions, orphaned identities, and long-lived secrets so cleanup is tracked as security work, not optional maintenance.

Key takeaways

• The central NHI risk in this post is identity sprawl, where systems exist without a reliable owner, purpose, or retirement path.
• The scale problem is lifecycle persistence, because stale permissions and unrotated secrets turn temporary access into durable exposure.
• The practical fix is to treat discovery, role design, and offboarding as one continuous governance process rather than separate tasks.

Key terms

• Non-Human Identity: A non-human identity is any credentialed digital entity that authenticates or acts on behalf of a system rather than a person. It includes service accounts, API keys, tokens, certificates, workloads, and automated processes that need ownership, scope, and lifecycle control.
• Identity Inventory: Identity inventory is the authoritative record of which identities exist, what they do, who owns them, and when they should be reviewed or removed. For NHI governance, completeness matters more than volume, because unseen identities are the ones most likely to escape lifecycle control.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being created only when needed. In NHI environments, it creates persistent exposure because credentials, roles, or permissions can outlive the task they were meant to support.
• Lifecycle Offboarding: Lifecycle offboarding is the controlled removal of an identity's access, credentials, and ownership when its business purpose ends. For non-human identities, it must include revocation, rotation, and decommissioning so leftover access does not remain usable after the workload is retired.

Deepen your knowledge

NHI discovery, role design, and lifecycle cleanup are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still relies on manual cleanup and ad hoc ownership, it is worth exploring.

This post draws on content published by Oasis Security: The feast of security: what Thanksgiving can teach us about protecting Non-Human Identities. Read the original.