Website Login Security: MFA, Named Accounts, and Safer Admin Access

Website login security is often reduced to “use a strong password.” That is necessary, but it is not a complete access system.

A business website may have administrator access in the CMS, hosting, domain registrar, DNS, analytics, tag manager, forms, email delivery, payment tools, CDN, repositories, and deployment systems. One shared password cannot govern all of that safely.

Give each person a named account

Shared administrator logins make it difficult to answer basic questions: Who changed this? Who still knows the password? Can we remove one person without disrupting everyone?

Use named accounts wherever the platform supports them. Give each user the smallest role that fits the work. A writer usually does not need hosting access. An analytics reviewer does not need domain control. A web vendor may need CMS and deployment access without needing billing authority.

Named accounts improve both security and operations. They make offboarding possible without forcing an emergency password change across the whole team.

Add MFA to the accounts that can change the site

CISA recommends multifactor authentication because a stolen password alone should not be enough to enter an account. Prioritize the registrar, DNS, hosting, CMS administrators, deployment systems, and the email accounts used to recover them.

MFA methods are not identical. NIST’s current authenticator guidance provides a deeper model for authenticator strength and phishing resistance. A small business does not need to memorize the standard, but it should prefer stronger methods supported by the platform and keep recovery from becoming an easy bypass.

Protect the recovery path

An account is only as strong as its recovery process. Review the recovery email, phone, backup codes, trusted devices, security questions, and support contacts.

Use a business-controlled recovery address, not a former employee’s personal inbox. Store backup codes in a controlled password manager or other approved secure location. Do not leave the only recovery method on the same phone or email account that could be lost.

For the domain and hosting account, confirm the business can prove ownership without relying on one vendor.

Match permissions to the job

Administrator should not be the default role. Use editor, author, shop manager, analyst, billing, developer, or other scoped roles when available.

Review service accounts and API keys too. An integration may have broader access than a human user. Record what created the key, what uses it, and how it can be rotated. Remove keys that no longer have a known purpose.

This is where website security support becomes operational: access is inventoried, reviewed, and tested instead of assumed.

Make offboarding part of the same system

Access control is not finished when a user is created. It needs an end date.

When a staff member, freelancer, or vendor leaves:

1. Disable or remove named accounts.
2. Rotate shared credentials they knew.
3. Revoke sessions, keys, and trusted devices.
4. Transfer ownership of content, analytics, domains, and integrations.
5. Test the website and lead paths after changes.

Our website-access offboarding checklist covers the wider set of systems that often gets missed.

Review access on a schedule

Do not wait for an incident or staff departure. A simple quarterly review can compare active users with current responsibilities.

Check:

• CMS administrators and editors.
• Hosting, SFTP, SSH, and support users.
• Domain, DNS, CDN, and email-routing access.
• Analytics, Tag Manager, Search Console, and call tracking.
• Form, CRM, booking, payment, and automation integrations.
• Repositories, deployment services, and API keys.

Record the owner and purpose for each high-impact account. If nobody can explain why access exists, investigate before removing it; unknown integrations can break real workflows.

Build a login policy people can follow

The best policy is clear enough to use: named accounts, least privilege, strong authenticators, controlled recovery, documented owners, and timely removal.

Avoid rules that sound strict but encourage workarounds. If the official login process is impossible, people will share passwords in chat or leave trusted sessions open forever.

Robben Media can help map website access and define a practical maintenance and ownership process that fits the actual platforms behind the site. The goal is not more login ceremony. It is fewer invisible paths into business-critical systems.