Changing WordPress administrator passwords does not protect hosting, email, databases or API secrets that the compromised site could read. Rotation must follow control dependencies so a still-compromised recovery channel cannot reset newer credentials.
Inventory owners and exposure first; never record the replacement secrets in the incident report.
Start with primary email
Secure the mailbox used to recover hosting, WordPress, registrar, Cloudflare and payment services. Revoke sessions/app passwords, inspect forwarding/recovery rules and enable MFA.
Use a clean device and unique password. If mailbox ownership is uncertain, use the provider’s verified recovery process before trusting reset links.
Check delegated/shared access and OAuth applications.
Rotate hosting and server access
Change cPanel/Plesk/customer/system users, revoke panel sessions/API tokens, and replace SFTP/FTP/SSH credentials and deployment keys.
Give responders individual managed accounts rather than a shared master. Check addon domains/staging/sibling sites reachable by each user.
Do not forget infrastructure-provider console or reseller access.
Rotate database access
Create unique database users/passwords per site with minimum grants, update wp-config.php securely, test and revoke old credentials.
Review allowed remote hosts and public phpMyAdmin/database tools. Remove SQL backups from public roots.
If several apps share one user, plan separation before revocation.
Rotate WordPress identities
Reset approved administrator/shop-manager passwords, remove unknown/obsolete users, revoke sessions and application passwords, and enable MFA.
Rotate salts/keys to invalidate cookies when warranted. Confirm site/user admin emails and pending change requests.
Do not create a permanent hidden responder account.
Rotate mail credentials
Replace SMTP mailbox/app passwords, transactional provider API keys, webhook/event tokens and bounce-processing access. Review forwarding rules and outbound spam.
Use a dedicated authenticated website sender rather than an employee password. Update each site/integration before revoking the old value.
Verify SPF/DKIM/DMARC after provider changes.
Rotate DNS and CDN access
Review registrar users, nameservers, Cloudflare/CDN users, API tokens, workers and redirects. Revoke unknown tokens and narrow automated DNS privileges.
Changing a registrar password does not revoke every CDN token. Enable MFA and protect the owner email independently.
Keep a known-good zone export.
Rotate service and automation identities
Inventory cron scripts, backup agents, uptime/security monitors, CI/CD runners, remote-management tools and server-to-server credentials. These accounts are easy to miss because no person logs in interactively.
Issue named replacements with narrow scope and clear owner. Test each job, then revoke the previous value and watch for failed attempts.
Do not give automation a human administrator password or unrestricted cPanel access.
Rotate business integrations
Review payment/gateway keys, WooCommerce REST keys, webhooks, CRM/ERP/shipping/tax/analytics/tag-manager and backup/monitoring credentials.
Use one named least-privilege identity per integration. Rotate in sandbox and verify idempotency before live write access.
Never paste payment or API secrets into tickets.
Check code and secret history
Search repositories, CI logs, environment files, support exports, old staging sites and backups for exposed values. Revocation makes old credentials unusable; still remove public leaks and restrict historical access.
Do not rewrite production repository history without the source-control owner’s plan. Record affected locations, not secret values.
Use managed secret storage.
Follow a dependency-aware order
Secure recovery email and master control planes first; then create/test downstream replacement credentials before revocation. Rotate secrets readable by the compromised PHP process even if no misuse appears.
Record services that cannot rotate immediately and isolate them with temporary controls/monitoring. Avoid changing every value simultaneously without knowing which failure belongs to which dependency.
Have a rollback that does not restore exposed credentials.
Verify and close temporary access
Test every service with replacement credentials, then revoke the old and confirm it fails. Remove emergency users, keys, IP allowlists and database tools.
Monitor login/API failures and privileged changes. Keep a rotation matrix with account, owner, date and verified status—never passwords.
Request managed post-hack rotation when several services depend on one secret. Share the account inventory and access invitations—never old or new credentials publicly.