Non-Human Identity Security: The Attack Surface Security Teams Underestimate
Non-human identities (NHIs) are the service accounts, API keys, OAuth tokens, machine certificates, workload identities, and CI/CD pipeline credentials that allow applications, automation, and infrastructure to authenticate against each other. They outnumber human identities by 45 to 1 in the average enterprise. They are typically far more privileged than any individual human user. And they are almost universally under-secured compared to human identity controls.
The consequence is predictable: machine identity attacks are now involved in 40% of cloud breaches. Attackers who compromise a CI/CD pipeline token, an over-privileged service account, or a hardcoded API key in a code repository gain access that bypasses MFA, conditional access policies, and most UEBA detection logic, because non-human identity activity looks like normal automation to defenders who have not instrumented it specifically.
This guide covers the full NHI security lifecycle: discovery, classification, least-privilege scoping, rotation automation, and detection engineering for machine identity attacks.
The Non-Human Identity Problem: Why It Gets Worse Every Year
Human identity security has matured substantially over the past decade. Modern IAM programs manage the human identity lifecycle with automated provisioning, regular access reviews, MFA enforcement, and UEBA-based anomaly detection. Non-human identity management has not kept pace, for structural reasons.
NHIs are created by developers, DevOps teams, and automation pipelines, not by IAM administrators. A developer creating a GitHub Actions workflow needs a secret to authenticate against a cloud provider. They generate a long-lived API key with broad permissions because scoping it correctly requires understanding IAM policy syntax they may not know. They store it in a GitHub secret, sometimes in a .env file that gets committed, sometimes in an environment variable that is logged during debugging. Six months later, the developer who created it has moved to a different team. The key still exists, still has broad permissions, and no one is monitoring it.
This pattern, repeated at scale across thousands of developers, automation tools, and microservices, produces the NHI sprawl problem that most enterprise security teams have not fully quantified. HashiCorp's 2025 State of Infrastructure Security report found that 68% of organizations cannot inventory all non-human identities in their environment. You cannot secure what you cannot see.
Secret sprawl
API keys, passwords, and certificates stored in code repositories, CI/CD environment variables, configuration files, Slack messages, and developer laptops rather than centralized secrets management systems.
Over-privileged service accounts
Service accounts granted administrator or owner roles during initial deployment and never scoped down, because developers default to the widest permission that makes the thing work.
No rotation
Long-lived credentials that have never been rotated, in some cases for years, giving attackers who obtain them persistent access until the credential is discovered and revoked.
No monitoring
Most organizations apply UEBA and anomaly detection to human identity activity but have no equivalent monitoring for non-human identity access patterns.
Blast radius amplification
A single compromised NHI with broad permissions can provide access across multiple systems simultaneously, often without triggering alerts designed around human access patterns.
NHI Discovery: Finding What You Do Not Know You Have
The first step in NHI security is understanding the scope of the problem. Discovery must cover four categories: secrets stored in code repositories and CI/CD systems; service accounts and workload identities in cloud providers and identity platforms; machine certificates and SSH keys; and OAuth and API tokens issued to third-party integrations.
For code repositories, tools like GitHub Advanced Security (secret scanning), GitGuardian, and Trufflehog scan repositories for secrets committed in code, configuration files, and git history. Git history scanning is important because a secret deleted from the current branch may still exist in prior commits. GitGuardian's 2025 State of Secrets Sprawl report found over 12 million secrets detected in public GitHub repositories in 2024 alone.
For cloud environments, IAM Access Advisor (AWS), Permissions Management (Azure), and Policy Analyzer (GCP) identify service accounts, their permission scopes, and their last-used dates. Cloud Security Posture Management (CSPM) tools including Wiz, Orca, and Prisma Cloud can flag over-privileged identities across multi-cloud environments. For centralized secrets management, platforms like HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault provide inventories of managed secrets with access audit logs, but they only cover secrets that have been onboarded to the system.
The discovery output should produce a classification by sensitivity: credentials with admin or owner-level access to production systems are Tier 1 and require immediate remediation; credentials with broad read access to sensitive data are Tier 2; all others are Tier 3.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Least Privilege for Non-Human Identities
Applying least privilege to NHIs requires understanding what each identity actually needs to do, then constructing the minimum permission set that enables it. In practice, this requires collaboration between security engineers and the development teams who build and operate the systems using these identities.
For cloud IAM, use resource-scoped permissions rather than account-wide policies. An S3 access key that needs to read one specific bucket should have a policy scoped to that bucket ARN, not s3:* on all resources. AWS IAM Access Analyzer generates least-privilege policies based on actual access history, which eliminates the guesswork. For GCP and Azure, equivalent tools exist in their IAM policy analysis capabilities.
For service accounts in Kubernetes, use RBAC with namespace-scoped roles rather than ClusterRoles where possible. Avoid mounting service account tokens in pods that do not require API access. Enable projected token volumes with bounded lifetimes rather than using long-lived service account tokens.
For CI/CD systems, use short-lived OIDC tokens rather than long-lived API keys where the CI/CD platform and cloud provider support it. GitHub Actions OIDC federation with AWS IAM, GCP Workload Identity Federation, and Azure Managed Identities enables CI/CD workflows to assume cloud roles without storing any long-lived credential in GitHub Secrets. This eliminates an entire category of secret sprawl risk for cloud operations.
Secrets Rotation Automation
Manual rotation of secrets does not scale. The average enterprise has thousands of NHIs; a security team that manually rotates credentials is doing so infrequently, under pressure, and with high error risk. The goal is automated rotation with zero-downtime credential handoff.
Centralized secrets management platforms handle rotation in two models: managed rotation (the platform rotates the credential directly, such as AWS Secrets Manager rotating an RDS database password by calling the RDS API and updating the secret) and application-assisted rotation (the application checks for a new secret version on each use, allowing the platform to rotate without requiring a deployment). Both models require application code to retrieve secrets at runtime from the secrets manager rather than reading them from environment variables or configuration files at startup.
For credentials that cannot be rotated automatically, establish a maximum credential age policy enforced by tooling rather than human discipline. HashiCorp Vault supports lease-based credentials that expire and must be renewed; expired credentials that are not renewed are automatically revoked. This is preferable to relying on humans to remember to rotate credentials on a schedule.
Rotation events should be logged in your SIEM with alerts for rotation failures. A credential that cannot be rotated (because an application is hardcoded to a specific key and cannot accept a new one) is a remediation target, not a rotation exception.
Detection Engineering for Non-Human Identity Attacks
Most SOC detection logic is calibrated for human identity behavior: logins at unusual hours, impossible travel, new device authentication. NHI attacks look different: service accounts accessing resources they have never accessed before, API keys used from unexpected IP addresses, tokens used at rates inconsistent with their normal automation patterns.
Core detection rules for NHI attacks include: service account access to resources outside its historical baseline (requires per-identity behavioral baselining, not just alert-on-admin-access rules); API key usage from IP addresses not associated with the application's normal infrastructure (requires infrastructure IP inventory); token usage rate anomalies (a CI/CD token used 1,000 times in an hour is suspicious if its normal pattern is 10 times per hour); and lateral access chains where a single NHI accesses multiple distinct systems in a short time window.
For cloud environments, AWS CloudTrail, Azure Monitor, and GCP Cloud Audit Logs provide the raw telemetry for NHI detection. Feeding this into a SIEM with entity-level analytics (Splunk ES, Microsoft Sentinel, Chronicle) enables per-identity behavioral baselining. UEBA platforms like Varonis and Securonix increasingly include NHI behavioral modeling as a distinct analytics category.
The most valuable single detection rule is flagging any use of a credential from a git repository scan finding. GitGuardian and similar tools identify exposed secrets; correlating those credential identifiers against your authentication logs tells you whether the exposed credential has already been used by an attacker.
The bottom line
Non-human identities are the attack surface that most enterprise security programs have systematically under-invested in while focusing on human identity hardening. The gap is measurable: 45 NHIs for every human identity, 68% of organizations unable to inventory them, 40% of cloud breaches involving NHI compromise. The remediation path is the same as it was for human identities 15 years ago: discover what exists, apply least privilege, automate rotation, and instrument detection. The difference is that NHI security requires developer workflow integration, not just security team tooling.
Frequently asked questions
What counts as a non-human identity?
Non-human identities include service accounts (AD service accounts, cloud IAM service accounts), API keys and tokens, OAuth 2.0 client credentials, machine certificates used for mutual TLS authentication, SSH keys used by automation, CI/CD pipeline secrets (GitHub Actions secrets, Jenkins credentials), workload identities (Kubernetes service accounts, Managed Identities), and any credential used by an application or automated process rather than a human user.
What is the most common NHI attack vector?
Exposed secrets in code repositories are the most common initial access vector for NHI attacks. Developers commit API keys, passwords, and tokens to source control, often accidentally, and these credentials are then discoverable by anyone with repository access or, for public repositories, by anyone on the internet. Secret scanning in CI/CD pipelines and repository-level secret detection (GitHub Advanced Security, GitGuardian) are the most direct controls.
How do OIDC tokens replace long-lived API keys in CI/CD?
OIDC federation allows a CI/CD platform (like GitHub Actions) to issue a short-lived JWT that proves the workflow's identity to a cloud provider without using a long-lived API key. The cloud provider validates the JWT signature against the CI/CD platform's JWKS endpoint and grants a short-lived cloud credential. The credential expires when the workflow ends, eliminating the persistent access risk of a stored API key. GitHub Actions OIDC works with AWS IAM, GCP Workload Identity Federation, and Azure Federated Credentials.
How should we handle legacy service accounts that cannot use modern secrets management?
Legacy systems that cannot retrieve secrets dynamically from a secrets manager require a different approach. Store their credentials in the secrets manager as a central record of truth, enforce maximum credential ages via policy (for example, a 90-day maximum with alerts at 60 days), and treat any rotation failure as a remediation ticket, not an exception. Long-term, factor the cost of secrets management modernization into your technical debt prioritization.
What is the difference between a Managed Identity and a service account?
A Managed Identity (Azure) or Workload Identity (GCP) is a cloud-provider-managed identity where the cloud platform handles credential issuance and rotation transparently. The application retrieves short-lived tokens from the platform's metadata service at runtime. A service account is an identity you create and manage, with credentials you must store and rotate yourself. Managed Identities eliminate the credential management burden for workloads running on the cloud platform's compute infrastructure.
How do you detect a compromised service account if its activity looks like normal automation?
Detection requires per-identity behavioral baselining, not just threshold rules. A compromised service account will typically exhibit one or more of: access to resources outside its historical scope, usage from an IP address not in its normal infrastructure footprint, activity at times inconsistent with its normal automation schedule, elevated request volumes, or lateral movement to systems it has not previously accessed. UEBA platforms or SIEM rules built on CloudTrail/Azure Monitor/GCP audit logs with entity-level analytics can surface these deviations.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.