Scope
This guide addresses the governance of non-human identities (NHIs) — such as service accounts, API keys, OAuth tokens, machine certificates, and bot credentials — within compliance frameworks. You'll learn how to inventory, classify, and govern these identities to prevent outages or compliance issues.
What's included:
- Mapping NHI governance to PCI DSS v4.0.1, SOC 2 Type II, and ISO/IEC 27001:2022
- Certificate lifecycle management for machine identities
- Implementation patterns for credential rotation and access reviews
- Integration with existing IAM and PAM tools
What's not covered: Human identity management, SSO configuration, or federated authentication protocols.
Key Concepts and Definitions
Non-human identity (NHI): Any credential that authenticates a process, service, or automated workflow rather than a person. This includes:
- Service accounts with static passwords
- API keys and tokens
- Machine certificates (TLS, mTLS, code signing)
- OAuth client credentials
- SSH keys for automated deployment
- Database connection strings with embedded credentials
Ghost identities: NHIs created for a specific project or integration, then abandoned when the project ends or the engineer who created them leaves. These accounts continue running with full privileges and no oversight.
Certificate expiration cascade: When multiple machine certificates expire simultaneously because they were issued during the same deployment window. Organizations that rapidly adopted cloud services between 2020 and 2022 face this risk now, as those certificates reach their validity limits.
Requirements Breakdown
PCI DSS v4.0.1
Requirement 8.2.2: Authenticate all access to system components, including non-human identities. Your quarterly access reviews must cover service accounts, not just employee credentials.
Requirement 8.3.2: Strong cryptography must protect authentication credentials during transmission. API keys sent over HTTP or hardcoded in configuration files violate this requirement.
Requirement 10.2: Audit logs must capture all actions by privileged accounts. Service accounts often have elevated privileges but generate logs that don't tie back to a responsible individual.
SOC 2 Type II
CC6.1 (Logical and Physical Access Controls): Your control descriptions must explain how you grant, review, and revoke access for non-human identities. If your access review process only covers human users, you have a control gap.
CC6.2 (Authentication): Document how service accounts authenticate and how you protect those credentials. A vault solution alone isn't sufficient — you need rotation policies and access logging.
ISO/IEC 27001:2022
Control 5.15 (Access Control): Establish and document access control rules for all identity types. Service accounts need the same classification and approval workflow as human accounts.
Control 5.17 (Authentication Information): Implement controls for the lifecycle management of authentication credentials. This means tracking creation, rotation, and deactivation of API keys and certificates.
Implementation Guidance
Phase 1: Discovery (Weeks 1-4)
Start by identifying what you have. Non-human identities outnumber human ones by a factor of ten to one in most large organizations, so manual tracking won't scale.
Query your certificate stores for expiration dates:
openssl x509 -in cert.pem -noout -enddate
If you issued certificates between 2020 and 2022, prioritize those expiring within 90 days. An expired certificate took Microsoft Teams offline for millions of users in 2020 — your service dependencies are equally fragile.
Check your secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for:
- Static credentials older than 90 days
- Credentials with no rotation policy
- API keys with no expiration date
Scan your repositories for hardcoded credentials. This violates PCI DSS Requirement 8.3.2 and creates immediate compliance exposure.
Phase 2: Classification (Weeks 5-8)
Map each NHI to a data classification and system criticality tier:
| Tier | Access Scope | Rotation Frequency | Example |
|---|---|---|---|
| Critical | Production data, payment systems | 30 days | Payment gateway API key |
| High | Production infrastructure | 60 days | Database service account |
| Medium | Development/staging | 90 days | CI/CD deployment token |
| Low | Non-production, public data | 180 days | Log aggregation read-only key |
This mapping determines your rotation schedule and monitoring requirements. Critical-tier credentials require automated rotation and real-time alerting on usage anomalies.
Phase 3: Governance Integration (Weeks 9-16)
Extend your existing access review process to include NHIs:
Quarterly reviews (SOC 2 CC6.1): Export all service accounts and their permissions. Route to the application owner, not the engineer who created them. If the owner left the company, that's a deactivation candidate.
Ownership assignment: Every NHI needs a documented owner responsible for renewal, rotation, and deactivation. Use your CMDB or asset inventory to link credentials to services, then services to owners.
Automated rotation: Implement rotation for all Critical and High-tier credentials. Your secrets manager should handle the rotation and notify dependent services. Test your rotation process in non-production first — a failed rotation can cause the same outage as an expiration.
Phase 4: Monitoring and Response (Ongoing)
Configure alerts for:
- Certificate expiration within 30/60/90 days
- API key usage from unexpected IP ranges or geographic locations
- Service account authentication failures (potential compromise)
- Credential access without corresponding service activity
Integrate NHI events into your SIEM. The SolarWinds breach exploited compromised service credentials that went undetected because no one was monitoring for anomalous NHI behavior.
Common Pitfalls
Treating NHIs as "technical debt": Your auditor doesn't care that service accounts are harder to manage than human ones. PCI DSS Requirement 8.2.2 applies equally to both.
Relying on manual spreadsheets: You can't track thousands of credentials in a spreadsheet. Invest in tooling that integrates with your secrets manager and certificate authority.
Ignoring third-party NHIs: The Okta breach demonstrated that your vendors' service accounts can compromise your environment. Include third-party integrations in your NHI inventory.
No break-glass process: When a certificate expires unexpectedly, you need a documented process to issue an emergency replacement without waiting for the standard approval workflow.
Rotation without testing: Rotating a credential that breaks a critical integration is worse than not rotating at all. Build automated tests that verify service functionality after rotation.
Quick Reference Table
| Task | Frequency | Owner | Compliance Mapping |
|---|---|---|---|
| Certificate expiration scan | Weekly | Security Ops | PCI DSS 8.3.2, ISO 27001 5.17 |
| NHI access review | Quarterly | Application Owners | SOC 2 CC6.1, PCI DSS 8.2.2 |
| Critical credential rotation | 30 days | DevOps + Security | PCI DSS 8.3.2, ISO 27001 5.17 |
| High credential rotation | 60 days | DevOps | ISO 27001 5.17 |
| NHI usage anomaly review | Daily | SOC | SOC 2 CC6.2 |
| Deactivation of orphaned NHIs | Monthly | Security Ops | PCI DSS 8.2.2, ISO 27001 5.15 |
| Break-glass procedure test | Quarterly | Security + DevOps | SOC 2 CC6.1 |
Your compliance program already has processes for human identity governance. Extend those same controls to service accounts before your next audit finds the gap — or before an expired certificate takes your production environment offline.
