{{ summaryHeading }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ badge.label }}
{{ secretsStageAgeLabel }} Deploy {{ secretsStageVerifyLabel }} {{ secretsStageRevokeLabel }}
Use staged dual-secret when consumers can accept old and new credentials during the same window.
Name the credential without exposing the credential value.
Pick the credential type that best matches the rotation job.
Cloud and Vault-backed flows get pending-version, lease, or audit-specific gates.
Shown in every schedule row and exported artifact.
Use one consumer per line or separate names with commas.
Used to calculate stage timestamps in the plan.
Age drives due/overdue badges and risk scoring.
days
Enter the expected maximum age before this secret rotates again.
days
Consumers can accept old and new credentials
Turn off for systems that can hold only one credential at a time.
This precedes any consumer reload or cutover.
hr
Keep long enough for delayed jobs and partner callbacks to use the new credential.
hr
Use a short hold for rollback, then revoke promptly.
hr
List concrete checks such as auth success rate, queue drain, partner callback, and audit log evidence.
Make this explicit enough for an on-call engineer to act without debate.
Added before validation begins.
min
Use 0 when the credential has no explicit expiration.
hr
Used in the schedule and checklist evidence rows.
hr
Leave blank to use a generic change record placeholder.
Use a durable record such as a ticket, runbook page, or evidence folder name.
Break-glass path verified
Confirms emergency access works without depending on the credential being rotated.
Previous credential retained for rollback until revoke
Turn off when policy requires immediate destruction or the old credential is known compromised.
Stage Time Owner Action Exit gate Fallback Copy
{{ row.stage }} {{ row.timeLabel }} {{ row.owner }} {{ row.action }} {{ row.exitGate }} {{ row.fallback }}
Checkpoint Evidence Pass threshold Failure action Record Copy
{{ row.checkpoint }} {{ row.evidence }} {{ row.threshold }} {{ row.failureAction }} {{ row.record }}
Risk Severity Driver Mitigation Owner Copy
{{ row.risk }} {{ row.severity }} {{ row.driver }} {{ row.mitigation }} {{ row.owner }}
Tags: Devops, Security
Cache TTL Hit Rate Calculator Model cache TTL hit rate from request reuse, fixed or sliding expiry, purge loss, freshness pressure, target TTL, and latency savings.
DNS Cache Capacity Calculator Estimate DNS resolver cache memory from QPS, hit rate, distinct inserts, TTL, DNSSEC overhead, headroom, and upstream-load charts.
IPv4 Renumbering Planner Plan IPv4 renumbering waves from host mappings, prefix boundaries, DNS TTL, and DHCP lease timing with readiness checks and rollback runbooks.
JWT Claims Risk Checker Check JWT claims and headers for issuer, audience, time, algorithm, replay, and sensitive-data risks before relying on a token in an API.
Customize
Advanced
:

A secret rotation is not finished when a new value exists. It is finished when every trusted reader has moved to the replacement, the old value no longer works, and the change record can explain what happened if an outage or audit question follows. The difficult part is usually coordination rather than generation. API clients cache keys, batch jobs wake up late, pods may not reload mounted values, partners may retry callbacks with an old signature, and database pools can keep using a connection that was opened before the credential changed.

Rotation planning separates two problems that often get mixed together. The first is exposure control: how long the current value has been trusted, whether it may have leaked, and how quickly old trust must be removed. The second is service continuity: how consumers receive the replacement, how readiness is proved, and what happens if one consumer was missed. A plan that only says "replace the key" leaves both problems underspecified.

Secret identifier
A safe name for the target, such as a path, alias, certificate name, or provider key label. It should not be the credential value.
Consumer inventory
The applications, jobs, integrations, operators, and external systems that must read or validate the replacement.
Overlap
A period when both old and new values are accepted, giving consumers time to prove readiness before revocation.
Cutover gate
The evidence required before promotion, such as successful authentication, manager version labels, audit reads, or absence of error spikes.
Revocation proof
Evidence that the old value fails and stale reuse attempts are understood rather than ignored.
Credential rotation flow through creation, deployment, validation, promotion, and revocation Current trusted value Pending replacement Deploy consumers Validate evidence Revoke old trust old exposure should fall to zero new readiness rises through proof

Different secret classes need different proof. An API key may need provider-side usage logs and a smoke test. A database credential needs a connection test, pool refresh, and failed-login watch. An OAuth client secret needs token exchange evidence and old-secret rejection after revocation. A webhook signing secret must prove that signed callbacks validate through the intended path. A TLS private key or certificate needs chain, expiry, key-usage, reload, and custody checks.

