Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure
Back to Blog

OWASP NHI Top 10: what to check for each machine identity risk

The ten OWASP NHI risks explained through specific checks for service accounts, tokens, deployment systems, and owners.

Ben Kim
Written by
Ben Kim
Published
Updated
4 min read492 words
Share:
OWASP NHI Top 10: what to check for each machine identity risk

Published October 3, 2026. This article replaces an older version that carried a 2024 publication date even though it described the 2025 OWASP list. The OWASP Non-Human Identities Top 10 names risks associated with accounts and credentials used by applications, services, and workloads. It is a risk reference, not a compliance certification.

The ten risks, in plain terms

NHI1: Improper offboarding. A service account or access key survives after its application, integration, or owner has gone. Keep an owner and retirement process; test that retired access actually fails.

NHI2: Secret leakage. A credential appears in a repository, document, log, chat, or other place outside approved storage. Remove the exposed value where possible, rotate it at the issuer, and inspect use.

NHI3: Vulnerable third-party NHI. An integration receives access to your systems, then a weakness or compromise at that provider creates a route into your environment. Review the integration’s permissions and how you can revoke them.

NHI4: Insecure authentication. A workload uses a deprecated flow, app password, or static key when a safer supported method exists. Review the actual sign-in mechanism, not only where the key is stored.

NHI5: Overprivileged NHI. The identity can do more than its workload needs. Limit its scope and resource permissions, and retest the application after reducing them.

NHI6: Insecure cloud deployment configurations. Deployment systems expose or mishandle credentials through configuration, environment variables, or jobs. Separate sensitive publish steps, restrict job permissions, and inspect build output.

NHI7: Long-lived secrets. A key remains valid for too long, making a missed exposure useful to an attacker for longer. Prefer short-lived identities where supported; set a rotation and revocation path for the rest.

NHI8: Environment isolation. The same identity or credential crosses development, test, and production boundaries. Issue distinct access for each environment and block a test workload from production resources.

NHI9: NHI reuse. A single identity is shared across unrelated applications or services. Split it so one compromise does not grant access to every dependent system, and document who owns each replacement.

NHI10: Human use of NHI. A person uses a service credential for manual work. Require individual accounts for human actions so permissions and audit records identify the actor.

Turn the list into a review

Choose one critical service and draw its access path: workload, credential or federation flow, issuing service, target resource, owner, and retirement trigger. Mark which of the ten risks apply. Start with credentials that are exposed and still active, or identities with broad production access. Fixing one category does not close the others; a rotated key can still leave an overprivileged service account.

Cremit Platform contributes to NHI2 by finding exposed credentials in supported connected sources and verifying supported types. Its finding and owner workflow can support follow-up. It does not automatically audit every authentication flow, remove excess permissions, offboard identities, or certify all ten OWASP controls. Use identity provider, cloud, CI, and service records for those tasks.

Official source

OWASP Non-Human Identities Top 10

Share it with your networkLinkedInX

Read next

Get the next one in your inbox

Monthly NHI security brief from Cremit. One email, high signal.

We never sell your email. Unsubscribe anytime.

OWASP NHI Top 10: risks and practical checks | Cremit