OWASP NHI1 Improper Offboarding: Guide for Practitioners

Service accounts, access keys, tokens and OAuth apps routinely outlive the projects, systems and people that created them, and every one that stays active is a working credential nobody is watching. OWASP ranks this as the first risk in its Non-Human Identities Top 10, NHI1:2025 Improper Offboarding. This guide explains what the risk covers, how OWASP rates it, and how to build the discovery, ownership and offboarding workflow that closes it. It is written for IAM engineers, cloud platform teams and security architects who own service accounts and secrets, and for auditors who need to test the control. It covers cloud IAM, Kubernetes, SaaS integrations and CI/CD credentials.

Key takeaways

NHI1 has three forms: stale or dormant NHIs left behind by retired applications, orphaned NHIs whose owner has left, and credentials known to a departing employee who was not their owner.
OWASP rates it easy to exploit and hard to detect, with widespread prevalence and severe technical impact, because an unused credential generates little activity for anyone to notice.
Ownership is the control that makes offboarding possible: without a named, current owner for every NHI there is no trigger to retire it and nobody to approve deletion.
Offboarding a person must include the NHIs they touched, not only their own accounts: rotate any secret a leaver could have seen, and transfer or retire anything they owned.
Disable, observe, then delete: a staged decommission with a defined quarantine window removes the fear of breaking production that keeps stale NHIs alive.

What it is and who it applies to

The OWASP NHI1:2025 page defines improper offboarding as the inadequate deactivation or removal of non-human identities, such as service accounts and access keys, once they are no longer needed. OWASP describes three situations:

Stale or dormant: an application is deprecated or a service goes offline, but its identities stay active.
Orphaned: the owner leaves the organisation and the NHI continues to run with nobody accountable for it.
Partially offboarded employee: someone who was exposed to an NHI's credentials, without owning it, leaves and the credentials are not rotated.

The risk applies to any organisation that runs automation: cloud IAM users, roles and service accounts, Kubernetes service accounts, OAuth client applications and app registrations, personal access tokens, API keys for SaaS platforms, CI/CD deployment credentials, database accounts and signing keys. It also applies to AI agents, which are created quickly for experiments and rarely retired with the same discipline. See the Non-Human Identity (NHI) Guide for the wider category.

Structure and key requirements

The OWASP entry follows the standard OWASP risk rating format. The table summarises its ratings and what each means for defenders.

OWASP factor	NHI1 rating	What it means in practice
Exploitability	Easy	An insider or an attacker already inside can identify which forgotten credential gives access; no exploit development is needed.
Prevalence	Widespread	OWASP notes that NHI offboarding capabilities are inadequate and that available options are rarely used.
Detectability	Hard	Finding unused NHIs relies on incomplete usage data that is slow to compile and analyse.
Technical impact	Severe	Forgotten NHIs often keep elevated permissions, enabling critical system compromise, data exfiltration and persistence.
Business impact	Specific	Depends on what the NHI could reach; a signing key or an admin integration has organisation-wide impact.

OWASP's prevention guidance has four requirements:

Offboarding review for leavers: review every NHI associated with a departing employee; decommission what is no longer needed, transfer ownership of the rest, and rotate credentials the employee could access.
Automation: integrate HR systems with identity and access management tooling so that a leaver event starts the NHI review automatically.
Periodic recertification: confirm that each NHI is still in use, still needed and has a valid owner.
Ongoing audit: monitor usage of active NHIs to detect and block misuse.

OWASP's example scenarios are worth using as test cases: service accounts left active on a decommissioned Kubernetes cluster; an ex-employee who managed automation keeping access because credentials were never rotated; a test application connected to sensitive systems left running after its workload moved to production; and a developer's access key, used by a business-critical application, unnoticed after the developer leaves. The page cites Cloud Security Alliance survey data that 51% of organisations have no formal process to offboard or revoke long-lived API keys.

Identity and NHI requirements

Offboarding fails because the data needed to decide is missing. Before any workflow, each NHI needs the attributes below. See the Service Account Inventory Template for a ready-made structure.

Attribute	Why offboarding needs it	Where to get it
Primary owner (a person) and owning team	Someone must approve retirement or transfer; a team survives individual departures	Tags or labels at creation, CMDB, IGA owner field
Parent application or workload	When the application is retired, its NHIs are retired with it	CMDB, deployment manifests, app registration metadata
Credential type and age	Static keys and long-lived tokens need rotation on leaver events; federated identities may not	Cloud IAM APIs, secrets manager metadata
Last authentication and last action	The evidence that an NHI is stale	AWS IAM last accessed data, Google Cloud authentication metrics, sign-in logs
People with access to the secret	Defines the "partially offboarded employee" exposure	Secrets manager access policies, vault audit logs, repository and pipeline permissions
Permissions and blast radius	Prioritises which stale NHIs to retire first	Policy analysis, entitlement reports
Expiry or review date	Forces a decision rather than indefinite life	Set at creation by policy

