OWASP NHI5 Overprivileged NHI: Practitioner Guide

Service accounts, roles, API tokens and OAuth apps are routinely granted far more access than their job needs, so a single compromised machine credential becomes a compromised cloud account. OWASP ranks this as NHI5:2025 Overprivileged NHI in the Non-Human Identities Top 10. This guide explains what OWASP says about the risk, how to turn it into enforceable requirements, and how to right-size permissions in AWS, Google Cloud, Azure and Kubernetes without breaking production. It is written for cloud security engineers, platform and IAM teams, and auditors who need to show that machine identities follow least privilege in practice, not just in policy.

Key takeaways

Severe impact, hard to exploit alone. OWASP rates NHI5 hard to exploit (an attacker needs a foothold first) but widespread and severe once used, because excess rights turn any foothold into escalation or account takeover.
Usage data beats guesswork. Right-size from observed activity: AWS IAM Access Analyzer unused access findings, Google Cloud role recommendations and last-accessed data show what an identity actually uses.
Guardrails stop the next grant. Organisation-level deny policies (AWS SCPs and RCPs, Azure Policy, Google Cloud organisation policies) cap what any NHI can receive, which reviews alone cannot.
Hidden escalation paths count as privilege. Rights to edit access policies, impersonate other service accounts or create workloads are as dangerous as admin, and they rarely show up as "admin" in a review.
Measure it continuously. Track the share of NHIs holding admin or basic roles, unused permissions per identity and time to remediate, rather than running a once-a-year certification.

What it is and who it applies to

OWASP describes NHI5 as non-human identities (service accounts, API tokens, workload identities and similar) holding more privileges than their function requires, which enlarges the blast radius when they are compromised. The OWASP page lists the consequences as access to sensitive data, privilege escalation, lateral movement, malware installation and, in the worst case, takeover of the cloud account when the identity is tied to an administrator or root-level grant.

OWASP rating factor	NHI5 rating	What it means in practice
Exploitability	Hard	An attacker must first obtain the credential or run code as the workload (RCE, leaked key, supply chain).
Prevalence	Widespread	Broad managed roles, default service accounts and "temporary" admin grants are found in most estates.
Detectability	Average	Native tools show unused permissions, but escalation paths need graph analysis.
Technical impact	Severe	Data exfiltration, persistence through new credentials or roles, account takeover.
Business impact	Specific	Depends on what the identity can reach.

The OWASP example scenarios are useful test cases for any estate: a web server process running as a Linux user that can read unrelated applications; a CI server instance with full administrator rights when it only needs container service permissions; an OAuth application given broad write access when it needs read access to one storage location; and a database service account whose administrative rights hand over the cloud account when the database is breached. OWASP also cites third-party research for prevalence, including the Cloud Security Alliance NHI report finding over-privileged accounts behind about 37% of NHI-related incidents and Datadog's State of the Cloud 2024 finding that a third of Google Cloud VMs had sensitive project-level permissions. Treat those figures as the cited publishers' numbers.

The risk applies to every team that creates machine identities: platform and cloud engineering (instance roles, managed identities, service accounts), application teams (database users, OAuth clients, API keys), CI/CD owners (deployment roles, covered further in NHI6) and SaaS administrators (integration tokens). For the broader category, see the Non-Human Identity (NHI) Guide.

Structure and key requirements

OWASP gives four prevention measures. Turned into requirements an auditor can test, they look like this (our Access Control Policy Template gives matching policy wording):

OWASP prevention	Requirement to adopt	Native mechanisms
Apply least privilege; avoid admin unless truly necessary	No NHI holds AdministratorAccess, Owner, Editor or cluster-admin without a recorded exception and expiry date. Permissions are scoped to named resources, not `*`.	AWS customer managed policies with resource ARNs and conditions; Google Cloud predefined or custom roles on the narrowest resource; Azure RBAC at resource group or resource scope; Kubernetes namespaced Role and RoleBinding
Regularly audit and review permissions	Unused permissions are reviewed at least quarterly and removed after a defined window (for example 90 days unused).	IAM Access Analyzer unused access findings and policy generation; Google Cloud IAM recommender; last accessed information
Organisation-wide preventive guardrails such as deny policies	A baseline of deny guardrails applies to every account, subscription or project, including blocks on creating long-lived keys and on privileged role assignment outside the IAM pipeline.	AWS SCPs, RCPs and permissions boundaries; Azure Policy and deny assignments; Google Cloud organisation policy constraints and IAM deny policies
Just-in-time access for elevated privilege	Elevated rights for automation or break-glass are time bound and approved, not standing.	Short session duration on assumable roles; Entra PIM for groups; approval-gated pipeline environments

Two details matter when you design guardrails. AWS documents that SCPs grant nothing on their own: they set the maximum available permissions, and effective access is the intersection of SCPs, RCPs and identity or resource policies. AWS also documents that SCPs do not restrict the management account or service-linked roles, so do not run workloads in the management account and do not assume an SCP protects it. Test guardrails on a pilot OU before attaching them at the root.

