CME-805

Credential Rotation Policy

Harden Identity Unquantified evidence Preventive

Description

Enforce credential lifecycle limits through automated rotation of passwords, API keys, service account tokens, and secrets. Two distinct tiers of effectiveness: (1) OS-level password aging (chage on Linux, Group Policy on Windows) forces periodic password changes, typically every 90 days — this limits the maximum validity window of compromised credentials but provides minimal protection against immediate credential abuse since attackers typically exploit stolen credentials within hours. NIST SP 800-63B recommends against mandatory periodic rotation for human users due to the pattern of progressively weaker passwords (Password1!, Password2!). (2) Automated short-lived secret rotation via secrets managers (HashiCorp Vault dynamic secrets, AWS STS temporary credentials, Kubernetes service account token projection) with TTLs measured in hours — this genuinely limits the exploitation window because credentials may expire before an attacker can extract and replay them. The attenuation strength is directly proportional to the rotation frequency: 1-hour TTLs provide strong protection, 90-day aging provides weak protection.

CVSS Vector Impacts

Metric	Transition	Rationale
Attack Complexity (AC)	L → H	Effectiveness is proportional to rotation frequency. For automated short-lived secrets (Vault dynamic secrets with 1-hour TTL, STS temporary credentials), the credential may expire before an attacker can extract and replay it — requiring the attacker to maintain persistent access to the credential source rather than using a one-time theft. For 90-day password aging, the protection window is too large to prevent most credential abuse (attackers act within hours), providing only residual protection against very slow-developing compromises such as leaked credential databases discovered months after breach

CWE Relationships

CWE-262 CWE-263 CWE-798

Verification

Verify credential rotation enforcement via password aging (OS-level) and secret TTL policies (application-level)

$ grep '^PASS_MAX_DAYS' /etc/login.defs | grep -oE '[0-9]+'
# Expected: <=90

Platform: linux

$ chage -l root | grep 'Maximum' | grep -oE '[0-9]+'
# Expected: <=90

Platform: linux

$ net accounts | Select-String 'Maximum password age'
# Expected: Maximum password age (days) 90

Platform: windows

Remediation

linux Linux password aging via /etc/login.defs and chage


sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS	90/' /etc/login.defs
sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS	1/' /etc/login.defs
sed -i 's/^PASS_WARN_AGE.*/PASS_WARN_AGE	14/' /etc/login.defs
chage --maxdays 90 --mindays 1 --warndays 14 <username>

windows Windows password aging via net accounts


net accounts /maxpwage:90 /minpwage:1

Applicability (CVE 5.2.0 Schema)

Vendor	Product	CPEs	Platforms	Status
redhat	enterprise_linux	`cpe:2.3:o:redhat:enterprise_linux:8:::::::` `cpe:2.3:o:redhat:enterprise_linux:9:::::::` `cpe:2.3:o:redhat:enterprise_linux:10:::::::*`	All	applicable
microsoft	windows	`cpe:2.3:o:microsoft:windows_10::::::::` `cpe:2.3:o:microsoft:windows_11::::::::` `cpe:2.3:o:microsoft:windows_server_2019:::::::` `cpe:2.3:o:microsoft:windows_server_2022:::::::`	All	applicable