IAM-010 Service Account and Non-Human Identity Management
Description
Service accounts, API keys, and other non-human identities are inventoried and managed with the same rigour as human accounts. Each non-human identity has a documented owner, a defined scope of access, and a rotation or expiry policy. Unused service accounts are revoked. Non-human identities are not shared across services or environments.
Rationale
Service accounts and API keys are frequently over-provisioned, long-lived, and poorly tracked. They represent a significant attack surface and are a common source of lateral movement in breaches.
Applicability (9 profiles)
Framework Mappings (15)
| DCS-09 | Equipment Identification | partial |
| IAM-03 | Identity Inventory | informative |
| DCS-09 | Equipment Identification | partial |
| IAM-03 | Identity Inventory | informative |
| HIPAA-164.312.a.1 | Access Control | informative |
| 5.16 | Identity management | informative |
| AML.M0027 | Single-User AI Agent Permissions Configuration | partial |
| NIS2-CIR-11.1 | Access Control Policy | informative |
| NIS2-CIR-11.5 | Identification | informative |
| IA-3 | Device Identification and Authentication | partial |
| IA-8 | Identification and Authentication (Non-organizational Users) | partial |
| IA-9 | Service Identification and Authentication | full |
| ASI03 | Identity and Privilege Abuse | partial |
| ASI07 | Insecure Inter-Agent Communication | informative |
| LLM03 | Excessive Agency | informative |
Evidence (2)
Service account and non-human identity inventory showing each account's owner, defined access scope, and rotation or expiry policy.
Example: AWS IAM service role export, GCP service account inventory, or an internal CMDB/spreadsheet listing all service accounts and API keys with columns for: account name, owning team, systems it can access, last rotation date, and expiry date or rotation interval.
Test: Export the service account inventory from IAM and cross-reference with a manually maintained register if one exists. Verify: (1) every service account has a named owner (team or individual), (2) no service account has been inactive for more than the policy-defined period without documented justification, (3) API key rotation dates are within the policy-defined interval, (4) no service account is shared across services or environments.
Audit log showing recent activity (or confirmed inactivity) for each service account, enabling detection of dormant accounts that should be revoked.
Example: AWS CloudTrail last-used report for IAM roles/users, GCP IAM Recommender last-authenticated export, or equivalent log query output showing the most recent action timestamp for every service account over a 90-day window.
Test: Run a last-used query against every identity platform holding non-human identities, using the credential or last-activity report the platform produces. Verify: (1) an identity with no activity for more than 90 days is either disabled or carries a documented active justification, (2) an identity used from an unexpected source network or region resolves to a change record or an alert, (3) every identity in the inventory appears in the report, (4) an identity in the report that is absent from the inventory is raised as a finding.
Questions (3)
Are service accounts, API keys and other non-human identities recorded in an inventory?
Every non-human identity should have a named team or individual as owner. Unowned or undocumented service accounts are a significant risk. The inventory must be kept current, not just created once.
How frequently are API keys and service account credentials rotated?
Automated rotation is strongly preferred. Long-lived, non-rotating credentials significantly increase the impact of a credential exposure. Rotation should also occur immediately upon any suspected compromise.
What does each non-human identity entry record?
Options run from the most commonly recorded to the least. An unowned service account is the one nobody revokes. A shared one turns every compromise into a compromise of every service that uses it.