Identity and NHI requirements

Overprivilege is rarely one bad policy. It is a set of patterns that differ by platform, and each needs its own control.

Patterns to hunt for

Broad managed roles: AWS AdministratorAccess or PowerUserAccess on instance and Lambda roles; Google Cloud basic roles (Owner, Editor) on service accounts, which Google's recommender flags as HIGH severity at project, folder or organisation level; Azure Owner or Contributor at subscription scope. See the AWS IAM Policies and Roles Guide and the Google Cloud IAM and Service Accounts Guide.
Wildcards: "Action": "*", "Resource": "*", s3:* or Kubernetes rules with verbs: ["*"]. Wildcards also grant actions the provider adds later.
Permission to change permissions: iam:PassRole on any role, iam:AttachRolePolicy, iam:CreatePolicyVersion, Google Cloud iam.serviceAccounts.actAs or token creator rights on other service accounts, Azure Microsoft.Authorization/roleAssignments/write, Kubernetes escalate, bind and impersonate verbs.
Management plane that reaches data: the Azure Key Vault Contributor escalation showed that Microsoft.KeyVault/vaults/write on vaults using the access policy model lets the holder grant itself read access to every secret. Microsoft's recommended fix is the Azure RBAC permission model for vaults.
Over-scoped tokens and signed URLs: the Microsoft SAS token exposure involved an account-level SAS with full control rather than read access to one container, with its expiry later extended to 2051. Scope SAS tokens, PATs and API keys to one resource, read-only where possible, with short expiry.
Build credentials with write access to release paths: in the Amazon Q Developer extension compromise, AWS described a GitHub token in a CodeBuild configuration as inappropriately scoped, and that access let an attacker push code that flowed into a release.
Kubernetes service accounts: ClusterRoleBindings to cluster-admin, list or watch on Secrets (which returns secret contents), and pod create rights, which let a subject mount any service account in the namespace. Disable token automount where the pod does not call the API. See the Kubernetes RBAC Guide.
OAuth and SaaS integrations: apps granted tenant-wide scopes such as full mailbox or Files.ReadWrite.All when they need one site or folder. See the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide.

Choosing the right control

Situation	Prefer	Trade-off
Stable workload with predictable API calls	Generated least-privilege policy from observed activity, scoped to resource ARNs	Misses rare paths (quarterly jobs, disaster recovery); keep an observation window covering them
Many teams creating roles	Permissions boundaries or custom role catalogue plus deny guardrails	Platform team owns boundary design; slower first deployment
Rare high-privilege automation (migrations, recovery)	Separate role assumed just in time with approval and short session	Adds an approval step to runbooks
Third-party SaaS or vendor access	Dedicated identity per vendor with resource-scoped grants and external ID or federation	Vendor may request broad scopes by default; negotiate
Small organisation, one cloud account	Native recommender plus a short deny list (no key creation, no admin to workloads)	Less granular than a CIEM, but cheap and quick
Large multi-cloud estate	CIEM for cross-cloud effective permission and escalation path analysis	Licence cost and tuning; still needs owners to act on findings

For tool selection and cross-cloud analysis, see the Cloud PAM and CIEM Guide. For time-bound elevation, see the JIT Access Guide.

Implementation steps

Inventory and assign owners. List every role, service account, managed identity, app registration, database account and API token, with an accountable human owner and the workload it serves. Identities without an owner go to a quarantine list. See the Service Account Inventory Template.
Find the worst first. Query for NHIs with admin or basic roles, wildcard actions, permission-management rights and cross-account or cross-project impersonation. Rank by what they can reach (production data, identity plane, key material), not by count.
Turn on usage analysis. Enable IAM Access Analyzer unused access analysis for the organisation (AWS documents it covers unused roles, unused access keys and unused service and action level permissions). In Google Cloud, use role recommendations: they draw on up to 90 days of usage, never apply themselves, and do not cover bindings with IAM conditions. In Azure, use sign-in and activity logs for service principals and managed identities.
Deploy guardrails in audit mode first. Write deny guardrails (no iam:CreateAccessKey outside a break-glass path, no admin policy attachment to workload roles, no public storage grants), attach them to a pilot OU or folder, and watch CloudTrail or audit logs for denials for two to four weeks before widening.
Right-size in rings. Start with non-production, then low-risk production workloads. Replace broad grants with generated or hand-written scoped policies; AWS advises testing generated policies before production. Keep the old policy version available for rollback rather than deleting it.
Split privilege. Separate the identity a workload runs as from the identity that deploys it, and move rare high-privilege tasks to a separate role assumed just in time.
Roll back safely. If an access denied error appears after a change, restore the previous policy version for that identity only, record the missing permission, and add it narrowly. Never roll back a guardrail organisation-wide to fix one workload.
Make it continuous. Add policy checks in infrastructure as code (block wildcards and admin managed policies at pull request), schedule recommender and analyser exports, and review exceptions at their expiry date.

Evidence and assessment

What to monitor: privilege changes to NHIs (AWS AttachRolePolicy, PutRolePolicy, CreatePolicyVersion, UpdateAssumeRolePolicy; Google Cloud SetIamPolicy in Admin Activity audit logs; Azure role assignment writes in the Activity Log; Kubernetes RoleBinding and ClusterRoleBinding creation), first use of a dormant permission, use of impersonation or token creation, and NHIs calling services they have never called before. These map to ATT&CK techniques such as T1098.003 Additional Cloud Roles, T1098.001 Additional Cloud Credentials and T1078.004 Cloud Accounts.

Metrics that show it is working:

Percentage of NHIs holding admin, Owner, Editor or cluster-admin (target: near zero, each with a dated exception).
Percentage of granted permissions used in the last 90 days, per identity and overall.
Number of NHIs with a privilege escalation path to admin (from CIEM or graph analysis).
Mean time to remediate an unused access or overprivilege finding.
Percentage of NHIs with a named owner and a last review date inside policy.
Count of guardrail denials by account, as an early sign of drift or of a workload that needs a scoped exception.

Audit evidence: exported recommender and analyser findings with closure dates, guardrail policy documents and their attachment points, exception register with approvals and expiry, and pull request checks that block wildcard policies.

Mapping to other frameworks

Framework	Reference	Relevance to NHI5
NIST SP 800-53 Rev. 5	AC-6 Least Privilege; AC-6(1) Authorize Access to Security Functions; AC-6(5) Privileged Accounts; AC-6(7) Review of User Privileges; AC-6(9) Log Use of Privileged Functions	Core least-privilege, review and logging requirements, applicable to system and service accounts
NIST SP 800-53 Rev. 5	AC-2 Account Management	Ownership, authorisation and review of every account including service accounts
NIST CSF 2.0	PR.AA-05; PR.AA-01	Permissions managed with least privilege and separation of duties; identities for services managed
CIS Controls v8.1	5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts; 5.5 Establish and Maintain an Inventory of Service Accounts; 6.8 Define and Maintain Role-Based Access Control	Inventory, admin restriction and role design
ISO/IEC 27001:2022 Annex A	5.15 Access control; 5.18 Access rights; 8.2 Privileged access rights	Policy, provisioning and review of access, privileged rights restricted and managed
MITRE ATT&CK v20	T1078.004 Cloud Accounts; T1098.003 Additional Cloud Roles; T1550.001 Application Access Token	How attackers use and extend overprivileged identities
OWASP NHI Top 10 2025	NHI3, NHI6, NHI9	Overprivilege amplifies third-party, pipeline and reused identities

Related OWASP NHI risks: overprivileged deployment identities are the core of the OWASP NHI Top 10 NHI6 Insecure Cloud Deployment Configurations Guide, and one identity shared by many workloads accumulates the union of their permissions, covered in the OWASP NHI Top 10 NHI9 NHI Reuse Guide.

Common pitfalls

Starting broad and never narrowing. AWS itself suggests managed policies as a starting point, but without a scheduled narrowing step the broad policy becomes permanent.
Reviewing names, not effective permissions. A role called "reader" with iam:PassRole on * is an admin. Review the effective permission set and escalation paths, as the Key Vault Contributor case showed.
Removing permissions without enough history. A 30-day window deletes rights used by monthly or quarterly jobs, which causes outages and pushes teams back to admin. Use 90 days or longer for infrequent workloads and keep rollback ready.
Trusting guardrails where they do not apply. SCPs do not cover the AWS management account or service-linked roles; conditional bindings get no Google Cloud recommendations. Know the gaps.
Treating tokens as out of scope. PATs, SAS tokens and OAuth grants carry privileges too, and they are often created outside the IAM process. Include them in the inventory and scope reviews.
One identity for many jobs. Shared service accounts must be granted everything every consumer needs, which defeats least privilege before the first review.

Practitioner checklist

Inventory every NHI with an owner, purpose and environment, and quarantine ownerless identities.
Remove admin, Owner, Editor and cluster-admin from workload identities, or record a dated exception.
Enable IAM Access Analyzer unused access, Google Cloud role recommendations and equivalent Azure activity reporting.
Deploy deny guardrails in a pilot OU or folder, monitor denials, then widen.
Block wildcard actions and admin managed policies in infrastructure as code checks.
Hunt for permission-management and impersonation rights held by NHIs and remove or isolate them.
Scope SAS tokens, PATs and API keys to single resources with short expiry.
Move rare high-privilege tasks to just-in-time roles with short sessions.
Alert on privilege changes to NHIs and on first use of dormant permissions.
Report the NHI admin percentage and unused permission ratio to leadership each quarter.

OWASP NHI Top 10 NHI5 Overprivileged NHI Guide