Discover every consumer
List applications, workers, scheduled jobs and integrations that use the credential. Record where each retrieves it, how often it refreshes and who owns the dependency. Do not copy the secret into a ticket, chat or diagnostic log.
Determine whether the provider supports two active credentials or versions. If it does not, a no-downtime change may require a different migration strategy or an agreed maintenance window; do not promise seamless rotation.
Rotate in a controlled order
Where overlap is supported, create the replacement credential with the required scope, store it in the approved secret manager and update one test consumer. Verify the real operation and inspect authentication failures without exposing credential values.
Roll out to remaining consumers, including long-lived processes that may cache a value at startup. Record the version or identifier in deployment metadata only if it is safe to do so. Keep the old credential active for the agreed observation window and retain a documented rollback path.
Revoke and verify
Once all consumers are confirmed on the new credential, revoke the old one and monitor for unexpected use or failed authentication. Check queues and delayed jobs that might run after the initial cutover.
If the rotation responds to a suspected compromise, containment may require revoking the old credential sooner. Follow the incident process and preserve evidence. Review automation permissions, expiration and alerts so the next rotation does not depend on undocumented manual steps.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.