Non-Human Identity Security: Service Accounts and Machine Identities

Non-human identities — service accounts, API keys, certificates, tokens, and bot credentials — represent the fastest-growing and least-governed segment of enterprise identity infrastructure. This page documents the structure, classification, regulatory context, and operational mechanics of non-human identity (NHI) security as a distinct discipline within identity and access management. It covers how machine identities differ from human identities in lifecycle management, how they are exploited, and where governance frameworks address them.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

Non-human identities are credentials, tokens, or cryptographic artifacts that authorize a process, application, workload, or automated agent — rather than a human user — to access systems and data. The category encompasses service accounts in directory services, API keys, OAuth tokens, SSH keys, X.509 certificates, secrets stored in vaults or environment variables, and the identities assigned to cloud workloads such as AWS IAM roles or Azure Managed Identities.

NIST SP 800-63 Digital Identity Guidelines addresses human subscriber identity with defined assurance levels but does not extend the same enrollment and verification model to non-human entities. This structural gap means NHI governance largely falls under organizational policy and framework controls rather than a single authoritative federal standard. NIST SP 800-53 Rev 5, control families IA (Identification and Authentication) and AC (Access Control), do address system and service account requirements (NIST SP 800-53 Rev 5, §IA-2, §IA-5, §AC-6), but implementation specifics are left to system owners.

The scope of NHI security as a practice includes:

• Discovery and inventory of all non-human credentials in an environment
• Lifecycle governance — provisioning, rotation, and decommissioning
• Privilege management — enforcing least-privilege on machine accounts
• Secrets management — secure storage and retrieval of credentials
• Detection and response — identifying anomalous machine-identity behavior

Core mechanics or structure

Non-human identities authenticate through one of four primary mechanisms: shared secrets (passwords, API keys), asymmetric key pairs (SSH, code-signing certificates), short-lived tokens (OAuth 2.0 bearer tokens, Kerberos service tickets), or platform-managed identity bindings (cloud provider IAM roles attached to compute resources).

Service accounts in Active Directory or LDAP-based directories function as domain objects assigned passwords and group memberships. Microsoft's Group Managed Service Accounts (gMSA) automate password rotation for Windows services, addressing a long-standing gap where service account passwords were routinely set to "never expire" to avoid operational disruption. When a service account is granted Domain Admin rights — a misconfiguration documented repeatedly in breach reports — the blast radius of a single compromised credential becomes environment-wide.

Secrets (API keys, tokens, database credentials) are embedded in application code, configuration files, container images, or CI/CD pipeline variables. When not managed through a dedicated secrets management system, they accumulate as static, long-lived credentials. GitGuardian's 2023 State of Secrets Sprawl report documented over 10 million secrets exposed in public GitHub repositories in a single year, illustrating the scale of unmanaged NHI credential exposure.

Certificates rely on a Public Key Infrastructure (PKI) model. Each certificate has a defined validity period. When certificate inventories are not maintained, expiration causes unexpected outages; when revocation infrastructure fails, compromised certificates remain trusted. The NIST SP 800-57 series on key management establishes lifecycle guidance for cryptographic keys and certificates.

Cloud workload identities — such as AWS IAM roles with attached policies, Google Cloud service accounts, or Azure Managed Identities — bind identity to a compute resource at the platform level rather than requiring an embedded credential. This model reduces secrets sprawl but introduces a separate risk: over-permissioned IAM roles granted to Lambda functions, EC2 instances, or Kubernetes pods can be exploited via server-side request forgery (SSRF) to access cloud metadata services and obtain temporary credentials.

The interaction between privileged access management controls and NHI management is structural: PAM systems that govern human privileged accounts often have separate or absent workflows for service account vaulting, creating an adjacent unprotected surface.

Causal relationships or drivers

Three structural forces drive NHI proliferation faster than governance processes can absorb.

Cloud-native architecture multiplies machine identity count. A containerized microservices deployment may instantiate hundreds of workload identities where a monolithic predecessor required a handful of service accounts. Kubernetes alone introduces service accounts, secrets, ConfigMaps, and role bindings as native constructs requiring governance.

