Phishing
A convincing login page collects working credentials. Without a registered machine, the credentials open nothing.
WP Device Guard only lets /wp-admin open on machines you have approved. A password on its own stops being enough — so a leaked one stops being a breach.
The password is correct in every case. Only the machine changes.
WordPress already checks the password. Device Guard adds a second question — is this machine on the register? — and both must be satisfied before the admin opens.
Every common way a WordPress admin account is taken over ends the same way: someone who is not you, typing your password, on a machine that is not yours.
A convincing login page collects working credentials. Without a registered machine, the credentials open nothing.
A password from an unrelated breach is tried against your login within hours. Each attempt is refused before the password is even weighed.
Sitting on the same café or office connection as a registered laptop proves nothing. The register records machines, not networks.
Set up once. Afterwards your team signs in exactly as before — same page, same password, same habits.
It starts in monitor mode, recording what it would have refused without locking anyone out while you watch.
You · onceLaptops run a small background app. Phones get a single-use link instead — open it, confirm the password, done.
Each person · onceRegistered machine and correct password gets in. Anything else is refused and written to the ledger, with its reason.
Every dayPress revoke in your dashboard. The next request from that machine is refused — no password reset, no waiting for a session to lapse, no call to a network administrator.
| 04:20:44 | login | allowed | registered machine |
| 04:21:02 | revoke | ok | by administrator |
| 04:21:04 | login | refused | machine not trusted |
| 04:36:10 | heartbeat | refused | revoked |
Genuine audit output. Revoke to lockout: two seconds.
Laptops prove themselves continuously in the background. Phones cannot run background apps reliably, so they prove themselves another way. You choose which methods the register accepts.
| Machine | Proof | Effort for the person |
|---|---|---|
| Mac · Windows · Linux | Background app checks in every few minutes | Installs once, then nothing |
| iPhone · iPad · Android | Single-use authorization held in the browser | Opens a link, confirms the password |
| Any phone · stronger | Passkey held in the secure chip, non-exportable | Face ID or fingerprint at sign-in |
| Managed fleet | Certificate issued by your IT department | None — invisible |
Four situations every WordPress owner eventually meets. Pick one and follow what actually happens, minute by minute.
Choose a situation:
The machine was registered, and it was taken unlocked. The attacker has everything they need — except time.
Window of exposure: 18 minutes, ended by one click
Most sites already do one of these. They are not wrong — they answer different questions. Only the last row answers "which machine is this?".
| Approach | Stops a stolen password | No speed penalty | Revoke one device | Works off the office network |
|---|---|---|---|---|
| Full-tunnel VPN | Anyone on the tunnel | All traffic routed | Account level | Yes, once connected |
| Two-factor only | Codes get phished too | No penalty | Account level | Anywhere |
| IP allowlist | Anyone on that network | No penalty | Whole ranges | Breaks when travelling |
| Device Guard | Machine must match too | Nothing is tunnelled | One machine, seconds | Network is irrelevant |
Keep the VPN for everything else. This replaces it for one door.
Device Guard proves a request came from a machine on the register. It is worth being precise about where that stops.
It is not antivirus.
If a registered laptop is already compromised, the attacker is on a trusted machine and Device Guard will let them through — it has no view into what is running on the device.
Pair with endpoint protectionIt does not watch the keyboard.
An unlocked, registered laptop in the wrong hands works exactly as it should. Device trust proves the machine, never the person sitting at it.
Pair with short screen-lock timeoutsIt does not replace the password.
Both checks still run, and either failing refuses the request. Device trust narrows where a credential works; it does not make a weak one safe.
Keep two-factor switched onIt guards the admin only.
The check applies to wp-admin and the login. Other internal systems keep whatever protection they already have, and the VPN can stay for those.
Keep existing controls elsewhereThe ones that come up before anyone agrees to install it.
The machine goes stale after about fifteen minutes and the admin stops opening, with a message explaining why. Starting the app again restores access within a minute or two — nothing needs re-registering.
This is deliberate. "The app is not running" and "this is not an approved machine" should look identical to the gate, or the check could be sidestepped by simply quitting the app.
No. Nothing is added to your public pages, and no traffic is tunnelled. The only extra work is one indexed database update when a registered machine checks in — at fifty machines that is roughly one small request every four seconds, which is less than a single page view costs.
Yes, but a phone is registered differently. Phones cannot run a reliable background app, so instead you open a single-use link and confirm your password once on that device. It then keeps working until it is revoked.
For a stronger option, a phone can register a passkey held in its secure chip, which cannot be copied off the device.
Revoke it from any browser you can reach the admin from — including a colleague's registered machine. The stolen laptop is refused on its next request, and the app on it erases its own token.
No, and it should not. They defend against different things: two-factor proves the person, device trust proves the machine. Keep both switched on.
Three things: the machine's hardware identifier, a token proving it registered, and the public IP it connects from. It does not see browsing, files, keystrokes or anything else, and it only ever talks to your own WordPress site.
Your password is used once, at registration, and is never written to disk by the app.
That is the default. The plugin installs in monitor mode, where it records every decision it would have made but blocks nothing. Run it for a week, read the log, then switch it on when the picture looks right.
Then the gate is gone, which is worth saying plainly. For a stricter deployment the same check can run at the web server or CDN in front of WordPress, with the plugin as a second layer rather than the only one.
WP Device Guard is being trialled with its first sites. Get in touch if you would like to run it on yours.
Talk to us