When an engineer signs in as a service account, pastes a deployment key into a terminal or shares a bot token with the team, every action they take is logged as "the machine", and the controls built for people, such as MFA, device checks and personal accountability, quietly drop away. OWASP lists this as NHI10:2025 Human Use of NHI, the last entry in the Non-Human Identities Top 10. This guide explains how OWASP defines and rates the risk, which platform features separate human and workload use, how to move people off machine credentials without breaking operations, and how to evidence the result. It is for IAM and platform engineers, SRE and operations leads, and the assessors who review NHI programmes.
Key takeaways
- It is a people problem with a machine signature. OWASP notes that developers often impersonate service accounts to debug issues, and that most NHI providers cannot tell a workload using an NHI from a human using it.
- Four harms, not one. OWASP names elevated privilege, lost accountability, human and automated activity becoming indistinguishable, and cover for attackers.
- Impersonation is fine, borrowing is not. Logged, short-lived impersonation (Google Cloud
--impersonate-service-account, AWS role sessions with a source identity, Kubernetes--as) keeps the human in the audit trail; copying a key does not. - Close the convenience gap first. People use NHIs because their own access is slower. Give them a fast, approved break-glass or just-in-time path before you block the shortcut.
- Detection is the hard part. OWASP rates detectability Hard, so build specific signals: console sign-ins by service identities, NHI use from user devices or office IP ranges, and interactive logons by service accounts.
What it is and who it applies to
OWASP describes NHIs (service accounts, API tokens, workload identities) as designed for programmatic access, so applications and automated processes can run without human intervention. NHI10 occurs when developers or administrators use those identities for manual tasks that should be done with their own identity and appropriate privileges. The weakness is common in practice because machine identities often hold exactly the access an engineer needs during an incident, and because nothing in most platforms stops a person from presenting a machine credential.
The risk applies wherever a person can obtain or present an NHI credential:
- Cloud administrators: signing in to a cloud console or CLI with a deployment service account, an IAM user access key created for a pipeline, or an Entra ID service principal secret.
- Developers and SREs: running scripts against production with an application's credentials, or loading a service account key file into a laptop to reproduce a bug.
- Teams sharing tokens: one SaaS or API token kept in a chat channel or shared vault entry and used by several people.
- Windows and directory administrators: logging on interactively or over RDP with a domain service account whose password is known to the team. See the Service Account Security Guide.
- Attackers: OWASP's final scenario is the attacker who obtains NHI credentials after compromise and uses them for persistence, because NHIs are not subject to regular password changes or MFA.
NHI10 sits next to two neighbours. NHI9 NHI Reuse is several workloads sharing one identity; NHI5 Overprivileged NHI is the excess privilege that makes human use tempting and damaging. See the OWASP NHI Top 10 NHI9 NHI Reuse Guide and the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide.
Structure and key requirements
The OWASP entry follows the project's standard layout: a rating table based on the OWASP Risk Rating Methodology, a description, example scenarios, "How to Prevent", references and data points.
| Factor | NHI10 rating | OWASP's reasoning (paraphrased) |
|---|---|---|
| Exploitability | Hard | The threat agent must first gain access to the environment, so exploitation depends on a separate initial access vector. |
| Prevalence | Common | Developers often impersonate service accounts to debug issues. |
| Detectability | Hard | Most NHI providers offer no tooling to distinguish a workload assuming the NHI from a human doing so. |
| Technical impact | Low | Depends on the NHI's privilege; low where least privilege is adopted. |
| Business impact | Specific | Depends on what the NHI can reach. |
OWASP's five scenarios map to distinct control gaps:
| OWASP scenario | What goes wrong | Primary control |
|---|---|---|
| Administrator uses service account credentials in the console | Access beyond the person's role; actions logged under the service account | Block interactive sign-in for NHIs; named admin roles |
| Developer runs commands with a production NHI | Errors or unauthorised changes cannot be traced to a person | Logged impersonation or JIT elevation with a recorded human identity |
| Team shares an API token | One compromised laptop exposes the token; source of breach unclear | Personal tokens per human, workload tokens kept in the workload |
| Employee bypasses MFA or IP restrictions via an NHI | Policies on human accounts are sidestepped | Network and context conditions on NHIs themselves |
| Attacker uses NHI credentials for persistence | No MFA, no password changes, long dwell time | Short-lived credentials, anomaly detection on NHI use |
The four "How to Prevent" requirements are:
- Use dedicated identities: debugging and maintenance use dedicated human identities with appropriate roles and permissions.
- Audit and monitor NHI activity: use tools that audit and track NHI usage so human use is detectable and accountable.
- Use context-aware access controls: conditional access policies detect and block human access to NHIs based on suspicious patterns.
- Educate developers and administrators: train on the risks of manual NHI use and provide alternative access methods.
Identity and NHI requirements
The fix is not to stop humans acting with a workload's permissions in every case. Some tasks genuinely need them. The fix is that the human authenticates as themselves, with MFA, and the platform records both identities. The major platforms each provide a mechanism for this.
| Platform | Anti-pattern | Accountable alternative | What the log shows |
|---|---|---|---|
| Google Cloud | Downloading a service account key to a laptop | gcloud --impersonate-service-account, which needs iam.serviceAccounts.getAccessToken (in roles/iam.serviceAccountTokenCreator) and issues short-lived credentials | Audit log authenticationInfo.serviceAccountDelegationInfo records the delegation history and the real (first-party) principal; serviceAccountKeyName identifies a key when one is used |
| AWS | Using a pipeline IAM user's access keys from the CLI | Assume the role through the workforce identity provider and set a source identity (--source-identity, or the SAML SourceIdentity attribute); require it in the trust policy with sts:SetSourceIdentity and a condition on sts:SourceIdentity | CloudTrail requestParameters.sourceIdentity on AssumeRole, then userIdentity.sessionContext.sourceIdentity on every later call, carried through role chaining and immutable for the session |
| Microsoft Entra ID | Running scripts with a service principal's client secret, or using a user account as a service account | Managed identities or certificate-based service principals for workloads; Privileged Identity Management for humans who need the same rights | Service principal sign-ins log, separate from user sign-ins |
| Kubernetes | Extracting a service account token from a Secret to use with kubectl | User impersonation (kubectl --as) gated by the RBAC impersonate verb, granted narrowly | Audit events carry both user and impersonatedUser |
| Windows and Active Directory | Interactive or RDP logon with a service account | Group managed service accounts with no human-known password; deny interactive logon rights to service accounts | Security event 4624 with logon type 2 (interactive) or 10 (remote interactive) for a service account is a finding |
Three design rules follow from the table:
- No human-known secrets for workloads: if no person ever sees the credential, no person can borrow it. Prefer platform-issued identities (managed identities, attached service accounts, IAM roles on compute, gMSA). See the Workload Identity Federation Guide and the Group Managed Service Accounts (gMSA) Guide.
- Elevation, not borrowing: where a human needs workload-level rights during an incident, grant time-bound elevation of their own identity. See the JIT Access Guide and the Break-Glass Account Guide.
- Agents are a new grey zone: an AI coding assistant running on a developer's laptop with the developer's copy of a production token is human use of an NHI with an extra actor. Give agents their own identities rather than borrowed ones. See the Agent Identity and Access Guide.
Implementation steps
- Find the human use you already have (weeks 1 to 3): query 90 days of logs for NHI sign-ins that look human: console sign-ins by service accounts or IAM users tagged as automation, NHI API calls from corporate egress IPs, VPN ranges or user device user agents (browser, AWS CLI on a laptop), Windows logon types 2 and 10 for service accounts, and key creation events followed by downloads. List each case with the person, the NHI and the task they were doing.
- Classify the reasons: group findings into debugging production, emergency fixes, missing human role, tooling that only accepts a key, and habit. Each reason needs a different fix; blocking without fixing the first three causes outages and workarounds.
- Build the accountable path: create human roles for the recurring tasks, enable impersonation or role assumption with a recorded human identity, and set up a JIT or break-glass process with approval and a short duration. Test it with the teams who were found in step 1.
- Remove human-known credentials: rotate every NHI secret a person has seen, move workloads to platform-issued identities where possible, and in Google Cloud apply the constraints that disable service account key creation and upload (enforced by default for organisations created on or after 3 May 2024). See the Secrets Rotation Runbook Template.
- Apply preventive controls in audit mode first: run Entra Conditional Access for workload identities in report-only mode with a location condition (include any location, exclude the named locations the workload runs from), deploy "Deny log on locally" (
SeDenyInteractiveLogonRight) and "Deny log on through Remote Desktop Services" for service account groups to a pilot OU, and log rather than deny AWS role sessions without a source identity. - Enforce in rings: switch policies to enforcing for non-production, then lower-risk production, then the rest. Roll back by setting the Conditional Access policy back to report-only, unlinking the GPO, or removing the trust policy condition; each is a single change, so record who can make it.
- Train and publish the rule: a one-page standard ("never sign in as a machine; here is the fast alternative") delivered to engineering and operations, linked from the JIT request page and the incident runbook.
Small organisations can stop at steps 1, 3 and 4: removing human-known secrets and giving people an easy alternative removes most of the risk. Large organisations need steps 5 and 6 because they cannot review every engineer's behaviour by hand.
Evidence and assessment
OWASP rates detectability Hard, so the evidence pack has to show detection that actually works, not just a policy statement.
| Signal or metric | Source | Target |
|---|---|---|
| Console or interactive sign-ins by NHIs | Cloud console sign-in events, Entra service principal sign-ins, Windows event 4624 logon types 2 and 10 | Zero outside approved break-glass |
| NHI API calls from user devices or office egress | CloudTrail sourceIPAddress and userAgent, Google Cloud audit logs, SaaS audit logs | Zero, each case investigated |
| Privileged role sessions with a recorded human identity | CloudTrail sessionContext.sourceIdentity, Google Cloud serviceAccountDelegationInfo, Kubernetes impersonatedUser | 100% of human sessions on production roles |
| NHI secrets known to a person | Secrets inventory, key download events, shared vault entries | Falling to zero; each rotated after exposure |
| Median time to grant JIT access | PAM or PIM records | Minutes, so the shortcut is not faster |
| Detection to response time for human-use alerts | SIEM case records | Under one business day |
Assessors should sample five privileged NHIs and ask three questions for each: can a person obtain its credential today, has a person used it in the last 90 days, and would the logs show who that person was. A clean policy with no answer to the second question is not evidence.
Mapping to other frameworks
| Framework | Reference | Relevance to NHI10 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2(9) Restrictions on Use of Shared and Group Accounts | Shared tokens and service accounts used by people |
| NIST SP 800-53 Rev. 5 | IA-2 Identification and Authentication (Organizational Users); IA-2(1) Multi-factor Authentication to Privileged Accounts | Humans must authenticate as themselves, with MFA for privileged access |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication | Service identities kept for services |
| NIST SP 800-53 Rev. 5 | AU-3 Content of Audit Records; AC-6(9) Log Use of Privileged Functions; AU-6 Audit Record Review, Analysis, and Reporting | Logs must identify the individual, and be reviewed |
| MITRE ATT&CK | T1078.004 Valid Accounts: Cloud Accounts; T1550.001 Use Alternate Authentication Material: Application Access Token; T1098.001 Account Manipulation: Additional Cloud Credentials | Attacker use of NHIs for access and persistence, the OWASP fifth scenario |
| CIS Controls v8.1 | Control 5 Account Management (service account inventory); Control 6 Access Control Management | Inventory and dedicated administrative accounts |
| ISO/IEC 27001:2022 Annex A | 5.16 Identity management; 8.2 Privileged access rights; 8.15 Logging | Unique identities, controlled privilege, attributable logs |
Common pitfalls
- Blocking before building the alternative: denying console access to service accounts on day one, before human roles and JIT exist, sends engineers to worse workarounds such as keys copied into personal tooling.
- Treating impersonation as the problem: logged impersonation with a short-lived token is the accountable pattern. The problem is impersonation rights granted broadly, for example
roles/iam.serviceAccountTokenCreatorat project level or the Kubernetesimpersonateverb on all users. - Machine admin keys living with people: in the CISA Private-CISA GitHub leak, administrative AWS GovCloud keys sat in a contractor employee's public repository for about six months, with GitHub's secret blocking turned off; researchers suspect the repository was used to sync files between work and home computers. Keys a person can carry will travel with that person.
- Source identity optional: AWS records a source identity only if it is set; unless the trust policy requires it, sessions from people still look like automation.
- Conditional Access gaps: Entra Conditional Access for workload identities covers single-tenant service principals only, not managed identities or multitenant apps, and needs Workload Identities Premium. Plan access reviews and monitoring for the identities it does not cover.
- No rotation after exposure: once a person has seen or downloaded a secret, assume it has been copied. Moving the person to a new access path without rotating leaves the old credential valid.
Practitioner checklist
- Run a 90-day log query for NHI sign-ins and calls that look human, and record the person and task for each.
- Create named human roles for every recurring task that people were doing with an NHI.
- Provide JIT elevation or break-glass with approval, short duration and session logging.
- Require a recorded human identity on human sessions: AWS source identity, Google Cloud impersonation instead of keys, Kubernetes impersonation with a narrow
impersonategrant. - Remove human-known NHI secrets: platform-issued identities, gMSA, and the Google Cloud key creation and upload constraints.
- Deny interactive and RDP logon rights to service account groups, piloted on one OU first.
- Apply location-based Conditional Access to single-tenant service principals, starting in report-only mode.
- Alert on NHI use from user devices, office egress or browser user agents, and on console sign-ins by NHIs.
- Rotate every NHI credential a person has handled, and record the rotation.
- Publish a short standard and train engineering, operations and anyone configuring AI agents.
Standards and references
- OWASP: NHI10:2025 Human Use of NHI
- OWASP: Non-Human Identities Top 10
- NIST: SP 800-53 Rev. 5
- AWS: Monitor and control actions taken with assumed roles
- Google Cloud: Service account impersonation
- Google Cloud: Best practices for managing service account keys
- Microsoft Learn: Conditional Access for workload identities
- Microsoft Learn: Securing service accounts in Microsoft Entra ID
Related NHI Mgmt Group resources: Non-Human Identity (NHI) Guide · OWASP NHI Top 10 NHI4 Insecure Authentication Guide · OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide · Human vs Non-Human Identity · Privileged Access Management Guide