Most often, it is technical teams (CTO, RSSI, Infra) that ask the question at the time of a redesign, migration (host, PHP, CI/CD), or when "a tricky thing" goes up via SOC. In the digital direction / project managers, it happens instead when deadlines explode due to security measures added too late, with, in passing, a classical tension: "we secure" vs "we continue to deliver". And on the marketing side, the brake is very concrete: the fear of "no longer being able to publish", or of breaking forms and tags.

WordPress is very targeted... For a simple reason: it is massively deployed. So mechanically, it attracts everything that is automated: brute force, credential stuffing, extension scans, opportunistic exploitation. The realistic goal is not to aim for a "zero risk" fantasy, but to reduce the attack surface, detect quickly, and react cleanly when it happens.

The idea of this article: an actionable method, a prioritized checklist, and quick wins to harden WordPress without breaking use – nor turn each release into a fighter's journey.

And that's precisely what brings us to the next: where to start when everything seems important?

Essential in 30 seconds

If you have to choose where to invest, the fastest and most "profitable" gains generally come from:

• Identity-first (SSO/2FA + own overboarding)
• one patch process (with watch and prioritization)
• of the hardening infra (headers, permissions, WAF/virtual patching)
• and a real ability to restore + runbooks.

WordPress is not "less secure" by nature: security is won at implementation and exploitation. And to avoid the wrong fight, one can already clarify one point: comparison with the custom.

To be retained

WordPress is no less secure than tailor-made: security is won at implementation and operation. The weak point #1, in the majority of cases, are identifiers (and access governance), not CMS. And when we talk about "Enterprise" security, we talk about a trio that reinforces each other: prevention + detection + response, with an acceptable level of friction for the teams.

What we see in the field

In many projects, "classical" WordPress incidents come mainly from rough force/credential stuffing attempts on /wp-login.php, vulnerable plugins installed "speed made" to unlock a need, shared (or never revoked) admin accounts, and environments where no one can clearly say "who has access to what".

The common surprise: up-to-date sites without usable logs, therefore impossible to investigate properly.

And the time lag we often encounter: we strengthen the server... but we leave a weak authentication, or an overboarding service provider blurred. This is precisely where the Identity-first method makes the difference. — which brings us to the real debate on WordPress vs custom.

👉 If you don't know today precisely list who has access to what on your WordPress, this is probably the first point to clarify.

Is WordPress "less secure" than tailor-made?

Why "made-to-measure = more secure" is a shortcut

Intuition is understandable: "if it is known, it is more attacked, therefore less sure".

In practice, a tailor-made one often has an attack surface less visibleNot necessarily better controlled. It can combine DIY authentication, little-followed dependencies, lack of patch process, incomplete logs... In short, safety is more "implicit" than driven.

Which makes WordPress solid... and what makes him fragile

WordPress is solid when it is maintained, hardened and observed The ecosystem and herening practices are mature. It becomes fragile when one lets drift: too many plugins, unmaintained themes, too wide privileges, updates "when one will have time", and above all... Low identity.

The Be API principle: security-by-design

Security-by-design is not a "lot" added at the end. It is a design constraint that is dealt with early: roles, admin paths, authentication flow, secrets, IC/CD, observability, restoration. When placed in the kick-off phase, we avoid the "successive" model.

Our 3 requirements from kick-off

• Identity-first (SSO where possible, 2FA imposed, password policy including providers)
• one patch + watch process (windows, prioritization, and mitigation when patch cannot pass immediately)
• a evidence & answer (centralised logs, runbooks, systematic post-mortem).

The most frequent attacks on WordPress (and why they pass)

Brute force & credential stuffing

• Why: passwords reused, absence of MFA, login endpoints exposed without rate limiting.
• Signals: peaks of attempts, gusts of 401/403 on /wp-login.php or /wp-admin/.
• Corrective: MFA/SSO + rate limiting + bot detection (WAF or proxy).

Plugins & Vulnerable Themes (only chain)

• Why: popular plugin but maintainer absent, dependencies not followed, admin rights too open (installation "anytime").
• Signals: creation of unknown accounts, new PHP files in wp-content/, suspicious requests on extension endpoints.
• Corrective: plugin governance (selection, review, deletion) + WAF/virtual patching if needed.

Administrative accounts / poorly managed roles

• Why: "admin for everyone", shared accounts, approximate offboarding, never revoked providers.
• Signs: out-of-time admin connections/unusual countries, unexpected role changes.
• Corrective: RBAC strict + conditional access + quarterly review of accounts.

Malware/backdoors via compromised server access

• Why: permissions too permissive, secrets that drag around, no separation of environments, vulnerability elsewhere on the host.
• Signals: unknown cron, abnormal outgoing traffic, off-deployment modifications.
• Corrective: OS hardening + env separation + file integrity + secret rotation.

Exposured endpoints (XML-RPC, REST): case by case

• Why: uncontrolled exposure, useful but unprotected endpoints, or "blind" deactivation that breaks down usages.
• Signals: POST gusts on xmlrpc.php, bikes on sensitive REST roads.
• Corrective: Targeted filtering (WAF/rate limit), appropriate authent/permissions, deactivation only if confirmed unnecessary.

What we avoid "disabling blindly" (XML-RPC/REST)

XML-RPC can still be used for certain streams (publishing, legacy integrations); The REST API is often structuring (editor, headless, apps, integrations). In general, we get out better with a "reduce and control" approach (roads, methods, rate limiting, auth) than with a "OFF" that eventually shifts the risk... to cleaner bypasses.

Now that the risks are set, we can move on to concrete: the prioritized checklist.

Priority checklist: the 10 "must-have" measures

• Impose SSO or 2FA for all privilege accounts (admin/editor)
• Rate limiting + anti-bot on login and admin (WAF/proxy or serious plugin)
• Access policy: minimum roles, no shared accounts, strict offboarding
• Controlled updates: core + plugins + themes, with security prioritization
• Inventory and governance of plugins/themes (selection, review, deletion)
• Server hardening: permissions, ca. separation, secrets, less privilege
• HTTPS everywhere + secure cookies + headers (HSTS, etc.) depending on context
• WAF + virtual patching to reduce exposure window
• Backups + tested restoration (RPO/RTO) + recovery plan
• Centralised Logs + Detection + Runbooks + Post-mortem "Support Evidence"

(1) Mandatory SSO/2FA.

Immediate benefit from password attacks; trap: 2FA "optional" = 2FA ignored; quick win: impose at least on admins + providers.

2) Rate limiting / anti-bot.

Cutting automation; trap: blocking legitimate IPs (VPNs, offices); quick win: progressive thresholds + allowedlist controlled.

3) Roles & Offboarding.

Reduces impact; trap: too much admins "for comfort"; quick win: a technical admin, limited business roles.

4) Patch process.

Reduced exposure; trap: "we patch when we can"; quick win: monthly slot + hotfix security.

5) Governance plugins.

Limit supply chain; trap: plugin "one-shot" forgotten; quick win : quarterly review + deletion.

(6) Server hardening.

Limit climbing; trap: too wide writing rights; quick win: minimum permissions + secrets off repo.

7) HTTPS / headers / cookies.

Protects sessions and traffic; trap: aggressive CSP without recipe; quick win: secure cookies + PSTS if perimeter controlled.

8) WAF / virtual patching.

Save time when the patch waits; trap: believe it replaces the patch; quick win: rules targeted on known CVE.

9) Backups + restore.

"Real" insurance trap: backups not tested; quick win: restoration exercise on preprod.

10) Logs / runbooks / post-mortem.

React better; trap: scattered logs; quick win: centralize auth + admin + application errors.

👉 This is typically the kind of exercise we do with our clients: objectiveizing the real level and making 2–3 immediate, concrete and actionable priorities emerge.

The logical follow-up, now, is to zoom in on the point that often changes the level of risk: identity.

Identity-first (the real Achilles heel)

Why IDs are the most "profitable" fault

Because it's scalable: the attacker doesn't need a 0-day if a password leaked elsewhere. In many projects, infrastructure is hardened... And we keep a "historic" authentication. This shift is common.

Recommended model: SSO + MFA + conditional access

Whenever possible:

• an IdP (Azure AD/Entra ID, Okta, etc.)
• MFA
• conditional rules (location, device compliance, risk)

Result: clean offboarding, visibility, and homogeneous policy.

"2FA attached to the contract": the factor must be revocable

Prioritise a factor related to a revocable element (pro / IdP / device managed) rather than a "portable" OTP that an outgoing takes away. The goal is to be able to cut access in 2 minutes – not "hope" that the claimant returns his TOTP.

To summarize:

• SSO alone is interesting for governance
• 2FA alone is fast but more fragile side offboarding
• SSO + MFA generally remains the best "Enterprise" standard if IdP exists.

For example: an outgoing provider, WordPress account disabled... but OTP factor remained "outside SI". With SSO + MFA, revocation is done side by side IdP (account + sessions + device) and traceability is cleaner.

With the identity in place, you can secure wp-admin without blind hardening.

Secure wp-admin and login page without breaking usage

The right compromise is often to break automation, without punishing teams (VPN, travel). The spleen limiting is regulated in steps, with different thresholds for public admin vs.

Changing login URL can reduce noise a little. But it remains hygiene: useful, rarely decisive, and it does not compensate for a weak identity.

And on the choice 2FA vs SSO: if you already have an IdP, SSO (with MFA) is often the most coherent. Otherwise, 2FA imposed is a very good step — provided that it is revocable and monitored.

Deploy 2FA gradually without chaos

1. Start by mapping roles (admins, publishers, providers, technical accounts)
2. Choose a "removable" factor
3. Pilot on admins + providers, then impose by waves (short grace period + accompaniment).
4. In parallel, add rate limiting/WAF on /wp-login.php.
5. Above all, measure: failure rates, non-compliant accounts, blocked attempts to adjust thresholds.

Once the access is set, the other "continuous" lever concerns the supply chain: plugins and themes.

Plugins & themes: reducing the risk of supply chain without killing agility

The objective is rarely "zero plugin". What works better is "less plugins, but better" : avoid duplicates, prefer proven components, and limit "tote" extensions that affect auth, files and forms at the same time.

To select, one can remain pragmatic: plugin maintained, patch history, compatibility, possible review code, and functionality actually needed (less surface = less surprises). Then, regular review and removal of unnecessary: a plugin "disabled" is not always a "risk-free" plugin if it remains present or if it has left endpoints.

Typical Cadence:

• monthly magazine light (MAJ & alerts)
• quarterly review (inventory & deletion).

And when the function is stabilized, the "Enterprise" level is played mainly on l'infra.

Server Hardening & Infra: Enterprise Level

HTTPS is non-negotiable HSTS deploys when the perimeter is well controlled. CSP can be very effective, but gets ready (otherwise you break tags/iframes marketing) — a "report-only" phase often avoids bad surprises.

On the system side, the heart remains the slightest privilege: permissions, preprod/prod separation, off-deposit secrets, rotation. And on the WordPress side, hardening sensitive files (wp-config.php, keys/salts) is part of the basics.

Finally, the WAF/virtual patching serves as an airbag when the patch window is forced: "upstream" protection to block a known feat, pending the patch. It completes the patch; It doesn't replace him.

Frequent errors : to think that "HTTPS + security plugin" is enough without strong identity; leave large writing rights "for comfort"; deploy a prod CSP without reporting-only phase; install a WAF and never look at logs; reuse the same secrets between preprod and prod.

This infra base is important, but it is really effective only if updates become a process – not an event.

Updates & Updates: Switch to a Process

The most robust prioritization remains pragmatic: known exploitable vulnerabilities, components exposed in front, auth/admin perimeter, and the rest. The idea is to reduce first what is achievable and impacting.

On the organizational side, an effective watch does not need to be complex: editor sources, CVE alerts, tracking critical plugins, and an internal channel (Teams/Slack) where the info actually lives. The good "rhythm" often looks like: hebdo alert review, sort "patch now / patch planned / mitigations", and updates in controlled environment with tests.

And even with the best patching in the world, you need insurance that works on the day... It's still going on: restoration.

Backup & restoration: insurance that works if tested

Without RPO/RTO, "we have backups" doesn't mean much. RPO = acceptable data loss; RTO = return time to service. Fixing them, even approximately, makes arbitrations concrete.

The useful test is not a "isolated file restore", but a complete restoration (file + DB) on an isolated environment, with minimal validation (login, key pages, forms, payment if e-commerce) and a measurement of time. Documenting variances is what turns an exercise into an improvement.

Once we know how to restore, one last pillar remains: being able to investigate and respond without improvising.

Logs, detection, incident response: be ready on D-Day

Minimal viable: logs (success/fails), admin actions, role changes, application errors, WAF/proxy logs, and system events. Centralization is often the real accelerator: faster investigation, cleaner evidence, and less time lost in "reconstitute" history.

Runbooks avoid "who decides?" hot: roles, escalation, communication, technical actions, rocking criteria (maintenance mode, rotation of secrets, etc.). And post-mortem, when it is factual and tooled, is mainly used to advance: timeline, root causes, impact without speculation, immediate and structural measures, evidence (logs/IOC/WAF/commits rules), date tracking plan.

With these elements, one can propose a simple trajectory at 24 / 7 days / 30 days — and above all make it actionable.

Checklist "24h / 7 days / 30 days"

• 24h: reduce the immediate risk. Impose 2FA on admins, activate rate limiting/WAF on login, cut useless accounts, check backups, and make sure you have exploitable logs.
• 7 days: stabilize. Inventory plugins/themes, patch plan, hardening permissions, preprod/prod separation, overboarding procedure providers.
• 30 days: industrialize. SSO/MFA + conditional access, CI/CD with tests, virtual patching for constraint windows, runbooks, restoration exercise, safety dashboard.

Scorecard /100 (10 criteria)

1. Identity (SSO/2FA)
2. Offboarding & access governance
3. Rate limiting/WAF on login/admin
4. Patch process (core/plugins/themes)
5. Governance plugins (selection/review/deletion)
6. Server/permission/secret strength
7. HTTPS + cookies + headers
8. Backups + tested restore (RPO/RTO)
9. Centralised Logs + Retention + Access
10. Runbooks + post-mortem "proof"

👉 This scorecard can serve as a basis for a WordPress security audit to quickly identify your priorities. Let's talk about it.

To go further

If you want to secure WordPress without slowing down the teams, the trajectory often looks like this: governed identity (SSO/MFA), industrialised patching, WAF/virtual patching as airbag, tested restore, and an investigative ability "proof to support".

At the bottom, secure WordPress does not raise any miracle plugin or isolated hardening. It is a coherent set: controlled identity, controlled updates, properly configured infrastructure, tested restoration, and investigative ability when something comes out of the frame.

What makes the difference is continuity in execution.

FAQ