OWASP NHI Top 10 Remediation Playbook

The problem

Every enterprise runs on a hidden workforce. Service accounts push code to production. API keys authorize million-dollar transactions. OAuth tokens link SaaS applications into sprawling dependency chains. Kubernetes pods spin up with credentials provisioned months ago by engineers who have since left. The average enterprise maintains 82 machine identities per human user. Fewer than 5% of the permissions granted to them are actually used. Over half are classified high-risk. Ninety-nine percent of cloud service accounts are over-permissioned. The Cloud Security Alliance 2025 NHI survey measured 80% of identity-related breaches as involving compromised non-human identities. Credential abuse is the number-one initial attack vector. The cost per breach now averages $4.88 million.

OWASP published the Non-Human Identities Top 10 in 2025 — the first industry-standard framework for classifying and remediating NHI-specific risks. The existing OWASP Top 10 (for web applications) does not address the unique attack surface of machine credentials, service accounts, and automated workload identities. The new ten ranks Improper Offboarding (NHI1), Secret Leakage (NHI2), Vulnerable Third-Party NHIs (NHI3), Insecure Authentication (NHI4), Overprivileged NHIs (NHI5), Insecure Cloud Deployment (NHI6), Long-Lived Secrets (NHI7), Environment Isolation Failure (NHI8), NHI Reuse (NHI9), and Human Use of NHIs (NHI10).

This is the remediation playbook. For each of the ten risks: what it is, how to detect it in your environment, the fix steps with code patterns, the verification procedure, and the 90-day quick-start plan that gets the worst exposure closed in four weeks.

What most people get wrong

Mistake one: treating “delete the credential from the .env file” as remediation for secret leakage. A credential that was ever in a git repository — even briefly, on a feature branch that nobody else pulled — is in git history. Forever. GitHub Secret Scanning catches 23.8 million credential leaks per year. 25% year-over-year growth. 70% of secrets leaked in 2022 are still active three years later. The remediation for NHI2 is not “edit the file” — it is “assume the credential is harvested, rotate it immediately, scan git history with truffleHog or gitleaks, then centralize secrets in a vault so the next commit never carries one.” Treating the symptom (the file) instead of the credential leaves an active key in attacker storage.

Mistake two: scoping permissions by “what we might need someday” instead of “what we used last quarter.” 99% of cloud service accounts are over-permissioned. Less than 5% of granted permissions are actually used. The remediation pattern is permission right-sizing: analyze 90 days of CloudTrail / Cloud Audit Log / Azure Activity Log, generate a least-privilege policy that matches actual usage, deploy it as the new policy, monitor for the rare denied operations and add only the truly-needed permissions back. Overprivilege amplifies every other NHI risk: a leaked admin credential is a full account takeover; a leaked read-only credential is contained damage. The book has the script for permission analysis on AWS, GCP, and Azure.

A working approach

Each of the ten risks gets the same five-section treatment in the book. The walkthrough below is the structure, with the highest-priority remediations highlighted.

1. Risk description — what the vulnerability is, why it matters, real attack scenarios. NHI1 (Improper Offboarding) is the most prevalent because it is the most invisible: orphaned service accounts created during a proof-of-concept that was abandoned 18 months ago still hold production credentials. NHI2 (Secret Leakage) has 23.8M leaks/year on GitHub, and 70% of historic leaks remain active. NHI5 (Overprivileged) has 99% prevalence in cloud environments.

2. Detection checklist — specific actionable items to identify the risk:

# NHI1 detection — orphaned credentials
- Query cloud IAM for service accounts with last-used > 90 days
- Cross-reference creator user_id against active employee directory
- Map NHI -> service dependency; flag NHIs with no live service
- Audit CI/CD pipeline credential stores for references to deleted services
- Inspect resource inventories for stopped infrastructure with active IAM bindings

3. Fix steps — ordered remediation with code:

// NHI1 Step 1: Establish an NHI Ownership Registry
interface NHIRecord {
  nhi_id: string;
  credential_type: 'api_key' | 'service_account' | 'oauth_token';
  owner_email: string;
  service_name: string;
  created_at: string;
  last_used_at: string;
  lifecycle_state: 'active' | 'review' | 'deprecated' | 'revoked';
  review_date: string;
  auto_revoke_after_days: number;
}

// NHI1 Step 2: Automated lifecycle triggers
async function handleOffboardingEvent(event: OffboardingEvent) {
  const nhis = await registry.findByOwner(event.entity_id);
  for (const nhi of nhis) {
    await registry.updateState(nhi.nhi_id, 'review'); // 7-day grace
    await notifyDependents(nhi);
    scheduleAutoRevoke(nhi, 7);
  }
}

4. Verification procedure — how to confirm the fix works:

# NHI1 verification
- Run a synthetic orphan: create + abandon a test NHI, verify auto-revoke fires
- Pull weekly orphan reports from the registry; target 0 orphans
- Audit a random sample of 50 NHIs: each has a live owner + dependent service
- Verify last-used scanning runs on schedule

