Guide · Access

Website admin accounts: who should have one?

An administrator can change the site, its users and sometimes its data. The useful question is who needs that power today and who is accountable for each account.

Updated September 11, 2026 Reading time: 9 minutes

On this page
  1. The principle
  2. Who should be an admin
  3. Build the inventory
  4. Separate daily work
  5. Protect the accounts
  6. Vendors and departures
  7. Technical sources
  8. Common questions

Short answer

Who should have an administrator account on a website?

Only people who actually need to change configuration, install code or manage users. Every account should be named, have a current owner and map to a documented need.

The site owner should keep at least one administrator account under the organization’s control. Writers, analysts and short-term vendors get a narrower role or time-limited access. A former employee, former agency or shared mailbox should not remain an administrator just in case.

Least privilege in plain language

Access should let someone complete a specific task without opening everything else. A writer usually does not need to install a plugin. A vendor fixing one page does not need to manage every user.

This limits both human mistakes and the damage a compromised account can cause. Named accounts also make actions attributable instead of hiding them behind a shared login.

Worth remembering

A job title does not justify permanent access. A real need, a duration and clear accountability do.

Three categories to separate

  1. The accountable owner

    keeps access controlled by the organization, with an organizational email address and recovery method.

  2. The regular technical administrator

    gets a named account because administration is part of their ongoing work. That access is reviewed periodically.

  3. The short-term operator

    gets the narrowest workable role and an expiry. Access is removed after the work and its validation are complete.

Careful

Do not delete the only account whose recovery you control. Before reducing access, verify that an owner account works and that its recovery details are current.

An inventory you can act on

Open the CMS user list, then the hosting provider, domain registrar, CDN and any tool that can deploy code. These are different boundaries: deleting a WordPress administrator does not remove their hosting access.

For every powerful account, record

  • Identity a person or accountable team, never only “admin” or “agency.”
  • Scope what the account can change: content, users, code, DNS, billing or backups.
  • Reason the current task that requires this level of access.
  • Protection multifactor authentication, a unique password and controlled recovery.
  • Review date the next review or removal date for temporary access.

Use a daily account and an admin account

Someone who administers the site does not need that power to read, draft or view analytics. A lower-privilege account fits daily work; the administrator account is used only when the task requires it.

This reduces exposure of the most powerful account and makes sensitive actions more visible. The separation matters most for hosting, domain and deployment access.

Worth remembering

The less often a privileged account is used, the fewer chances it has to be phished, reused or left open on a device.

Protections that matter most

Enable multifactor authentication on administrator accounts, starting with the registrar, hosting, email provider and CMS. Use a unique password stored in a password manager, and keep recovery codes in a location controlled by the organization.

Where the platform supports it, retain logs of sign-ins and role changes. A login alert only helps when someone owns the response.

Technical detail

Multifactor authentication does not fix an overpowered role. It protects the sign-in; least privilege limits what the resulting session can do.

Vendors, absences and departures

Removing access is part of closing an engagement. It should not depend on the memory of the person who created the account.

When a team member or vendor changes

  • Create the replacement access first and confirm recovery before removing the old account.
  • Remove named accounts from the CMS, hosting, domain, code repositories and third-party services.
  • Rotate shared secrets including keys, service passwords or codes that cannot be attributed to one person.
  • Check recovery details so they remain under the organization’s control.
  • Record the review with the date, owner and any access deliberately retained.

Common questions

Should there be only one administrator?

Not necessarily. Avoid both a single unrecoverable account and many administrators without a need. Two protected, named owners can be more resilient than one shared login.

Should an agency remain an administrator after the engagement?

Only when a current contract and task require it. Otherwise, remove the account after verifying your own access and recovering the materials you need.

Is changing the password enough when someone leaves?

No. Remove named accounts, revoke sessions and keys, rotate truly shared secrets and verify recovery methods.

Unsure who still controls the site?

An audit can inventory visible accounts, roles and the other control points your team should review.

Request an audit See what a WordPress audit examines