A token appears in a build log or a pasted support message. The priority is to limit exposure, but immediately revoking it without checking its consumers can turn a contained credential incident into an outage. Treat rotation as a short, ordered change: scope the exposure, replace the credential, verify the change, then revoke the old one.
Scope exposure and use
Identify the credential’s owner, permissions, creation time, and services that may use it. Check the systems where it could have been copied, such as build output, deployment settings, source control, logs, and support tickets. Do not paste the token into a new message or command history while investigating.
Use the provider’s access records, if available, to look for recent use and unexpected activity. Those records can help establish what happened, but an absence of recorded requests does not prove the token was never copied or that every consumer has been found. If the credential has broad access or suspicious activity is visible, prioritize containment and follow the organization’s incident process.
Replace it in a controlled order
First check whether the provider allows two active credentials at once. If so, create a replacement with only the permissions the service needs, store it in the approved secret manager, and update one consumer at a time. Keep the old credential active only for the brief overlap needed to confirm that the replacement works.
If overlap is not supported, plan a coordinated change instead of assuming the application can swap credentials without interruption. Identify the deployment or restart needed to load the new value, choose an appropriate change window when the service warrants one, and make sure you have a rollback plan that does not put the exposed token back into use.
Verify before closing the change
Test the actual operation each consumer needs, not just whether it can reach the provider. Review application logs and provider access records for authentication failures after the update, while taking care not to log the new secret. If one service still uses the old credential, locate that dependency before revoking it when the risk allows.
Once the replacement is working across the identified consumers, revoke the exposed token and confirm it is no longer accepted if the provider offers a safe way to test that. Remove the leaked value from places you control and record what was exposed, what changed, and what remains uncertain. A careful rotation ends with a smaller set of valid credentials—not just a new string in one configuration file.