Skip to main content
← All controls
IA-5(1) / A.9.2.4 / CIS-5.4 NIST SP 800-53 Rev 5

How do you manage long-lived access keys / service account credentials?

Demonstrate that the organization maintains an inventory of long-lived credentials, enforces rotation and expiration policies, monitors usage for anomalies, and remediates stale or unused credentials in accordance with defined lifecycle standards.

Description

What this control does

Long-lived access keys and service account credentials (e.g., AWS access keys, API tokens, service principal secrets) present persistent attack surface if compromised. This control establishes lifecycle management practices including rotation schedules, usage monitoring, deactivation of unused credentials, and secure storage mechanisms. Organizations implement automated rotation where possible, enforce maximum credential age policies, and maintain inventories to prevent credential sprawl. Effective management reduces the window of opportunity for credential-based attacks and limits blast radius of compromised keys.

Control objective

What auditing this proves

Demonstrate that the organization maintains an inventory of long-lived credentials, enforces rotation and expiration policies, monitors usage for anomalies, and remediates stale or unused credentials in accordance with defined lifecycle standards.

Associated risks

Risks this control addresses

  • Compromised long-lived credentials enable persistent unauthorized access to cloud resources, APIs, or service accounts without requiring re-authentication
  • Stale or orphaned credentials embedded in legacy code, configurations, or employee devices remain active attack vectors after projects end or personnel depart
  • Lack of rotation allows attackers who obtain credentials through historical breaches, log exposures, or insider threat to maintain access indefinitely
  • Credentials stored in plaintext in code repositories, CI/CD pipelines, or developer workstations leak through repository scraping or insider exfiltration
  • Excessive credential age increases likelihood that keys have been inadvertently exposed through logging, error messages, or support tickets without detection
  • Inability to correlate credential usage to specific workloads or services prevents detection of unauthorized or anomalous API calls
  • Service accounts with long-lived credentials lacking multi-factor protection bypass compensating authentication controls applied to human users

Testing procedure

How an auditor verifies this control

  1. Obtain and review the organization's credential management policy documenting rotation schedules, maximum age limits, and deactivation procedures for long-lived access keys and service account credentials
  2. Request a complete inventory of active long-lived credentials across cloud platforms (AWS IAM access keys, Azure service principals, GCP service account keys), API gateways, and SaaS integrations for a representative sample of environments
  3. Select a sample of 15-25 credentials spanning multiple credential types, service accounts, and creation dates from the inventory
  4. For each sampled credential, retrieve creation date, last rotation date, last usage timestamp, and associated permissions or roles from platform audit logs and IAM configuration exports
  5. Identify credentials exceeding the organization's defined maximum age threshold and verify whether approved exceptions exist with documented business justification and compensating controls
  6. Review automated rotation mechanisms (e.g., AWS Secrets Manager rotation lambdas, Azure Key Vault rotation policies, HashiCorp Vault dynamic secrets) and test configuration for at least two service account types to confirm functional rotation
  7. Examine monitoring and alerting configurations to verify that credential usage anomalies (unusual API calls, geographic origin, access patterns) trigger security team notifications, and review sample alerts from the past 90 days
  8. Trace at least three instances where credentials were deactivated due to age, inactivity, or project termination, and validate that deactivation occurred within policy-defined timeframes and that dependent services were appropriately migrated
Evidence required IAM configuration exports showing credential creation and rotation dates, credential inventory spreadsheets or CMDB exports with metadata, screenshots of automated rotation policies in secrets management platforms, audit logs demonstrating credential usage patterns and last-used timestamps, monitoring alert configurations and historical alert samples for credential anomalies, documented exceptions with approvals for credentials exceeding maximum age, change tickets or workflow records evidencing credential deactivation and service migration activities.
Pass criteria All sampled credentials comply with defined maximum age policies or have documented approved exceptions with compensating controls, automated rotation is functionally configured for credential types supporting it, monitoring detects and alerts on usage anomalies, and evidence confirms timely deactivation of credentials associated with terminated projects or inactive services.