- \n
- A dev@ account with a password nobody’s touched since 2019.\u00a0\u00a0<\/li>\n<\/ul>\n\n\n\n
- \n
- A plugin author’s support account that was never removed after they fixed something a couple of years ago.\u00a0<\/li>\n<\/ul>\n\n\n\n
- \n
- A\u00a0plain subscriber who somehow ended up with an Administrator role that nobody can explain.\u00a0<\/li>\n<\/ul>\n\n\n\n
- \n
- Former employees\u00a0and\u00a0contractors who fixed one thing and disappeared.\u00a0<\/li>\n<\/ul>\n\n\n\n
- \n
- Third-party authors who were given temporary access and never asked to leave.\u00a0\u00a0<\/li>\n<\/ul>\n\n\n\n
The site moved on. The accounts didn’t. <\/p>\n\n\n\n
Why this goes unnoticed<\/strong> <\/h3>\n\n\n\n
User hygiene doesn’t make it onto most security checklists because it’s not a technical vulnerability. <\/p>\n\n\n\n
There’s no CVE for “ex-employee still has the keys.” No scanner flags it. No plugin monitors it by default. <\/p>\n\n\n\n
It just requires someone to sit down, look at the list and ask: does this person still work here? <\/p>\n\n\n\n
The answer, more often than you’d expect, is no. <\/p>\n\n\n\n
Or nobody can remember, which amounts to the same thing. <\/p>\n\n\n\n
Security hardening guides have trained developers to think about perimeter defences. But a dormant account with a weak password and full admin rights skips straight past all of that. <\/p>\n\n\n\n
A 30-minute fix that catches more than most hardening checklists<\/strong> <\/h3>\n\n\n\n
Export the user list and go through it with the client<\/strong> <\/h4>\n\n\n\n
Sort by role. Ask the client to put a name to every admin and editor. Anyone they can’t identify gets demoted to subscriber, not deleted. You want the audit trail intact. <\/p>\n\n\n\n
Force a password reset on everyone who\u00a0remains<\/strong>\u00a0<\/h4>\n\n\n\n
Even accounts the client can vouch for. Password hygiene degrades over time and a clean reset at handover sets a clear baseline from day one. <\/p>\n\n\n\n
Kill all active sessions<\/strong>\u00a0<\/h4>\n\n\n\n
WordPress lets you invalidate all existing sessions from the user profile screen. Do it. Anyone who was logged in and shouldn’t be is now out. <\/p>\n\n\n\n
Set up login logging<\/strong>\u00a0<\/h4>\n\n\n\n
A basic activity logging plugin takes five minutes to configure and gives you a clear record of who’s accessing the site going forward. It makes every future audit much quicker. <\/p>\n\n\n\n
No specialist tools, no complex configuration. Just a clear-eyed look at who actually has access to the site you’ve been trusted to look after. <\/p>\n\n\n\n
The underlying problem<\/strong>\u00a0<\/h3>\n\n\n\n
WordPress makes it genuinely easy to grant access and easy to forget you’ve done it. There’s no expiry on user accounts, no nudge to review permissions, no warning when a role hasn’t been used in 18 months. <\/p>\n\n\n\n
The responsibility falls entirely on whoever manages the site. In a handover situation, that means it often falls through the gap completely. <\/p>\n\n\n\n
It’s also one of the easier conversations to have with a client. Former staff with full admin rights is a risk that lands immediately, even for people with no technical background. And fixing it costs less than an hour. <\/p>\n\n\n\n
Sort the users. Ask the questions. Change the passwords. It’s not glamorous, but it’s where the real exposure tends to live. <\/p>\n\n\n
- Third-party authors who were given temporary access and never asked to leave.\u00a0\u00a0<\/li>\n<\/ul>\n\n\n\n
- Former employees\u00a0and\u00a0contractors who fixed one thing and disappeared.\u00a0<\/li>\n<\/ul>\n\n\n\n
- A\u00a0plain subscriber who somehow ended up with an Administrator role that nobody can explain.\u00a0<\/li>\n<\/ul>\n\n\n\n
- A plugin author’s support account that was never removed after they fixed something a couple of years ago.\u00a0<\/li>\n<\/ul>\n\n\n\n
![\"Managed](\"https:\/\/www.20i.com\/blog\/wp-content\/uploads\/2026\/03\/Blog-Ad-WordPress-1200x625-1.png\")
<\/a><\/div>\n\n","protected":false},"excerpt":{"rendered":"Most WordPress security advice revolves around WAFs, login page obfuscation and security plugins. Meanwhile, a significant risk sits…","protected":false},"author":13,"featured_media":19585,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"csco_singular_sidebar":"","csco_page_header_type":"","csco_page_load_nextpost":"","footnotes":""},"categories":[293],"tags":[],"class_list":["post-19408","post","type-post","status-publish","format-standard","has-post-thumbnail","category-wordpress","cs-entry"],"_links":{"self":[{"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/posts\/19408","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/comments?post=19408"}],"version-history":[{"count":3,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/posts\/19408\/revisions"}],"predecessor-version":[{"id":19411,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/posts\/19408\/revisions\/19411"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/media\/19585"}],"wp:attachment":[{"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/media?parent=19408"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/categories?post=19408"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.20i.com\/blog\/wp-json\/wp\/v2\/tags?post=19408"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}