5. trustauthority.ai coverage — how the Trust Authority platform addresses the risk natively. 7 of the 10 risks have native coverage; the remaining 3 (NHI3 Vulnerable Third-Party, NHI6 Insecure Cloud Deployment, NHI10 Human Use) are organizational/process risks that get partial coverage.

The Tier 1 quick-start sequence (Weeks 1–4) addresses the three highest-impact risks where credentials may already be compromised:

Week	Risk	Action
1	NHI2 — Secret Leakage	Scan all repos (truffleHog or gitleaks), rotate every leaked credential
1–2	NHI1 — Improper Offboarding	Inventory all NHIs, identify orphans, disable everything with no live owner
2–4	NHI7 — Long-Lived Secrets	Implement lifetime policies, begin automated rotation, set hard expirations

Tier 2 (Months 2–3) tackles overprivileged credentials (NHI5), insecure authentication (NHI4), and CI/CD pipelines (NHI6). Tier 3 (Months 3–6) completes environment isolation (NHI8), eliminates NHI reuse (NHI9), tightens third-party access (NHI3), and addresses human use of NHIs (NHI10).

90-day target metrics:

• Active leaked secrets: 0
• Orphaned NHIs: 0
• Credentials older than 90 days: 0
• Wildcard permissions: 0
• Credential-to-workload ratio: 1:1
• Cross-environment shared credentials: 0
• CI/CD static credentials: 0

Where this scales

The walkthrough above is the playbook spine. The full book covers six more dimensions:

• Each of the 10 risks in detail — every chapter is ~6 pages with the five-section treatment (description, detection, fix, verification, trustauthority.ai coverage). The book is structured for reference, not linear reading.
• NHI4 Insecure Authentication migrations — workload identity federation patterns for AWS IRSA, GCP Workload Identity, Azure Managed Identity. mTLS deployment patterns. Short-lived OIDC tokens replacing API keys.
• NHI5 Overprivileged right-sizing scripts — CloudTrail / Cloud Audit Log / Azure Activity Log query patterns that generate least-privilege policies from actual 90-day usage data.
• NHI6 Insecure Cloud Deployment — the OIDC-based CI/CD authentication pattern that replaces pipeline static credentials. Audience claim restrictions. Per-pipeline trust policies.
• NHI7 Long-Lived Secrets — zero-downtime rotation flow, ephemeral credentials, expiration-enforcement patterns, monitoring dashboards.
• Comprehensive remediation roadmap — the three-tier prioritization framework (Immediate / Structural / Governance), the 90-day quick-start plan, NHI governance program organizational structure, and the metrics that prove the program is working.

Every code example has been tested in production. The 82:1 NHI-to-human ratio, the 99% overprivilege prevalence, the 23.8M GitHub leaks per year — these are operational measurements from CSA, Astrix, and GitHub Security research, not estimates.

Included with the book

• nhi-audit-spreadsheet.csv — the audit spreadsheet template used in real NHI assessments. Columns for risk classification, ownership, lifecycle state, last-used, action plan. Drop into the first week of the 90-day rollout.

Get the full picture

Readers of this also chose

Questions readers ask

How is this different from the CISO Guide (Book 18)?

Book 18 is the strategic risk framework — three-layer protocol model, 21 attack vectors, NIST AI RMF scoring, compliance mapping, board presentation. This book is the operational remediation playbook — for each of the OWASP NHI Top 10 risks, exactly what to detect, how to fix, how to verify. Read together, the CISO guide gives you the board approval; this book gives you the work.

Do I need trustauthority.ai to remediate these risks?

No. Every fix step works with standard tooling: AWS IAM, GCP IAM, Azure RBAC, GitHub Secret Scanning, HashiCorp Vault, AWS Secrets Manager, OIDC providers. trustauthority.ai is the reference implementation we run; the book documents how it addresses each risk for context. The playbook itself is platform-neutral.

What if my organization runs on-premises, not in the cloud?

On-prem NHI risks map closely to cloud NHI risks: service accounts, API keys, certificates, automation credentials. The fix patterns translate. The book covers the on-prem variations (HashiCorp Vault for secrets, internal CA for certificates, Active Directory service accounts) alongside the cloud-native patterns.

How do I prioritize across 10 risks at once?

The three-tier prioritization framework in Chapter 12. Tier 1 (Weeks 1–4): credentials may already be compromised — leaked secrets, orphans, long-lived secrets. Tier 2 (Months 2–3): reduce blast radius — overprivilege, insecure auth, CI/CD pipelines. Tier 3 (Months 3–6): governance maturity — environment isolation, reuse, third-party, human use. The book also has the 90-day quick-start plan if you need a more compressed schedule.

What's the refund policy?

Lemon Squeezy's standard refund window applies. The refund link is in the receipt email.