Secret rotation

What it is

Secret rotation is the practice of replacing a credential's value with a new one on a schedule, or in response to suspected compromise. The goal is to bound the lifetime of any single value so that a leaked credential stops being useful within hours or days instead of remaining valid forever.

Rotation is the second half of a secret's lifecycle. The first half is keeping it out of attackers' hands; rotation is the assumption that the first half will eventually fail, and the harm needs to be time-boxed.

Why it's hard

A secret has two states that need to stay in sync: the application code that uses it, and the system that issued it. Rotation has to update both, in the right order, without anyone hitting the window where one side has the new value and the other still has the old. Three real problems show up:

• Distribution. Every consumer that reads the value has to receive the new one before the old is revoked. With one server, that's a config change. With twenty containers, three CI runners, and a serverless function, it's a coordination problem.
• Coupling. Some credentials gate downstream systems. Rotating a database password without updating the connection string in your app means immediate outage. Rotating a webhook signing secret without updating the receiver means dropped webhooks.
• Visibility. A spreadsheet of "what rotates when" stops being current the day after you write it. Without a system tracking which secrets exist, where they're used, and when they were last rotated, "rotate everything quarterly" is a policy nobody actually executes.

The result, at most companies, is that rotation is the security control everyone knows they should run and almost nobody does on a real schedule.

How automated rotation works

A working rotation flow looks the same in most systems:

1. The secrets manager generates a new value.
2. The new value is provisioned into the source system (a new database password is set, a new API key is minted, a new TLS cert is signed).
3. Consumers fetch the new value on their next read.
4. After a brief overlap window, the old value is revoked.

Step 2 is the one that varies the most. For credentials the secrets manager controls directly (random tokens, app-defined keys), it's just a write. For credentials backed by an external system (a database, a cloud IAM, a third-party API), the manager has to call out to that system to actually create the new credential. Most secrets managers either have built-in integrations for common backends (PostgreSQL, MySQL, MongoDB, cloud IAM) or expose a hook for you to write your own.

How SikkerKey rotates secrets

SikkerKey rotates secrets on a schedule you set per secret. The rotation works for any secret, not just database credentials. For ordinary secrets (API keys, webhook signing secrets, application tokens, arbitrary structured values), each rotation generates a new random value. The value is configurable by length and character set, or by specific JSON fields if the secret is structured. The new value is stored as the next version, and consumers fetch it on their next read.

For secrets that back a managed database (PostgreSQL, MySQL, MongoDB, Redis, or MSSQL), the same rotation generates a new credential and additionally pushes it to the live database. A local sync agent installed near the database receives the new credentials and applies them with the database's own user-management commands, so the rotation takes effect on the live system without any manual step.

Every rotation produces an audit log entry recording the secret, the version transition, and the timestamp. Old versions are retained briefly so consumers fetching during the rollover get the value that was current at fetch time, then the previous version is dropped. SikkerKey doesn't natively call out to third-party SaaS APIs (Stripe, Twilio, etc.) to rotate credentials inside those systems; for those, rotation produces a new value in your vault, and updating the value in the third-party system is a separate step.