Discovering orphaned and stale NHIs

AWS: IAM last accessed information shows which services a user, role or policy has used, retained for at least 400 days, with action-level detail for some services. Use GenerateServiceLastAccessedDetails and GetServiceLastAccessedDetails; the IAM credential report adds per-key last-used dates. AWS notes that last accessed data includes denied attempts, so confirm with CloudTrail before concluding a role is in use.
Google Cloud: the metrics iam.googleapis.com/service_account/authn_events_count and iam.googleapis.com/service_account/key/authn_events_count count authentication events per service account and key, but are kept for six weeks only, so export them to BigQuery for longer baselines. Activity Analyzer shows the most recent authentication, and service account insights flag accounts unused for 90 days.
Kubernetes: list service accounts per namespace and compare with running workloads; long-lived secret-based tokens should be the first target, since current releases issue short-lived bound tokens by default. A cluster that has been decommissioned must also have its cloud-side identities (workload identity bindings, node roles) removed.
SaaS and OAuth: review app registrations, OAuth grants and integration users in each SaaS tenant, including test tenants. See the SaaS and OAuth App Governance Guide.
Code and pipelines: personal access tokens and deploy keys tied to individual developers are classic orphans: they disappear from view when the developer's account is disabled in one system but not in another.

Ownership is the root fix. See the NHI Ownership Guide and the NHI Ownership Attestation Campaigns Guide.

Implementation steps

Build the inventory (weeks 1 to 4): pull all NHIs from cloud providers, identity providers, Kubernetes, secrets managers and top SaaS platforms into one list with the attributes above. Accept gaps at first; the aim is coverage.
Assign owners: map each NHI to an owner from tags, creator records or the parent application. Anything without an owner goes into an "unowned" queue owned by the platform team, with a deadline for claiming.
Define stale: agree thresholds per credential type, for example no authentication in 90 days for service accounts and no use of a static key in 30 days where a replacement exists. Record exceptions such as annual batch jobs and disaster recovery accounts.
Stage decommission: for each stale NHI, notify the owner, then disable (deactivate the key, disable the account, remove the role binding) rather than delete. Keep a quarantine window, typically 30 days, during which re-enabling is a single action. Delete after the window, and record the decision.
Wire leaver events: connect the HR system to the IGA or identity platform so that a leaver or mover event lists every NHI the person owns or could read. Transfer ownership before the leaving date, and rotate any shared secret the person could access. See the Employee Offboarding Security Guide.
Tie NHIs to application retirement: add "retire identities and secrets" as a mandatory step in the change process for decommissioning applications, clusters, environments and test tenants.
Set expiry at creation: new NHIs get an owner, a review date and, where possible, short-lived or federated credentials so that an abandoned identity stops working on its own. See the NHI Offboarding and Decommissioning Guide.
Recertify: run owner attestation quarterly for privileged NHIs and at least annually for others; non-response triggers disablement.

Testing and rollback: pilot the disable step on non-production accounts first. Before disabling a production NHI, check the last 30 to 90 days of authentication data and the owner's confirmation. If something breaks, re-enable the identity, record the dependency, assign an owner and set a review date rather than leaving it permanently exempt.

Decision guidance

Situation	Preferred action	Trade-off
Unused NHI, owner confirms not needed	Disable, quarantine, delete	Low risk; quarantine covers forgotten dependencies
Unused NHI, no owner found	Disable after notice period, then delete	Some outage risk; accept it rather than keep an unowned credential
In use, owner has left	Transfer ownership, rotate credentials	Rotation requires coordinated deployment
In use, static key seen by a leaver	Rotate immediately; plan move to federated or short-lived credentials	Rotation effort now versus repeat exposure on every leaver
Signing key or root secret seen by a leaver	Rotate and re-issue, revoke old key material	High effort; impact of not doing it is organisation-wide

Small organisations can start with cloud provider native reports and a spreadsheet inventory reviewed monthly. Large organisations with thousands of NHIs need automated discovery, owner resolution and ticketing, typically through an IGA platform or a dedicated NHI security tool. See the NHI Security Platform Buyer's Guide.

Evidence and assessment

Auditors and internal assessors testing NHI1 should ask for evidence, not policy statements.

