Database credentials rotated per policy

Database credentials that are never rotated represent an indefinite exposure window: a breach discovered six months late, a departed employee, or a compromised developer machine may have leaked those credentials with no way to detect it retroactively. NIST IA-5 requires authenticator management including credential lifetime controls. PCI-DSS v4.0 Req-8.6.3 requires passwords/passphrases for application and system accounts to be changed periodically per a targeted risk analysis and protected against misuse — the correct control for database service-account credentials. CWE-522 covers insufficiently protected credentials, which includes stale credentials that cannot be revoked because no rotation process exists. Without documented last-rotation dates, you cannot demonstrate compliance or reason about the risk surface.

Document last rotation dates and next scheduled rotation for every database credential set. For managed database services, prefer automated rotation over manual processes.

# ROTATION_SCHEDULE.md
## Database Credentials
| Environment | Last rotated | Next due   | Method    |
|-------------|-------------|------------|----------|
| Production  | 2026-01-15  | 2026-04-15 | Manual   |
| Staging     | 2026-01-15  | 2026-04-15 | Manual   |

Enable automated rotation on AWS RDS:

aws rds modify-db-instance \
  --db-instance-identifier prod-db \
  --manage-master-user-password
# Rotates credentials in Secrets Manager automatically

Manual rotation process: Generate new password → update Secrets Manager → trigger a rolling deployment → verify connectivity → archive old password with deactivation date. Document each step with a timestamp.