Which Credentials to Rotate After a Hack, and in What Order

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Cleaning the malware is the visible half of a recovery. The invisible half is assuming that everything readable was read, and replacing it. People generally change their WordPress password, feel they have addressed it, and leave a dozen other working credentials in place — several of which allow a quiet return long after the files are clean.

The assumption to work from

If an attacker had file access, assume they read every file, including wp-config.php with your database credentials and any configuration holding API keys. If they had database access, assume they read every table, including user records and any stored secrets.

That is not paranoia, it is the only workable standard. You almost never get evidence of what was actually copied, because copying leaves no trace. Treating everything reachable as exposed is the only approach that does not leave you guessing, and the cost of rotating a credential unnecessarily is a few minutes.

Order matters

Rotate from the outside in, starting with the credentials that would let someone undo your work. Hosting control panel first, because it governs everything else. Then FTP, SFTP and SSH access. Then the domain registrar and DNS provider. Then the site's own credentials, then everything stored inside the site.

Doing it in the other order wastes effort: change your WordPress password while someone still holds FTP access and they simply change it back. Also do this from a device you have reason to trust, not the machine you suspect might have been the source — my guide on infostealer malware covers why that matters.

The full list

Infrastructure: hosting control panel, all FTP and SFTP accounts, SSH keys, the registrar account, the DNS provider, and any CDN or proxy account such as Cloudflare including its API tokens.

The site: the database password, WordPress salts and keys in wp-config.php, every administrator password, and a forced reset for all remaining users. Then everything stored inside the site: SMTP credentials, payment gateway keys, shipping and tax integration keys, marketing platform keys, cloud storage tokens, and any licence keys for premium plugins.

The ones everyone forgets

WordPress salts are the biggest. They sit in wp-config.php and they are what session cookies are signed with — leave them unchanged and an attacker holding a stolen session cookie stays logged in as an administrator no matter how many times you change the password. Replacing them logs everyone out, including them, and it takes thirty seconds.

The others: API tokens, which survive password changes entirely and are independent credentials in their own right; application-specific passwords at services that issue them; email account passwords where the site sends through a real mailbox; and any credentials shared with a developer or agency, which frequently means a password nobody has changed in years.

Doing it properly

Use unique passwords, generated and stored in a password manager rather than invented. A compromise is the natural moment to stop reusing credentials, since reuse is how one breach becomes several. Enable two-factor authentication wherever it is offered — hosting, registrar, email, and WordPress itself.

Force a password reset for all site users rather than just administrators, particularly if the site holds customer accounts, since those records were readable too. And delete accounts that should not exist rather than changing their passwords, including any FTP user or WordPress administrator you cannot account for.

Verifying it took

After rotating, check that old access no longer works: confirm the FTP accounts you deleted are gone, that revoked API tokens fail, and that no active sessions remain. Then watch for a few days — an attempt to use a credential that no longer works sometimes shows up in your logs and confirms you closed something real.

If credentials keep being used after rotation, something is still on the system reading the new ones, and you have a live compromise rather than a leftover. That is the point to stop rotating and start hunting, which is exactly the work my malware removal service does.

Common questions

Why do I need to change WordPress salts?

Because they sign session cookies. If an attacker captured a valid administrator session cookie, it keeps working after you change the password — the password is not what authenticates that session. Replacing the salts invalidates every existing session at once, which logs them out along with everybody else.

What order should I rotate in?

Outside in. Hosting control panel first, then FTP, SFTP and SSH, then registrar and DNS, then the site's own credentials, then anything stored inside the site. Changing site passwords while someone still holds server access accomplishes nothing, because they can simply change them back.

Do API keys need rotating too?

Yes, and they are the most commonly missed. An API token is an independent credential that a password change does not affect at all — anyone holding a valid token keeps their access regardless. Revoke and reissue every key stored in or used by the site.

Should I reset passwords for all my users?

Yes, if the database was reachable, because their credentials were in it. Hashed passwords are not plaintext but they can be attacked offline, and people reuse passwords across services. Forcing a reset is the responsible action and it is also what you would want done for you.

I rotated everything and the attacker is still getting in. What now?

Something on the system is reading the new credentials as you set them, which means a backdoor survived the cleanup. Stop rotating — it is not going to work — and find the persistence mechanism. Check mu-plugins, scheduled tasks, prepended PHP configuration and other sites on the same hosting account.