DevOps and CI/CD automation creates credentials at pipeline speed. Every pipeline stage — source control, build, test, deploy — may authenticate to downstream systems using tokens or keys generated automatically, sometimes without formal provisioning review. The Cybersecurity and Infrastructure Security Agency (CISA) has noted CI/CD pipeline compromise as an attack vector in supply chain guidance (CISA Defending Continuous Integration/Continuous Delivery Environments, 2023).

Organizational opacity results from NHIs being created by application teams, infrastructure engineers, and automated provisioning scripts — not through centralized IAM processes. Unlike human identities that pass through HR onboarding and offboarding workflows, machine identities have no equivalent lifecycle anchor. When the application or team that created a service account is retired, the account typically persists.

The zero-trust identity model treats every identity — human or machine — as untrusted by default and requiring continuous verification. This architectural requirement specifically elevates NHI governance because perimeter-based trust often implicitly extended to internal service accounts.

Classification boundaries

Non-human identities separate into distinct subtypes with different risk profiles and governance requirements:

Service accounts: Directory objects used by applications and scheduled tasks to authenticate to resources. Long-lived by design; governance gap arises when passwords are static. Subject to NIST SP 800-53 §IA-5(1) password management controls.

API keys and access tokens: Credentials issued by APIs to authorize application-to-application communication. Range from long-lived static keys (high risk) to short-lived JWT or OAuth tokens (lower risk when properly scoped). Governed under OAuth and OpenID Connect standards where applicable.

SSH keys: Asymmetric keypairs used for administrative access to servers and network infrastructure. Authorized_keys files on servers function as a distributed access control list outside directory services. CIS Benchmark controls for Linux systems address SSH key management.

X.509 certificates: Used for mutual TLS authentication, code signing, and device identity. Governed by PKI policies under the CA/Browser Forum baseline requirements and enterprise Certificate Policy documents. Federal systems are subject to FPKI (Federal Public Key Infrastructure) requirements.

Cloud platform identities: IAM roles, service principals, and managed identities in AWS, Azure, or GCP. Controlled through cloud provider IAM policy language. Misconfigurations in these identities are a primary vector documented in cloud breach analyses.

Robotic Process Automation (RPA) credentials: Credentials used by software bots executing business processes. Often provisioned with human-equivalent access to legacy systems that lack API interfaces, creating high-privilege machine accounts with minimal monitoring.

The distinction between NHI subtypes is not merely taxonomic — each subtype requires different rotation mechanics, different discovery methods, and different detection logic. Conflating them into a single "service account" category is a governance failure pattern seen in organizations that apply human IAM policy uniformly.

Tradeoffs and tensions

Rotation frequency vs. operational stability: Frequent credential rotation reduces the window of exploitability for a compromised secret but introduces operational risk. Applications that cache credentials in memory or configuration files can fail when the underlying secret rotates without synchronized application redeployment. This tension is why service account passwords are set to non-expiring in an estimated majority of enterprise environments — a practice that directly contradicts NIST SP 800-53 §IA-5(1) guidance on authenticator management.

Short-lived tokens vs. dependency on authentication infrastructure: Short-lived tokens (OAuth bearer tokens with 15-minute expiry, for example) reduce exposure duration but create a hard dependency on token issuance infrastructure. If the authorization server is unavailable, all dependent workloads lose authentication capability simultaneously.

Centralized secrets management vs. platform-native identity: Centralized vault-based secrets management provides a single governance and audit point but requires all consuming applications to integrate with the vault API. Platform-native identities (cloud IAM roles) avoid credential handling entirely but are provider-specific and create governance fragmentation in multi-cloud environments.

Least-privilege enforcement vs. developer velocity: Enforcing least-privilege on service accounts and API keys requires understanding the exact permissions each workload requires — an analysis that adds friction to deployment pipelines. Organizations operating under identity governance and administration frameworks must balance review overhead against deployment speed.

