Skip to main content
emnode / learn
Compliance Medium severity

AWS Security Hub · SecretsManager

SecretsManager.2: Rotation-configured secrets should rotate successfully

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub SecretsManager.2 check?

SecretsManager.2 checks the RotationOccurringAsScheduled field on each secret that has rotation enabled. It passes when the most recent scheduled rotation completed successfully and on time, and fails when a rotation that should have happened didn't. Secrets with rotation disabled are not evaluated.

Why does SecretsManager.2 matter?

A failed rotation is silent by default — applications keep reading the old AWSCURRENT value, so nothing breaks today. But the secret is now ageing past the window you committed to, and the compromise-limiting benefit of rotation is gone while every dashboard still reports rotation enabled. The credentials this happens to are, by definition, your highest-value ones, so the blast radius is concentrated exactly where it hurts most.

How do I fix SecretsManager.2?

  1. Inspect the rotation Lambda's logs for the failing secret — common causes are permissions, timeouts, or no network path to the database.
  2. Fix the root cause and trigger a manual rotation to confirm it now reaches AWSCURRENT.
  3. Add a CloudWatch alarm on rotation failures so the next one is not silent.

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.2 a false positive?

A green RotationEnabled flag does not mean rotation is working — it only means it is configured. SecretsManager.2 is the control that catches the rotation that is quietly erroring out behind that flag.

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.2 →
Part of the learning path Lock down access

More SecretsManager controls