Central managers make rotation easier to audit because version labels, leases, timestamps, and access logs can show which value was read. Manual or config-managed secrets can still be rotated, but the plan needs stricter change evidence because the system may not produce a clear version history. Emergency rotation changes the order again: suspected access should be blocked first, then consumer inventory and evidence gaps can be closed as incident follow-up.

The strongest plans are deliberately boring. They name owners, consumers, timing windows, validation checks, rollback triggers, evidence stores, and revocation proof. They do not paste raw credentials into tickets, chat, exports, or planning notes.

How to Use This Tool:

Use the planner before opening or executing a change so the schedule, checklist, risk register, exposure chart, and exportable evidence describe the same rotation.

  1. Choose the Rotation pattern. Use Staged dual-secret cutover when old and new values can overlap, Single credential maintenance window when only one value can be trusted, Alternating user or cloned principal for paired accounts, Dynamic or short-lived secret migration for lease-backed moves, and Emergency revoke and reissue when containment comes first.
  2. Enter a Secret identifier, Secret class, Secret manager, Rotation owner, and Dependent consumers. The identifier should be safe for a change record, not the secret value itself.
  3. Set Start time, Current secret age, and Target rotation interval. These values drive the due label and the age term in the risk score.
  4. Use Supports overlap to state whether consumers can accept both old and new values. Turning it off removes the old-credential hold and adds a maintenance-window warning outside emergency mode.
  5. Fill in Prepare window, Validation window, Old credential hold, Propagation lag, New credential TTL, and Notify before start. The schedule turns those windows into ordered timestamps.
  6. Add Validation checks, a Rollback trigger, an approval ticket, an evidence store, and the break-glass and rollback readiness flags. Empty secret identifier, owner, or invalid start time blocks the result until corrected.
  7. Review Rotation Schedule, Validation Checklist, Risk Register, Rotation Exposure Timeline, and JSON. Copy or download outputs only after checking that they contain planning metadata rather than credential material.

Interpreting Results:

The summary combines the selected pattern, secret class, manager, overlap support, age status, consumer count, total schedule span, and composite risk band. Controlled means the entered plan has fewer modeled concerns. Watch means the plan needs attention before promotion. Elevated risk and High risk mean the timing, overlap, age, manager, consumer inventory, or fallback assumptions need stronger evidence before old trust is removed.

Result area Use it for Do not overread
Rotation Schedule Stage order, owner, timestamp, action, exit gate, and fallback. A planned stage is not proof that the stage passed.
Validation Checklist Evidence that must exist before promotion and revocation. Default checks should be replaced with service-specific health and audit signals.
Risk Register Modeled reasons the plan may fail or expose old trust longer than intended. A lower score does not remove per-consumer validation.
Rotation Exposure Timeline A visual check of old-value exposure and new-value readiness across planned checkpoints. The percentages are planning values, not live provider telemetry.
JSON A structured record of the entered plan, computed schedule, checklist, risks, and chart points. It should be saved only where change evidence is allowed to live.

The most important verification cue is revocation proof. If the old credential still authenticates, if stale reads continue after the hold period, or if a listed consumer never produced readiness evidence, treat the plan as incomplete even when the schedule and score look clean.

Technical Details:

The planner models rotation as an ordered change with bounded numeric windows. Time fields are normalized into hours, propagation lag is converted from minutes, and the old-credential hold is set to zero when overlap is unavailable. Consumer and validation text are split into individual entries so schedule rows, checklist rows, and exports can name the actual dependencies being checked.

Risk scoring starts with the rotation pattern and manager choice, then adjusts for overlap, blast radius, overdue age, fallback readiness, validation length, short-lived credential controls, and dynamic-secret signals. The score is a planning triage number. It is not a cryptographic strength score and does not inspect the credential value.

Formula Core:

The composite score starts at 8, applies additive and subtractive terms, clips the result to 0 to 100, and rounds to a whole number.

risk score = round ( clamp ( 8 + P + M + O + C + A + B + R + V - T - D , 0 , 100 ) )

P is the pattern base risk, M is the manager adjustment, O is 22 when overlap is unavailable, C is the consumer-count term, and A is overdue-age risk. B adds 10 when break-glass access is not verified. R adds 10 when rollback credential retention is unavailable outside emergency mode. V adds 8 when validation is shorter than 4 hours. T subtracts 6 when a nonzero new credential time-to-live is no longer than the target interval, and D subtracts 8 for dynamic-secret mode or Vault dynamic secrets.

