Why Rebuild Before You Rotate Credentials After a Breach

When you rotate credentials after a breach, timing decides whether the rotation helps. If the attacker still controls the system that stores or brokers those credentials, every new password, key and token you set flows straight to them. Patch or rebuild the compromised system first, confirm it is clean, then rotate in a deliberate order. Rotating early feels responsive, but it only repeats the leak.

Why does rotating credentials too early fail?

Rotating credentials too early fails because the new secrets are created on, stored in or typed through the system the attacker still controls. They capture the replacements the same way they captured the originals.

Google Threat Intelligence Group states this directly in its guidance for the BeyondTrust Remote Support CVE-2026-102764 intrusions: rotate only after the appliance is patched or rebuilt, because rotating earlier exposes the new credentials to an attacker who may still have access.

In that case the attacker had root on the appliance, a startup script that survived reboots and configuration resets, and had already tried to dump the credential vault. Any admin password reset through that appliance, any vault entry updated on it and any API secret reissued from it would have been visible to them.

The instinct to rotate first

Incident response often starts with "change all the passwords". It is visible, fast and easy to report upward. The problem is that it confuses activity with containment.

A credential rotation is only as trustworthy as the place the new credential lives. If that place is compromised, you have spent the effort, broken integrations, interrupted users, and gained nothing. Worse, you may have taught the attacker that you know, without having removed them. We made a related point in why patching your VPN gateway does not evict the attacker already inside: closing the original hole does not touch what the attacker left behind.

What should happen before credential rotation?

Before rotation, the compromised system must be patched or rebuilt from a known-good image, and the attacker's access paths must be closed. For appliances you cannot inspect, that usually means a rebuild, because a reboot or reset does not remove host-level persistence.

For the BeyondTrust case, GTIG's sequence was:

1. Preserve evidence (memory snapshots, disk exports, off-appliance logs).
2. Block inbound traffic at the perimeter and restrict egress.
3. Rebuild from a clean, fully patched image, restoring only a configuration backup dated before the exposure window.
4. Issue a new TLS certificate and redeploy agents and consoles from the rebuilt system.
5. Only then rotate credentials.

If you cannot rebuild yet, rotation can still make sense for credentials that do not pass through the compromised system, such as a directory account you reset on the domain controller and never type into the appliance again. Be honest about which credentials truly sit outside the attacker's reach.

Rotate in order of reach

Once the system is clean, rotate the credentials that control everything else first. GTIG's order for a remote support appliance shows the logic:

1. Credentials that administer the appliance itself.
2. Portal administrators and local users.
3. API client secrets.
4. Directory bind accounts and SAML signing keys.
5. Vaulted credentials, rotated at the target system rather than inside the appliance.
6. Integration credentials such as SMTP, syslog and ticketing connectors.
7. Anything typed into a support session during the exposure window.

The top of the list is the smallest set with the widest reach. If an attacker kept one appliance admin account, they could read every credential you rotate afterwards. Reversing the order wastes the work on everything below.

Step 5 deserves attention. Changing a password inside the vault without changing it on the target server only updates your copy. The old password still works on the target, and the attacker has it.

Step 7 is the one teams forget. Session recordings and transcripts can contain credentials that never touched the vault. Review them, list what was typed, and rotate those too. Our guide on how to audit remote support logs for role escalation covers pulling the session reports you need for that list.

Tokens and agents count as credentials

Passwords are not the only secrets. Session tokens, agent registration tokens and certificates also let a holder act as a trusted party. GTIG's BeyondTrust guidance includes ending all active support sessions and redeploying Jump Clients, Jumpoints and the representative console so existing tokens stop working. Treat any long-lived token issued by the compromised system as part of the rotation scope.

For a full inventory approach, see how to rotate every secret an arbitrary file-read bug could have exposed.

Plan the order before you need it

The worst time to work out rotation order is during an incident. For each tier-0 system, including remote support, identity, backup and SIEM, write down which credentials it stores or brokers, where each one is actually changed, and in what order. Keep privileged credentials in an external vault with credential injection so fewer of them live on any single appliance. For the bigger picture on what these systems hold, read what a remote support appliance can reach in your network.