Planned rotation focuses on a controlled cutover. Suspected exposure calls for revoking affected access and addressing the exposure before reconnecting.
Choose the right sequence
Routine maintenance aims to switch a reading service predictably and retire its previous authorization. A credential appearing in a public repository, unsolicited conversation or uncontrolled screenshot changes the objective to preventing further misuse. Do not wait for a polished replacement while knowingly keeping suspicious access active. A rotation plan should reflect the actual service and exposure, not an invented universal number of days.
Find the dependencies
A dashboard, history importer and personal script might share a credential. List the consumers, runtime locations, owners, storage method and stop procedure without copying the secret. Unknown consumers make post-change errors difficult to interpret. Separate credentials for distinct uses make later revocation easier to target. The dependency list is an operational map, not another file containing everything needed to access the account.
Plan a visible maintenance window
When no exposure is suspected, choose a time when you can inspect the result. Confirm the replacement type and import format are supported. Recheck minimum permissions, environment and outbound IP. Pause or carefully switch the relevant jobs, update their configuration and inspect a necessary read. This does not promise zero interruption: parallel configurations and process restart requirements depend on the specific tool.
Exclude stale workers and caches
A balance remaining on screen does not prove the new credential loaded. Inspect the new job time, configuration label and data timestamp. A worker retaining old environment variables may still serve the page. If the provider offers only one credential form, ask when saving it reloads the service. Do not hide an unexplained migration failure by repeatedly restoring the old secret or testing with a live trade.
Use an incident path for exposure
From a trusted device, revoke affected credentials through the official account entry point and review whether suspicious access is broader. Follow official security support guidance where the scope is uncertain. Record the discovery time and exposure location with appropriately redacted evidence. Repositories, tickets, extensions and service storage are investigation possibilities, not proof that any particular component was compromised. Avoid further handling in unknown troubleshooting tools.
Do not refill the same leak
Removing a secret from a repository’s latest file does not erase history or downloaded copies. Revocation ends the old authorization; fixing storage addresses recurrence. If a device or provider remains suspect, pause the connection while dealing with it. Pasting a replacement into the same conversation, log or unexplained service simply repeats the exposure. Recovery needs a resolved access path, not merely different characters in a field.
Retire copies and jobs
After a successful planned cutover, record the old credential’s revocation on the exchange. Clean up old configurations, downloaded files and unnecessary secret copies under your control. Check whether scheduled jobs still retry the retired label. Ask third parties about material they retain through their official process. Deleting a local file and revoking platform authorization address different parts of the problem.
Define completion precisely
Keep the affected tool, old stop time, new start time, verified read function, open issues and responsible maintainer in a non-secret record. For an incident, also record whether the exposure path was addressed and relevant account activity reviewed. This is more useful than “key changed.” A future maintainer can distinguish completed evidence from assumptions that still need investigation before another change.
Treat rollback as a separate decision
A maintenance rollback involving an old credential is only a possible option while that credential remains explicitly trusted and authorized. It is not an incident response for a suspected leak. Restoring service can instead mean pausing synchronization, showing the last data time or waiting for a verified repair. Document this boundary before trouble occurs. If the dependency inventory reveals a tool with no remaining purpose, retirement can be the correct outcome: stop its jobs, revoke access and address retained copies. A new key is unnecessary merely to give every old connection a fresh date.