Inventory completeness: a reconciliation between the NHI inventory and each platform's own list (cloud IAM, identity provider, Kubernetes, top SaaS tenants).
Leaver sample: for a sample of leavers in the period, the list of NHIs they owned or could access, and proof of transfer or rotation before or on the leaving date.
Decommission records: for retired applications, evidence that their identities and secrets were disabled and deleted.
Stale NHI report: NHIs with no authentication beyond the threshold, and the action taken on each.

What to log and monitor: authentication by NHIs that were marked stale or are in quarantine; any use of a credential after its owner's leaving date; new keys added to existing service accounts or apps (ATT&CK T1098.001 Additional Cloud Credentials); and authentication from unexpected networks by service principals (T1078.004 Cloud Accounts).

Metric	Target direction
Percentage of NHIs with a current, active owner	Above 95%, rising
Number of NHIs with no authentication beyond the stale threshold	Falling month on month
Median days from leaver date to NHI transfer or rotation	0 days (completed by leaving date)
Percentage of retired applications with all NHIs removed within 30 days	100%
Percentage of NHIs using static, non-expiring credentials	Falling
Recertification completion rate for privileged NHIs	100% per cycle

Mapping to other frameworks

Framework	Reference	Relevance to NHI1
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-2(3) Disable Accounts; AC-2(2) Automated Temporary and Emergency Account Management	Account lifecycle, disabling inactive and unneeded accounts
NIST SP 800-53 Rev. 5	IA-4 Identifier Management; IA-5 Authenticator Management	Retiring identifiers and changing authenticators
NIST SP 800-53 Rev. 5	PS-4 Personnel Termination; PS-5 Personnel Transfer; CM-8 System Component Inventory	Leaver and mover triggers; inventory
NIST CSF 2.0	PR.AA-01; PR.AA-05; ID.AM-02	Identities and credentials for services managed; access reviewed; inventories of software and services
CIS Controls v8.1	5.1 Establish and Maintain an Inventory of Accounts; 5.3 Disable Dormant Accounts; 6.2 Establish an Access Revoking Process	Inventory, dormant accounts, revocation on departure
ISO/IEC 27001:2022 Annex A	5.16 Identity management; 5.18 Access rights; 6.5 Responsibilities after termination or change of employment	Lifecycle of identities and access, leaver obligations
MITRE ATT&CK v20	T1078 Valid Accounts; T1078.004 Cloud Accounts; T1098.001 Additional Cloud Credentials	How attackers use forgotten identities
OWASP NHI Top 10	NHI7 Long-Lived Secrets; NHI5 Overprivileged NHI	Long-lived and overprivileged credentials magnify NHI1

Sibling pages: OWASP NHI Top 10 NHI2 Secret Leakage Guide, OWASP NHI Top 10 NHI5 Overprivileged NHI Guide, OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide and OWASP NHI Top 10 NHI10 Human Use of NHI Guide.

Common pitfalls

Assuming a credential is unused without checking: after the Okta support system breach, Cloudflare left one service token and three service accounts unrotated because it wrongly believed they were unused, and a nation-state attacker used them to reach its Atlassian systems and source code. See the Cloudflare Thanksgiving Breach 2023.
Offboarding the person but not the secret: a former Coupang developer kept a token signing key after leaving at the end of 2024; it was never rotated, and he used it to forge tokens and access data on about 33.7 million accounts. See the Coupang Breach 2025.
Forgetting test and legacy tenants: Microsoft reported that Midnight Blizzard compromised a legacy non-production test account without MFA, then a legacy test OAuth application with elevated access to the corporate environment, which it used to reach corporate mailboxes. OWASP cites this incident on the NHI1 page.
Deleting without a quarantine window: one outage caused by a hasty deletion makes teams refuse future clean-ups. Disable first, delete later.
Owners recorded as individuals only: when the named owner leaves, the NHI is orphaned again. Record a team as well as a person.
Relying on short retention data: six weeks of metrics cannot prove that a quarterly or annual job no longer runs; export usage data for long baselines.

Practitioner checklist

Build one NHI inventory across cloud IAM, identity providers, Kubernetes, secrets managers and SaaS, including test tenants.
Give every NHI a named owner, an owning team, a parent application and a review or expiry date.
Define stale thresholds per credential type and report against them monthly.
Decommission in stages: notify, disable, quarantine for a defined period, then delete.
Trigger NHI review from HR leaver and mover events, and rotate every secret a leaver could access.
Make identity and secret retirement a mandatory step in application and environment decommissioning.
Recertify privileged NHIs quarterly and disable those with no response.
Alert on use of quarantined NHIs and on new credentials added to existing service accounts and apps.
Replace static keys with short-lived or federated credentials so abandoned identities expire on their own.

OWASP NHI Top 10 NHI1 Improper Offboarding Guide