{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}{{ badge.value }}
{{ summaryAnnouncement }}

Rotation window unavailable.

Secrets rotation planning inputs
Use a dual-secret path only when consumers can accept old and new values during validation.
Planning metadata only; do not enter passwords, tokens, private keys, or authorization headers.
Choose the type that best describes the operational validation path.
The planner is local and does not connect to the selected manager.
The owner appears in every execution-ledger row.
Use one consumer per line or separate names with commas.
Review displayed timestamps when the window crosses a daylight-saving change.
From 0 to 3,650 days.
d
Use the applicable policy or manager schedule, not a universal interval.
d
Turn off for a single-value cutover that needs a maintenance window.
{{ supports_overlap ? 'Enabled' : 'Disabled' }}
From 0 to 336 hours.
h
Validation under four hours is flagged for delayed-consumer risk.
h
The canonical model uses zero hold when overlap is unavailable.
h
Use one verifiable check per line.
Make the threshold actionable for the on-call owner.
Turn this option on when break-glass path verified is required.
{{ break_glass_verified ? 'Enabled' : 'Disabled' }}
Turn this option on when rollback credential available until revoke is required.
{{ rollback_credential_retained ? 'Enabled' : 'Disabled' }}
Neutral default: 0 minutes.
min
Neutral default: 0 hours.
h
Neutral default: 0 hours.
h
Neutral default: blank.
Neutral default: blank. Do not use a location that accepts credential material.
{{ briefExportStatus }}
Rotation brief
{{ row.label }}{{ row.value }}
Stop/go gates
  1. {{ gate }}
Plan review
  • {{ flag }}
{{ chartExportStatus }}

The chart renderer is unavailable. The same checkpoint data remains available in the execution ledger.

{{ ledgerExportStatus }}
StageTimeOwnerActionExit gateFallbackCopy
{{ row.stage }}{{ row.time_label }}{{ row.owner }}{{ row.action }}{{ row.exit_gate }}{{ row.fallback }}

Introduction:

Creating a replacement credential is only the middle of a secret rotation. The change is complete when every legitimate consumer uses the replacement, the previous value no longer grants access, and the evidence explains who approved, performed, checked, and closed the work.

Secrets include API keys, database passwords, OAuth client secrets, webhook signing values, TLS private keys, and credentials injected into workloads. They often spread farther than expected: a key may be read by a web service, a delayed batch job, a deployment system, a partner integration, and an emergency runbook. Missing one reader can create an outage when the old value is revoked; leaving old trust in place can preserve the exposure that rotation was meant to end.

Stages and proof needed in a secret rotation
StageQuestion to settleUseful evidence
InventoryWhich systems read, cache, or distribute the credential?Owner list, dependency map, access policy, audit path
CreateDoes the replacement have the intended scope and lifetime?Version metadata, least-privilege review, expiry or lease
DistributeCan every consumer receive or reload the replacement?Deployment status, synchronization state, rollout record
ValidateDoes real authentication succeed without a new error pattern?Smoke tests, callback checks, connection refresh, audit reads
RevokeHas old trust actually ended?Old-value rejection and monitored stale-use attempts

The safest cutover pattern depends on what the consumer and secret manager support. A dual-secret window lets old and new values coexist while readers move. A single-value credential needs a coordinated maintenance cutover because updating it can briefly break new connections. Alternating users can preserve database availability but require permission parity between the two principals. Dynamic secrets replace periodic static rotation with short-lived leases that must be renewed or reissued.

Routine rotation and emergency revocation have different priorities. Routine work can prepare, distribute, validate, promote, hold, and revoke in order. Suspected compromise changes the sequence: blocking or revoking exposed access may take priority over a long validation window, followed by forced reissue and investigation. A normal schedule should not be used to delay containment.

Rotation frequency is a policy decision, not a universal number. Secret type, exposure, manager capability, consumer behavior, contractual rules, and incident history all matter. The plan should contain safe identifiers and evidence metadata only. Passwords, tokens, private keys, authorization headers, and other credential material do not belong in planning fields, tickets, exports, or screenshots.

How to Use This Tool:

Freeze the consumer scope and rollback authority before assigning times to the cutover.

  1. Choose the Rotation pattern, Secret class, and Secret manager. Use a dual-secret pattern only when the consumers really can accept old and new credentials during validation.
  2. Enter a safe Secret identifier, accountable Rotation owner, and complete Dependent consumers list. Do not paste the credential value.
  3. Set the start, preparation, validation, propagation, and old-credential hold windows. Review the displayed local timestamps if the plan crosses a daylight-saving change.
  4. Write verifiable Validation checks and an actionable Rollback trigger. Mark break-glass and rollback credentials as available only after testing those paths.
  5. Review the planning score, trust transition, risk flags, and execution ledger. Do not approve revocation until every consumer exception is recorded and the old value is expected to fail.

