Your sites shouldn’t have to trust me blindly

ToggleWP Cloud will let you manage the security settings of every client site from one place. You set a policy once, and every connected site picks it up. That’s the point of the service, and it could save agencies hours every week.

It also means the Cloud is a single place that many sites listen to. I’ve been thinking hard about what that means.

Before you read on: My ToggleWP Cloud service is still in the final stages of development and testing, it has no client sites connected to it and the changes covered below are not in response to any direct incident.

Why I built this

In October 2026, a well-known WordPress plugin vendor disclosed a breach of its customer systems. Among the data taken were the connection keys its cloud dashboard used to manage customers’ sites. Every customer had to go through each of their sites by hand: delete the old key, check for unknown administrator accounts and plugins, and reconnect.

Breaches like this happen to careful teams, and they disclosed it openly. But it made me ask a blunt question about my own service: if ToggleWP Cloud were ever broken into, what could an attacker do to your clients’ sites?

Part of the answer was already reassuring. ToggleWP Cloud doesn’t hold keys that let it log in to your sites. Sites fetch their settings from the Cloud, and the Cloud stores only a one-way fingerprint of each site’s credentials. A stolen copy of the database can’t be used to sign in to anyone’s WordPress.

The rest of the answer was less comfortable. Sites apply whatever settings the Cloud sends. Someone in control of the Cloud wouldn’t need your passwords. They could quietly loosen ToggleWP’s settings instead: switch off login alerts, hide a plugin from the plugins list, unlock file editing, stop core updates, or send alert emails to their own address. Each change on its own looks like routine configuration.

So I’ve changed how far a site trusts the Cloud.

1. Changes that weaken a site now need the site’s manual approval

ToggleWP still applies anything that tightens security straight away. Anything that would loosen it (once set) is now held back. The site’s administration email address (the one in Settings → General) gets an email listing the changes and a link to approve or decline them.

Changes that need approval include:

• switching off security alerts, lockdowns or plugin protection
• hiding a plugin, or removing one from the protected or blocked lists
• disabling core or theme updates
• longer admin sessions, or login history kept for less time
• new domains allowed to hold administrator accounts
• alerts, webhooks or the client report card sent somewhere new
• switching off a security module, or telling Update Guard to stop holding premium plugin updates

Nothing changes until someone with access to that email clicks Approve. The Cloud never sees the link, so even someone with full control of the Cloud can’t approve their own changes.

A few details I cared about:

• Opening the link changes nothing. Some email systems open links to scan them. Approving takes a deliberate button press.
• Each link works once and expires after seven days.
• You’re asked once per request. The same request on every sync doesn’t flood the inbox. Declining it stops the emails for that request.
• You can see it in the Cloud. While changes are waiting, the site shows Awaiting approval in your Sites list, so you know why a policy hasn’t taken effect yet.
• New setups aren’t held up. The first sync after you pair a site, and the settings of a module being switched on for the first time, go through as normal. Before that point the site had nothing to weaken.

A note for agencies and freelancers

The approval email goes to the site’s administration email address, so set that to whoever manages the site, which is usually you. Most of the time the email will simply confirm a change you made yourself a minute ago. It’s one extra click when you loosen a setting, and I think that’s a fair price for knowing nobody else can.

2. A kill switch that works even if ToggleWP Cloud is compromised

The approval step covers the most damaging changes. I also wanted a way to tell every site, at once, to stop listening to the Cloud entirely while I investigate a problem.

The catch is that the switch can’t live in the Cloud. If an attacker controlled the Cloud, they could just flip it back.

So the kill switch is a small document I sign offline with a key that never touches my servers. Every copy of ToggleWP carries the matching public key and checks the signature. When a site receives a valid freeze:

• it stops applying anything from the Cloud (settings, module switches, Update Guard decisions)
• it keeps its current settings, so nothing is switched off or reset
• site administrators see a notice explaining that changes are paused

Only a newer, properly signed “unfreeze” lifts it. An attacker in control of the Cloud can’t forge one. They also can’t replay an old unfreeze from a previous incident, because sites only accept a document newer than the last one they accepted. Other Cloud features that don’t change your site’s settings, such as content checks and email delivery monitoring, keep working during a freeze.

3. Starting clean afterwards

If I ever need to recover from an incident, I can now, with a single command:

• sign out every dashboard user
• revoke every API key and browser-extension token
• have every connected site switch to new credentials automatically on its next sync, with no visit to each site and no re-pairing

Sites keep working throughout. The old credentials stay valid until the site first uses its new ones, so a site that misses the message just tries again next time.

What you need to do

1. Update ToggleWP on your client sites when the release reaches you.
2. Check each site’s administration email address (Settings → General) and make sure it goes to someone who manages the site.
3. That’s it. Tightening settings works exactly as before. You’ll only see an email when a change would make a site less secure.

I hope you never see the kill switch in action. But security that only works when nothing has gone wrong isn’t worth much, and your clients’ sites deserve better than blind trust, including trust in me.