Secret Rotation 2026

Secrets rotate. The discipline.

Auto-rotation

Secret rotation is one of those security disciplines that everyone agrees is important and most teams skip. The reasons are predictable: rotation is operationally annoying, breaking change risk is real, and the team that does not rotate this quarter rarely gets a call about it. The fix is not "rotate more diligently"; it is automation that takes the human out of the loop.

What auto-rotation actually requires:

• AWS Secrets Manager rotation.: Native support for rotating database credentials, RDS credentials, RotateSecret-compatible custom rotators. The rotation runs on a schedule (typically 30 to 90 days), generates a new credential, updates the dependent system, and propagates the new value to consumers. Configuration is a few JSON fields per secret.
• Vault dynamic secrets.: HashiCorp Vault generates credentials on demand with short TTLs. The application requests a credential when it needs one; Vault provisions a temporary database user, returns the credential, expires it after the TTL. Rotation is implicit because credentials are short-lived; there is no long-lived secret to rotate.
• Cloud-native equivalents.: GCP Secret Manager rotation, Azure Key Vault rotation, similar patterns across providers. Each cloud has its own implementation; the pattern is the same: declare rotation policy, the platform handles the mechanics.
• Set and forget.: Once rotation is configured, the secret rotates automatically without team intervention. The team's job is verifying the rotation worked (monitoring for stale credentials and rotation failures); the rotation itself is the platform's job.
• Test rotation regularly.: The rotation policy is configured but the actual rotation may have bugs. Test it quarterly: trigger a rotation manually, verify it completes, verify dependent systems still work. The test catches the cases where the rotation succeeded in the secret store but failed to propagate.

Auto-rotation is the only sustainable model for secrets that need frequent rotation. Teams relying on manual processes drift; teams relying on automation maintain a constant state.

Manual rotation

Some secrets cannot be auto-rotated. Third-party API keys without rotation support, signing keys with custom propagation requirements, root credentials with high blast radius. For these, manual rotation is necessary. The discipline is making sure manual rotation actually happens on schedule.

• Quarterly cadence for most.: The default rotation cadence for non-auto-rotated secrets is quarterly. Some require more frequent rotation (PCI-scoped secrets every 90 days minimum); some can be annual (signing keys with long lifecycles). The cadence is per secret, documented per secret.
• Documented process per secret.: The runbook for rotating each secret is written down: the steps to obtain a new credential, the steps to update each dependent system, the steps to verify the new credential works, the steps to invalidate the old one. The runbook is reviewable; the engineer rotating does not have to invent the procedure.
• Tracked in a calendar.: The rotation schedule is on a shared calendar. Each rotation has an owner, a date, a runbook link, an expected duration. Skipped rotations are visible; nobody can quietly let one slip.
• Tested before deployment.: The rotation runbook is tested in dev or staging before being run in production. The first time the team rotates a specific secret, they discover the runbook gaps. The discovery happens in dev, not in prod at 3am.
• For secrets without auto-support.: Manual rotation is the fallback for the cases where auto-rotation is not possible. The default should be auto-rotation; manual rotation is the exception that requires explicit documentation.

Manual rotation discipline is what keeps the cases that cannot be automated from becoming long-term liabilities. It is more operational work than auto-rotation but it is bounded.

Emergency

The third rotation type is emergency: rotating a credential immediately because it might have been compromised. Emergency rotation is rare but high-stakes; the discipline is making sure the team can execute it within minutes when needed.

• On suspicion of compromise: rotate immediately.: A leaked credential, a suspicious access log entry, a third-party tool report of an exposed key. Any reasonable suspicion triggers emergency rotation. The cost of unnecessary rotation is small; the cost of waiting is large.
• Tested via game days.: The team practices emergency rotation on a regular cadence (quarterly is typical). The practice run is against a non-critical secret; the discipline being tested is the procedure, not the actual urgency. After enough practice, the team can execute under real stress.
• Runbooks ready.: The emergency rotation runbook is available, current, and known to the on-call. The on-call should not have to find the runbook during the incident; they should know where it is and what it says.
• Cross-team coordination practiced.: Some emergency rotations require coordination across teams (the secret is used by services owned by different teams). The coordination is practiced ahead of time so the team knows who to page and how.
• Audit trail preserved.: The emergency rotation is captured: when it fired, why, who executed, what was rotated, when the new credential was confirmed working. The audit trail is part of the incident retro and the compliance record.

Auto-rotation, manual rotation discipline, and emergency rotation readiness together produce the secrets posture that withstands modern threats. Nova AI Ops tracks rotation status per secret across the major secret stores, surfaces the cases where rotation is overdue, and runs the emergency-rotation game-day exercises that keep the team's response capability sharp.