Skip to main content
emnode / learn
Compliance Medium severity

AWS Security Hub · SecretsManager

SecretsManager.4: Secrets lack a rotation schedule

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub SecretsManager.4 check?

SecretsManager.4 checks that secrets are rotated within a specified number of days (default 90). It passes only when RotationEnabled is true and the current version is younger than the configured AutomaticallyAfterDays — so a long rotation interval can still fail it even with rotation on.

Why does SecretsManager.4 matter?

Rotation exists to bound how long a leaked credential stays useful. A secret that technically has rotation enabled but on a 365-day schedule still leaves a compromised password valid for a year. Every workload that ever held the value keeps a copy, so a stale credential's blast radius grows with its age — and PCI DSS 8.3.9, SOC 2, and ISO 27001 all expect a documented, enforced rotation lifecycle.

How do I fix SecretsManager.4?

  1. Enable rotation and set the interval at or below the threshold the control checks (default 90 days).
  2. Tighten the interval further for your highest-value secrets — production databases, signing keys.
  3. Confirm rotations are completing so the current version actually stays within the window.

Remediation script · bash

# Enable rotation on an RDS-backed secret with the AWS-managed Lambda, 30-day cadence.
aws secretsmanager rotate-secret \
  --secret-id prod/payments/db-master \
  --rotation-lambda-arn arn:aws:lambda:eu-west-1:123456789012:function:SecretsManagerRDSPostgreSQLRotationSingleUser \
  --rotation-rules AutomaticallyAfterDays=30

# Schedule deletion of stale secrets behind a recovery window (never force-delete in prod).
NOW=$(date -u +%FT%TZ)
for arn in $(aws secretsmanager list-secrets \
  --query "SecretList[?LastAccessedDate<='$(date -u -d '90 days ago' +%FT%TZ)'].ARN" \
  --output text); do
  aws secretsmanager delete-secret --secret-id "$arn" --recovery-window-in-days 7
done

# Alarm so the next failed rotation pages a human, not the next audit.
aws cloudwatch put-metric-alarm \
  --alarm-name secrets-rotation-failed --namespace AWS/Lambda --metric-name Errors \
  --dimensions Name=FunctionName,Value=RotatePaymentsDbMaster \
  --statistic Sum --period 3600 --evaluation-periods 1 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:security-oncall

Full walkthrough (console steps, edge cases and verification) in the lesson Manage secrets (rotation and hygiene).

Is SecretsManager.4 a false positive?

Enabling rotation is not enough on its own. If the configured interval exceeds the control's threshold, SecretsManager.4 still fails even though SecretsManager.1 passes.

Full lesson Manage secrets (rotation and hygiene) Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for SecretsManager controls ↗ Check your own account for SecretsManager.4 →
Part of the learning path Lock down access

More SecretsManager controls