Mechanism Rule Why it matters
Risk band 0 to 30 Controlled, 31 to 55 Watch, 56 to 75 Elevated, 76 to 100 High risk Higher bands call for stronger validation and fallback evidence.
Pattern base Staged dual 6, single credential 28, alternating user 12, dynamic secret 8, emergency revoke 36 Single-value and emergency paths start riskier because they leave less validation margin.
Manager adjustment AWS Secrets Manager 0, Vault static 4, Vault dynamic -6, cloud secret manager 1, Kubernetes External Secret 5, manual/config 16 Managers with version, lease, and audit evidence reduce uncertainty compared with manual records.
Consumer count 0 consumers adds 12, 6 to 11 adds 10, 12 or more adds 18 No inventory and broad blast radius both reduce confidence.
Overdue age min(24, overdue days / target interval * 30) Stale secrets add risk, but the age term is capped.
Validation checkpoint pending time + propagation lag + validation hours Promotion normally waits for validation, except single-credential mode promotes at the maintenance cutover.
Closeout max(validation end, revoke time) + max(1, min(24, validation hours / 4)) Evidence archiving lands after the later validation or revoke point.

Rule Core:

Schedule rows are derived from the selected rotation pattern. Emergency mode blocks suspected access near the start. Single-credential mode promotes at the prepare-window boundary because there is no overlapping dual-read validation period. Overlap-enabled paths distribute configuration, validate, promote, hold the old value briefly, and then revoke.

Pattern Promotion stage Revocation stage Main planning caution
Staged dual-secret cutover Promote new version Revoke old version Do not let the overlap window become indefinite old-value trust.
Single credential maintenance window Maintenance cutover Retire prior value Missed consumers fail quickly because only one value can work.
Alternating user or cloned principal Switch active principal Retire previous principal Permission parity must be verified without expanding access.
Dynamic or short-lived secret migration Enforce lease policy Revoke static fallback The migration is only meaningful when issuance, renewal, and revocation policy are real.
Emergency revoke and reissue Reissue replacement Revoke exposed credential Containment leads, and incomplete inventory must be tracked after the incident cutover.

The exposure chart uses planned old-exposure and new-readiness percentages at the start, pending, distribution, validation, promotion, revocation, and closeout checkpoints. Treat those lines as sequencing aids. Replace them with manager audit evidence, application health checks, callback results, and failed-authentication monitoring before closing the change.

Privacy and Safety Notes:

The planner is for rotation metadata and evidence planning. It should not receive passwords, tokens, private keys, certificate private material, webhook signing strings, environment variable values, or copied authorization headers.

  • Use a central secrets manager whenever possible so version labels, access logs, leases, and revoke events can support the evidence record.
  • Keep old-value revocation separate from promotion. Promotion proves the replacement is active; revocation proves old trust has ended.
  • During suspected compromise, disable exposed access before waiting for a perfect inventory, then record every exception and follow-up dependency.
  • Check exported tables, charts, documents, and JSON before attaching them to tickets or shared folders, because they include the entered identifiers, consumers, owners, and evidence paths.

Worked Examples:

A staged API key rotation for three services, with overlap enabled, 4 hours of preparation, 30 minutes of propagation lag, 24 hours of validation, and an 8-hour old-credential hold produces a plan that notifies owners, creates a pending value, distributes dual-read configuration, validates service and provider evidence, promotes the replacement, waits through the hold window, revokes the old value, and archives evidence.

A database credential that cannot overlap old and new values is a different kind of change. The risk score rises because no-overlap adds 22 points and the single-credential pattern has a 28-point base. The schedule should be treated like a maintenance cutover with explicit connection checks, pool refresh evidence, and a rollback path that does not depend on the credential being changed.

An emergency revoke starts from a higher base risk of 36 and changes the order of operations. The plan blocks the exposed value quickly, reissues a replacement, validates under pressure, and keeps incident evidence visible. That output can seed the incident record, but delayed jobs, partner callbacks, and stale configuration still need a follow-up inventory.

A Vault dynamic-secret migration should not be read as safe just because the pattern subtracts risk. The lease, renewal, and revocation policy must exist, and consumers must stop depending on long-lived static values before the static fallback is revoked.

FAQ:

Should the actual secret be pasted into the planner?

No. Use a path, alias, provider key name, certificate name, or other safe identifier. The plan needs enough detail to identify the rotation target, not the credential value.

Why does no-overlap rotation score higher?

A single-value cutover gives consumers less time to prove the replacement while the old value still works. The score adds risk and the warnings push the plan toward a maintenance window and explicit rollback evidence.

What does the new credential TTL change?

A nonzero TTL can reduce the score when it is no longer than the target rotation interval. The reduction only makes practical sense when the TTL or lease is enforced by the real issuing system.

Why is the result blocked?

The result is blocked when the secret identifier is empty, the owner is empty, or the start time cannot be parsed. Fix those fields before using the schedule, checklist, risk register, timeline, or exports.

Does a Controlled score prove the rotation is safe?

No. Controlled means fewer modeled concerns were entered. Real safety still depends on per-consumer readiness evidence, manager audit events, old-value rejection, and a record of any exceptions.

References: