How should security teams govern NHI access across joiners, movers, and leavers?

Why This Matters for Security Teams

Joiners, movers, and leavers are where NHI governance either stays current or quietly drifts out of control. Every onboarding event creates new service accounts, API keys, bot permissions, and secrets; every move can invalidate prior assumptions about scope; every leaver should trigger revocation, not just a ticket close. The risk is amplified because NHIs outnumber human identities by 25x to 50x, and the Ultimate Guide to NHIs shows that only 20% of organisations have formal offboarding and API key revocation processes.

Security teams often treat access reviews as periodic hygiene, but JML is really a control loop: identity source, business purpose, entitlement, secret, and owner must all stay aligned. That means HR, IAM, PAM, platform engineering, and application owners need a shared view of who or what owns each NHI, what it can do, and what event should force removal. Current guidance from the NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 both point toward continuous identity governance, not static approval records.

In practice, many security teams discover stale bot access only after a mover event has already widened privilege or a leaver event has already left secrets behind.

How It Works in Practice

Effective JML governance for NHIs starts with classification. Each service account, bot, workload identity, and integration should have a named owner, a documented business purpose, an expiration or review date, and a mapped set of allowed systems. On joiner events, provisioning should be tied to a change request and restricted to the minimum scope needed for the initial task. On mover events, the team should re-evaluate whether the original identity still fits the new application, environment, or permission boundary. On leaver events, revocation must include not only access removal but also secret invalidation, token rotation, webhook detachment, and deletion of unused credentials.

A practical pattern is to combine RBAC for baseline entitlement with JIT for elevated actions, then require explicit approval for anything outside the steady-state scope. That matters because NHI abuse is often driven by standing privilege and long-lived secrets. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Key Challenges and Risks both emphasise that secrets and permissions must move with the lifecycle, not sit outside it.

• Bind each NHI to an owner and a ticketable business purpose.
• Use automated checks to compare directory changes, CMDB records, and cloud entitlements.
• Trigger secret rotation when ownership, scope, or environment changes.
• Require the application owner to attest that a mover event still needs the same access.
• Revoke and archive stale identities quickly, then verify deletion actually succeeded.

This matters because 91.6% of secrets remain valid five days after notification, which shows that revocation workflows often lag behind the change event itself. Best practice is evolving toward policy-driven lifecycle automation, but there is no universal standard for every platform yet. These controls tend to break down in federated SaaS and legacy middleware because ownership is unclear and secrets are embedded in code, config, or CI/CD pipelines.

Common Variations and Edge Cases

Tighter JML controls often increase operational overhead, requiring organisations to balance revocation speed against application stability. That tradeoff is especially real for shared service accounts, break-glass accounts, and third-party integrations, where a single identity may support multiple systems or vendors. In those cases, the control objective is not instant deletion at any cost, but precise scoping, compensating monitoring, and staged retirement.

There are also edge cases where the identity source does not cleanly map to the actual runtime actor. For example, a SaaS connector may be owned by one team while used by several, or an agentic workflow may create temporary execution identities as it moves across tools. In those environments, current guidance suggests prioritising workload identity, short-lived secrets, and request-time authorisation decisions over static RBAC alone. That aligns with the operational direction discussed in the Ultimate Guide to NHIs and with the risk patterns described in the Top 10 NHI Issues.

Security teams should also treat cloud-native and CI/CD environments differently from traditional infrastructure. In high-churn pipelines, JML needs to be event-driven and automated, because manual review cannot keep up with ephemeral jobs, containers, and service mesh identities. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support this direction: reduce standing access, verify continuously, and remove access when the business purpose ends.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams make NHI best practices usable across the business?
• How should security teams govern API keys used for generative AI access?
• How should security teams prioritise NHI remediation in cloud environments?