Common misconceptions

"Service accounts are low-risk because they don't belong to humans." Service accounts are among the highest-value targets in enterprise environments precisely because they authenticate automatically without MFA challenges, often carry elevated permissions, and are rarely monitored for behavioral anomalies. The 2020 SolarWinds supply chain compromise exploited a service account (SAML token forgery against federated identity infrastructure) to move laterally across victim networks — a pattern documented in the CISA Emergency Directive 21-01.

"API keys are only an external-facing risk." Internal API keys used for service-to-service communication within a network perimeter are equally exploitable. An attacker with access to any internal workload can extract API keys from environment variables or process memory and use them laterally.

"Cloud IAM roles eliminate credential risk." Platform-managed identities remove the need to rotate static credentials but introduce the SSRF/metadata service attack vector. AWS Instance Metadata Service v1 (IMDSv1) allowed any process on an EC2 instance to retrieve temporary credentials without requiring authentication; AWS documented the transition to IMDSv2 to require a session-oriented PUT request as a countermeasure, but IMDSv1 remained the default for legacy workloads.

"Certificates manage themselves through auto-renewal." Automated certificate issuance through ACME-based CAs (such as Let's Encrypt) works reliably for internet-facing systems but does not extend automatically to internal PKI, mutual TLS between services, or code-signing workflows. A single missed renewal in a chain of internal certificates can cascade into authentication failures across dependent services.

Checklist or steps

The following operational sequence reflects the standard phases of NHI security program implementation as described in NIST SP 800-53 Rev 5 control requirements and CIS Controls v8:

1. Inventory all non-human identities: Enumerate service accounts in directory services, API keys across code repositories and vaults, SSH keys in authorized_keys files, certificates in PKI and load balancer configurations, and cloud IAM roles and service principals. Discovery must extend to shadow IT and CI/CD systems.

2. Classify by privilege level and exposure: Assign each NHI a risk tier based on whether it has privileged access (admin, domain admin, root, or equivalent cloud permissions), cross-boundary access (across network segments, cloud accounts, or organizational units), or external exposure (internet-facing endpoints).

3. Eliminate orphaned credentials: Identify service accounts with no active application dependency, API keys with no recent usage (cloud provider access logs typically retain 90 days of API call history), and certificates issued to decommissioned systems. Revoke and delete.

4. Enforce rotation schedules or transition to short-lived credentials: Establish maximum validity periods for static credentials aligned with NIST SP 800-57 recommendations for cryptographic key lifetimes. Where possible, replace static keys with dynamic, short-lived tokens.

5. Vault all secrets: Route secret retrieval through a centralized secrets management system rather than storing credentials in environment variables, configuration files, or code repositories. Apply access policies requiring workload authentication before secret retrieval.

6. Apply least-privilege to all NHI permissions: Audit permissions assigned to each service account, IAM role, and API key. Remove permissions not exercised within a defined lookback window. Document business justification for any retained elevated permissions.

7. Instrument for behavioral monitoring: Establish baseline behavioral patterns for each NHI (typical source IPs, call volumes, target resources). Configure alerting for deviations — a service account authenticating from a new host, or an API key accessed outside business hours, are anomaly indicators consistent with lateral movement.

8. Integrate NHI lifecycle with application lifecycle: Establish provisioning and deprovisioning gates in deployment pipelines so that NHI credentials are created only through approved requests and are automatically decommissioned when the associated workload is retired.

Reference table or matrix

References

• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-63-3 — Digital Identity Guidelines
• NIST SP 800-57 Part 1 Rev 5 — Recommendation for Key Management
• CISA — Defending CI/CD Environments (2023)
• CISA Emergency Directive 21-01 — SolarWinds Orion
• AWS Instance Metadata Service v2 Documentation
• CIS Controls v8 — Center for Internet Security
• RFC 6749 — The OAuth 2.0 Authorization Framework (IETF)
• CA/Browser Forum Baseline Requirements for TLS Certificates
• NIST National Vulnerability Database