In short: Two-factor authentication for admin access ensures that a stolen or guessed password alone is not enough. It must apply everywhere someone can change your website or server: CMS, hosting, panel, SSH, domain, DNS and the admins' mailboxes. Just as important as the setup are emergency codes and a clear rule on who has their own access for what.
Why passwords alone are not enough for admins
Passwords get lost in many ways: through phishing emails, malware on a workstation, data leaks at other services or simply through reuse. Automated attacks try stolen credentials continuously against known login pages.
With a second factor, an attacker additionally needs something only the authorised user possesses, such as a smartphone with an authenticator app or a security key. This raises the hurdle considerably, especially for accounts with far-reaching rights.
For management a distinction is important: two-factor login protects access, not the software behind it. A vulnerability like PHP2Shell, which allows code execution without authentication, is not closed by it. The two belong together: current software and well-protected access.
Which two-factor methods are suitable
The methods differ in security and ease of use. For admin accounts you should use at least authenticator apps, and for particularly critical access security keys or passkeys.
| Method | Protection against phishing | Suitability for admins |
|---|---|---|
| SMS code | low | only as a transition |
| Authenticator app (TOTP) | medium | good standard |
| Push confirmation | medium, susceptible to fatigue attacks | suitable with number matching |
| Security key or passkey (FIDO2/WebAuthn) | high | recommended for critical access |
| SSH key with passphrase | high | standard for server access |
One-time codes from an app can be intercepted on a deceptively genuine phishing page and reused immediately. FIDO2 methods, by contrast, check the address of the page and do not work on a fake page. That is why they are the best choice for admins with access to many systems.
Two-factor authentication for admin access: the complete list
Attackers pick the weakest access. Therefore go through all the places where someone can change your website, server or domain:
- CMS and shop backend: WordPress, Shopware, TYPO3 and others offer two-factor login in the core or via maintained extensions. Which variant is recommended is in the vendor's documentation.
- Hosting customer account: Whoever gets in here can often reset passwords, download backups or reinstall the server.
- Server panel such as Plesk or cPanel, if present.
- SSH and SFTP: Keys instead of passwords, see the next section.
- Domain registrar and DNS: A changed DNS setting redirects your visitors and emails without the server being affected.
- Admins' email mailboxes: Password resets for almost all other services run through them.
- Code repository and deployment: Whoever may write there can roll out malicious code.
- CDN, WAF, Google Search Console and payment providers.
For each entry, record who has access, whether the second factor is active and where the recovery codes are kept. This list is also an important part of your emergency plan, because after an incident exactly these access points have to be checked and renewed in a short time.
SSH: keys instead of passwords
For server access, login with an SSH key is the usual strong protection. The private key sits on the admin's device and is protected by a passphrase; for particularly sensitive servers it can sit on a hardware key. Once key login is set up and tested for all admins, switch off password login:
# /etc/ssh/sshd_config (excerpt)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Check the configuration before the service is reloaded
sshd -t && systemctl reload ssh # unter RHEL-Systemen: sshd
When switching over, leave an existing session open and test the login in a second window. That way you do not lock yourself out if there is a mistake. Each admin gets their own key; shared keys for a whole team cannot be revoked cleanly when individuals leave. Further basics are described in Securing root servers and vServers yourself.
Emergency access and recovery codes
A good rollout plans for failure. Smartphones get lost, employees leave the company, security keys break. Without a plan, nobody with access is then ready at the wrong moment.
For each critical account, register two factors, for example a security key in the office and an authenticator app, and keep the recovery codes separate from the password.
Further rules that have proved their worth:
- Personal accounts instead of shared admin logins, so that changes are traceable.
- A documented emergency access with credentials kept separately, whose use stands out and is logged.
- When employees or service providers leave, revoke all access and keys on the same day.
- After a security incident, check not only passwords but also registered factors and active sessions.
A clear process has proved its worth for the rollout in the team. Start with the accounts that can do the most damage: hosting, domain, DNS and the admins' email mailboxes. Servers, CMS and services follow. Set a cut-off date from which logins without a second factor are no longer possible, and make sure beforehand that everyone involved is set up.
Briefly explain to the team why the changeover is necessary and how it works in everyday use. A one-page guide with screenshots considerably reduces questions. External service providers and agencies should receive their own personal access with a second factor instead of a shared login, so that access stays attributable and can be revoked cleanly after the project ends.
How to protect login pages additionally against automated attempts is in the guide Protecting admin logins against brute force.
How does PHP SOS help?
- Together with you, we create a complete list of all admin access points and show where the second factor is missing.
- We convert server access to SSH keys and switch off password login in a controlled way as part of server hardening.
- We document emergency access and recovery routes so that they work in a real emergency.
- In the security maintenance contract, we check access regularly and remove orphaned accounts.
Frequently asked questions
Which two-factor method is the most secure?
Hardware security keys and passkeys based on the FIDO2 standard are considered particularly resistant to phishing because they are bound to the genuine address. Authenticator apps with one-time codes are a good standard. SMS is better than nothing but the weakest variant.
What happens if the smartphone with the authenticator app is lost?
That is what recovery codes are for, which are shown during setup. They should be kept safe, for example in a safe or a protected password manager. In addition, at least one second admin should be able to reset the access.
Does two-factor login also protect against PHP2Shell?
No. PHP2Shell allows code execution without authentication; the login is not used at all. Only the update to a fixed PHP version with a restart of all workers helps against PHP2Shell. Two-factor login protects against stolen or guessed passwords.
Is two-factor login in the CMS enough?
No, an attacker chooses the weakest access point. The hosting account, server panel, SSH, domain management, DNS and the admins' mailboxes must be protected as well, otherwise the CMS protection can be bypassed.