Interpreting Results:

Rotation readiness is a transparent planning-risk score, not a security verdict. Higher values identify a change that deserves stronger review because it lacks overlap, has many or no listed consumers, is overdue, has weak rollback readiness, or uses a short validation window. A low score does not prove that the inventory is complete or that the replacement is correctly scoped.

The trust-transition percentages are a planning illustration rather than live measurements from the selected manager. Use the Execution ledger for the actual stop/go sequence and check each exit gate against real service, audit, and old-value rejection evidence. The displayed schedule is usable only when its assumptions match the real propagation and reload behavior.

  • Controlled covers scores from 0 through 30.
  • Watch covers scores from 31 through 55.
  • Elevated covers scores from 56 through 75.
  • High risk begins at 76 and includes 100.

Technical Details:

The planning model combines an ordered credential lifecycle with explicit timing offsets and a bounded risk score. Manager and secret-class choices supply domain-specific evidence prompts, while the cutover pattern changes the order of distribution, promotion, and revocation. All score weights and trust-transition percentages are repository-authored heuristics.

Rule Core: ordered transition

  1. Notify consumer owners and freeze the scope.
  2. Inventory readers, access, audit evidence, and rollback paths.
  3. Create a pending replacement, or block suspected access first for an emergency.
  4. Distribute dual-read configuration or prepare a coordinated single-value cutover.
  5. Validate the replacement for the selected window.
  6. Promote the replacement, then retain old trust only for the declared rollback hold.
  7. Revoke the old value and prove that it fails.
  8. Archive safe evidence, ownership, exceptions, and the next due date.

A staged dual-secret plan places distribution after preparation and propagation, promotion after validation, and revocation after the old-credential hold.

tdistribute=prep+lag60 tpromote=tdistribute+validation trevoke=tpromote+hold

Lag is entered in minutes and converted to hours. When overlap is unavailable, hold is forced to zero. The single-credential pattern validates after the maintenance cutover. Emergency revocation caps pending creation at 0.25 hours and old-trust removal between 0.25 and 0.5 hours from the start. These are planning offsets, not guarantees about external systems.

Rule Core: planning score

The score begins with 8 points, adds the selected pattern and manager weights, applies situational adjustments, rounds to a whole point, and clamps the result from 0 to 100.

Secrets rotation planning score adjustments
ConditionAdjustment
Pattern weight: staged dual / single credential / alternating user / dynamic / emergency+6 / +28 / +12 / +8 / +36
Manager weight: AWS / Vault static / Vault dynamic / cloud manager / external secret / manual0 / +4 / −6 / +1 / +5 / +16
No overlap capability+22
No consumers listed / 6 to 11 / 12 or more+12 / +10 / +18
OverdueUp to +24
Break-glass path not verified+10
Rollback credential unavailable outside emergency mode+10
Validation window below 4 hours+8
Positive TTL no longer than the entered rotation interval−6
Vault dynamic manager or dynamic-secret pattern−8

The overdue contribution is proportional to overdue days divided by the entered interval, multiplied by 30 and capped at 24 points. Because these weights are planning choices rather than an industry standard, compare the flags and evidence gates, not just the total.

Validation and scheduling boundaries

Current age accepts 0 to 3,650 whole days and the target interval accepts 1 to 3,650 whole days. Preparation, validation, and hold windows accept up to 336 hours; validation must be at least 0.5 hours. Propagation lag accepts 0 to 1,440 minutes. The start is a local date and time, and elapsed hours are added as durations, so daylight-saving transitions require manual timestamp review.

A staged API-key example with AWS Secrets Manager, three consumers, a current age within the entered interval, overlap enabled, verified break glass, retained rollback credentials, zero notification lead, 4 preparation hours, 24 validation hours, and an 8-hour hold scores 14, which is Controlled. With zero propagation lag, promotion occurs at +28 hours, revocation at +36 hours, and closeout at +42 hours. Those numbers remain conditional on the real consumers passing their checks.

Privacy and Safety Notes:

The planner does not connect to the selected secret manager and cannot create, test, promote, or revoke a credential. Treat every form value and exported artifact as planning material that may be copied or shared.

  • Use aliases, paths, owner names, ticket references, and evidence locations only.
  • Never enter passwords, tokens, private keys, authorization headers, recovery codes, or live credential payloads.
  • Do not interpret a Controlled score as approval to proceed; require real consumer, manager, audit, rollback, and old-value rejection evidence.
  • For suspected compromise, follow the incident-response authority and containment timeline rather than waiting for a routine plan window.

References: