In this guide (8)
A site's admin panel, whether it's /wp-admin, /administrator or another address, is the point most probed by automated bots looking for weak credentials or credentials already stolen elsewhere. You don't need to have an important site to become a target: just being online is enough. This guide explains what really happens during an attack on administrative access, which defenses actually block it, and which are just myths.
A site's admin panel, whether it's /wp-admin, /administrator or another reserved address, is the point most probed by automated bots looking for a working username and password combination. You don't need to run a major site to become a target: just being reachable on the internet is enough. The good news is that the safeguards that stop almost all of these attempts are few, well known, and don't require an enterprise security budget.
This guide is for anyone managing a company site or an ecommerce store on WordPress, Joomla or a similar platform who wants to understand what really needs to be secured in terms of access, not a list of generic tips. If the site is already compromised, the procedure to follow in the first few hours is a different job, described in the guide on what to do if your site has been hacked. If instead you suspect that someone has already gotten in without leaving obvious traces, the warning signs are covered in the guide on a compromised site without knowing it.
What happens when the panel is attacked
In the vast majority of cases there isn't a person choosing your site specifically: there's a script that continuously scans the internet looking for reachable admin panels, and when it finds one it tries combinations of usernames and passwords in sequence. Two variants come up most often. Strict brute-force tries many different passwords against a known or common username, such as "admin". Credential stuffing is more insidious: it uses username and password pairs already leaked from breaches of other sites, betting that someone has reused the same password elsewhere, which happens more often than you'd think.
Those running these scripts almost never work from a single IP address. They use networks of compromised computers (botnets) that spread attempts across hundreds of different addresses, precisely to get around simple IP-based blocks. If the attack succeeds, the typical next step isn't to "vandalize" the site: it's to install a discreet backdoor, often a webshell, which guarantees access that survives even a change of the stolen password. How a webshell works, and how to recognize one, is described in the guide on what a webshell is and how to block it.
Why a panel becomes an easy target
Three conditions, almost always present together, turn a normal panel into a convenient target. The first is a predictable username: "admin", the domain name, or the owner's name as written in the contact email. The second is a weak password or one reused across multiple services, often chosen to be easy to remember rather than hard to guess. The third, the most underestimated, is the absence of a limit on attempts: if the panel accepts unlimited attempts without slowing down or blocking anything, a script can try thousands of combinations at no cost to the attacker.
Often added to these is a fourth, technical condition: accessory endpoints left active without any real need. On WordPress, for example, the xmlrpc.php file can be exploited to automate bulk login attempts (a single packet can contain hundreds of username/password pairs), and it's common to disable it when it isn't needed by integrations that genuinely require it.
KeideaCMS
Want to know if your current site's logins are exposed?
Declared security measures →Contact
The safeguards that block most attacks
You don't need an enterprise security budget. You need a few safeguards, actually applied, not just declared.
Unique, long password. The NIST SP800-63B guidelines, referenced by OWASP, indicate that without multi-factor authentication a password under 15 characters should be considered weak; with 2FA active, the threshold drops to 8. A long, unique passphrase managed with a password manager is better than a complex password reused across multiple sites.
Two-factor authentication (2FA/MFA). This is the single most effective safeguard: OWASP cites a Microsoft analysis according to which it would stop 99.9% of password-related account breaches. CISA recommends, where possible, phishing-resistant forms of MFA such as FIDO/WebAuthn; alternatively, an authenticator app (TOTP) is still far better than no second factor at all.
Limit on failed attempts. OWASP recommends defining three numbers: how many failed attempts are allowed, within what time window, and for how long the lockout lasts afterwards. The counter should be tied to the account, not just the IP address, because an IP is easily changed with a botnet.
Disable what you don't need. Endpoints like xmlrpc.php on WordPress, if no real integration uses them, should be disabled: they reduce the attack surface at no cost in functionality.
Login logs and notifications. Knowing when and from where someone has accessed (or attempted to access) the panel makes it possible to spot an anomaly before it becomes an incident, not after.
The safeguards at a glance
A summary of the five safeguards, with where they are typically configured on a self-managed WordPress or Joomla site.
| Safeguard | What it blocks | Where it's configured |
|---|---|---|
| Unique, long password | Dictionary attempts, reused passwords | Password manager, CMS policy |
| 2FA / MFA (TOTP or FIDO) | Access with a stolen or guessed password | CMS plugin/extension, or native in platform |
| Limit on failed attempts | Large-scale automated scans | CMS plugin/extension, application firewall, hosting |
| Disable unused endpoints | Large-scale automation (e.g. xmlrpc.php) | CMS configuration or system file (.htaccess) |
| Logs and notifications | Reaction time to an anomaly | Audit plugin, hosting panel, managed platform |
What's not enough: the false myths
Some common practices give a greater sense of security than they actually provide. It's worth being precise, because the difference between "looks protected" and "is protected" is exactly where successful attacks slip through.
Moving the login address (e.g. from wp-login.php to a custom URL) reduces traffic from the laziest bots, but it is security through obscurity: anyone who knows the platform can still find the new address, and on its own it doesn't replace 2FA and a limit on attempts. A CAPTCHA without a limit on attempts slows down but doesn't stop the most sophisticated scripts, which today often include modules to solve it. Blocking only by IP address, without tying the counter to the account, can be bypassed with a botnet that spreads attempts across hundreds of different addresses: OWASP explicitly flags this as a loophole to close. The absence of a visible attack so far is not proof of security: it only means you haven't noticed it, or that the logs aren't being checked.
What KeideaCMS states today (and what it doesn't)
On the security page, verified on 16 October 2026, KeideaCMS states for administrative access: two-factor authentication with the TOTP standard (RFC 6238), compatible with apps like Google Authenticator and Authy; a system of "trusted" devices that avoids requiring 2FA on every login for 30 days, using a 256-bit cryptographic token; a limit on attempts with a configurable threshold (5 attempts per hour by default), beyond which the IP address is automatically added to a blacklist for 24 hours; and a log of accesses, changes and blocked attacks, with configurable retention of up to over 90 days.
It should be stated precisely what that page does not declare: a mechanism for permanently locking the account after repeated failed attempts, and the full detail of which events, besides the attempt threshold, trigger the automatic blacklist. We do not present these measures as a guarantee of invulnerability: no technical safeguard is. They are verifiable measures on the public page, which concretely reduce the attack surface compared to a panel without 2FA and without a limit on attempts. Hosting, updates and support are included in the fee for the plans; a point-by-point comparison with other approaches is on the comparison page.
If you manage a WordPress or Joomla site yourself and want to understand who should be responsible for these safeguards over time, not just activate them once, the full picture is in the guide on managed website security. If, on the other hand, backup is the safeguard you're missing, the reference guide is on website backup.
Self-assessment checklist
Ten minutes to understand where you stand. The more boxes you can check, the harder the panel is to breach with an automated attack.
No administrator user is named "admin" or has the domain name as their username.
Passwords for accounts with access to the panel are unique, long, and generated or managed with a password manager.
2FA is active on all accounts with administrator privileges, not just the main one.
There is a limit on failed attempts, with a defined number, time window, and lockout duration, not left to chance.
Endpoints not used by any real integration (e.g. xmlrpc.php) are disabled.
Someone monitors, or receives a notification, when there are unusual logins or attempts on the panel.
Accounts of former collaborators or vendors who no longer work on the site have been deactivated, not just "forgotten".
Securing administrative access doesn't eliminate the risk of an attack: it makes it much more costly for anyone attempting it, to the point of discouraging nearly all the automated scripts that today scan the web looking for the weakest panel, not the most important one.
Sources and verification date
Consulted on October 16, 2026. Industry guides describe recommended practices, not an automatic obligation identical for every site. The product page describes what the vendor states, not proof of superiority.
OWASP, Authentication Cheat Sheet (account-linked account lockout, NIST SP800-63B thresholds on password length, MFA and effectiveness against password-related attacks).
CISA, Multi-Factor Authentication guide (phishing-resistant MFA, FIDO/WebAuthn).
KeideaCMS, security page (TOTP 2FA, attempt limit, IP blacklist, audit trail).
Research and first draft assisted by artificial intelligence tools. Proposed author and proposed reviewer: Antonio Cicirelli, pending human verification. The public byline should only be assigned after approval.
