Secrets such as database passwords, API keys, and signing credentials eventually need replacement. Rotation may follow a scheduled policy, staff departure, vendor requirement, or suspected exposure. A small SaaS team does not need an elaborate secret-management platform to rotate safely, but it does need an inventory, ownership, and a procedure that avoids unplanned downtime. The key is to make rotation a routine operation rather than an emergency experiment.
Know what exists
Record each secret's purpose, owner, storage location, consuming processes, permissions, and rotation method. Do not put the secret value in the inventory. Include credentials used by CI, background jobs, integrations, support tools, and old deployments. A key that only one person knows how to update is an operational risk. Prefer individual access and managed identities where the environment supports them so fewer long-lived shared secrets are needed. Limit a credential's privileges to the operations its service actually performs.
Prefer overlapping credentials
When a provider allows two active keys, create the replacement, deploy it to consumers, verify traffic, then revoke the old key. This avoids a gap where no valid credential exists. For signing keys, include a key identifier and allow verification with both old and new public keys during the transition so existing sessions can expire naturally. Database users may need a staged password change or second account. If overlap is impossible, plan a short maintenance window and a rollback that does not reintroduce a known-compromised credential. The procedure depends on the credential type and vendor behavior.
Store and deploy carefully
Use the platform's approved secret store or protected deployment environment. Never commit values to source control, bake them into images, or print them in build logs. Give CI and operators access only where necessary. Changes to secret references should be reviewable without revealing the values. If a credential is suspected exposed, rotate it promptly and investigate where it may have been logged or copied. Removing a value from the current configuration does not erase it from old builds, backups, or chat history; assess those locations when exposure is plausible.
Verify the whole dependency chain
After deploying a new key, check every process that uses it, including scheduled jobs that run infrequently. Watch authentication failures, connection errors, and external provider responses. A smoke test of the main site may miss a weekly export or billing job. Keep a list of consumers in the rotation runbook and record completion. If a service caches credentials in memory, it may need a safe reload. Confirm that old credentials are actually revoked after the transition rather than left active indefinitely “just in case.”
Handle incidents and normal rotation differently
Routine rotation can be scheduled and tested. Suspected compromise may require immediate revocation, session invalidation, and customer communication depending on impact. Define who can authorize and perform each step. Keep a secure audit record of when the credential changed and who did it. Avoid broad rotation of unrelated secrets during an incident unless evidence warrants it, because simultaneous changes can make diagnosis harder. Focus first on containment and restoration of the affected service.
Practice before the emergency
Rotate a low-risk credential in a test environment and update the runbook from what actually happened. For production, make a rollback plan, monitor the result, and verify infrequent consumers. A repeatable rotation process reduces the cost of good security. It also helps a small team avoid the false choice between leaving old keys active forever and risking a customer outage every time a password changes. Track the age of credentials and alert owners before a provider-enforced expiration. Review unused keys and delete them rather than keeping an indefinite inventory of possible access paths.