Secret rotation: why it matters and how to automate the reminder

The credentials that never change

Ask yourself honestly: when did you last rotate your production database password?

Most developers can't answer that question. The credentials were set up when the project launched. They've never caused a problem. Changing them would require updating every environment that uses them. It's easier to leave them.

This is exactly what attackers count on.

What is secret rotation and why does it matter?

Secret rotation is the practice of periodically replacing credentials — database passwords, API keys, JWT secrets, OAuth tokens — with new ones and invalidating the old ones.

The reason it matters comes down to a simple security principle: a compromised credential is only dangerous for as long as it's valid. If an attacker steals a database password that was rotated last week, they have a week's worth of damage potential. If they steal one that hasn't been rotated in three years, they have a three-year head start that you don't know about yet.

Credential exposure happens in more ways than most developers realise:

• A developer leaves the company and their local .env backup isn't wiped
• An old branch with a hardcoded secret gets pushed
• A third-party service you integrated with gets breached
• A contractor is given temporary access but the credentials aren't revoked
• A log file accidentally captures an API key in a query string

In most of these cases, you never know it happened. Rotation limits the blast radius by ensuring that even undetected exposures have a built-in expiry.

The 90-day rule

The most widely adopted standard is 90-day rotation — replace credentials every three months. This is the threshold recommended by:

• NIST Special Publication 800-63B
• SOC 2 Type II compliance frameworks
• PCI DSS for payment-related credentials
• Most enterprise security policies

90 days is long enough that it doesn't create operational burden, but short enough to limit exposure windows.

Some credentials warrant faster rotation:

Why teams skip it

The most common reason secret rotation doesn't happen is simply that there's no reminder. Unlike certificate expiry (which breaks things visibly), a credential that's three years old continues to work perfectly. Nothing prompts you to change it.

The second reason is friction. Rotating a production database password requires:

1. Generate a new password

2. Update it in your secrets manager or vault

3. Update every service that connects to the database

4. Deploy the change in a coordinated way that avoids downtime

5. Verify the old password no longer works

That's real work. Without a forcing function (like a compliance audit), it gets deprioritised indefinitely.

A lightweight rotation system

Here's a practical system that works for small teams without heavy tooling:

Step 1: Track creation dates

When you create a secret, note the date somewhere accessible. The simplest option: add a comment in your .env.example:

# === AUTH ===
# JWT_SECRET last rotated: 2026-01-15
JWT_SECRET=

# === DATABASE ===
# DB_PASSWORD last rotated: 2025-10-03
DATABASE_URL=

Step 2: Set a quarterly calendar reminder

Add a recurring event every 90 days: "Review and rotate secrets". Block 30 minutes. Actually do it.

Step 3: Use ENV Manager Pro rotation alerts

ENV Manager Pro's Pro tier tracks the age of each variable (based on when it was last changed in the vault) and flags anything older than 90 days with a ⚠️ warning in the sidebar. It also sends a Slack webhook notification so the alert lands where your team already works.

⚠️  Rotation due:
   STRIPE_SECRET_KEY     — last changed 94 days ago
   DATABASE_URL          — last changed 102 days ago
   SENDGRID_API_KEY      — last changed 87 days ago (due in 3 days)

Once you've rotated a credential, click "Mark as rotated" in the panel and the 90-day clock resets.

Zero-downtime rotation for databases

The trickiest rotation is a production database password, because if you change it and deploy before all services are updated, you get connection errors. Here's the safe pattern:

1. Add the new password as an additional valid credential

Most databases support multiple valid passwords for a user (PostgreSQL via ALTER USER, MySQL via ALTER USER ... BY with multiple auth options). Add the new password without removing the old one.

2. Update your secrets manager

Push the new DATABASE_URL to AWS Secrets Manager / Doppler / Infisical.

3. Deploy a rolling restart

Trigger a rolling deployment so services gradually pick up the new credentials. Old instances are still working on the old password; new instances use the new one.

4. Verify all instances are using the new credentials

Check your connection logs to confirm no requests are still authenticating with the old password.

5. Remove the old password

Once all traffic uses the new credential, revoke the old one.

This process takes about 15 minutes end-to-end for a typical deployment.

The audit log advantage

One of the biggest benefits of a structured rotation practice is the audit trail. When something goes wrong — and eventually something will — you want to be able to answer:

• When was this credential last rotated?
• Who rotated it?
• Which environments have been updated?

ENV Manager Pro's audit log records every change: who changed what key, when, and in which vault. When your next security audit comes around, you have a clean history to show, not a shrug and a guess.

Start now, not later

If you've never rotated your production credentials, the best time to start is today. Pick your most sensitive credential — probably your database password or your primary API key — and rotate it this week. Once you've done it once, the process feels much less daunting. Then set the 90-day reminder and let the system run.

Security debt compounds. A credential that's been static for three years is a credential that's almost certainly been exposed in some way you don't know about yet. Rotation is the reset button.