WordPress User Roles and Capabilities: A Least-Privilege Guide

WordPress controls what each person can do through roles and capabilities. A capability is a single permission, such as publish_posts or install_plugins. A role is a named bundle of capabilities. WordPress ships with six predefined roles: Super Admin (multisite only), Administrator, Editor, Author, Contributor and Subscriber. Giving each person the lowest role that lets them do their job is one of the cheapest and most effective security measures a site owner can take.

In practice, most small business sites have too many Administrators: the agency, a former freelancer, a plugin vendor's support account, the owner's personal login. Every one of those accounts can install plugins, change settings and create more administrators. If any of them is phished or reuses a leaked password, the whole site is exposed.

This guide explains each default role, how to apply least privilege, when to create custom roles, how multisite changes the picture, how application passwords work and how to roll out two-factor authentication. It reflects WordPress 7.1.2, the current version as of October 2026.

The default roles and what they can do

The official Roles and Capabilities documentation summarizes each role. The table below adds the capabilities that matter most for day-to-day decisions.

The documentation makes a useful point: "One particular role should not be considered to be senior to another role. Rather, consider that roles define the user's responsibilities within the site." An Editor is not a junior Administrator; the two roles do different jobs.

Two details are easy to miss:

• unfiltered_html. On a single site, Administrators and Editors can post unfiltered HTML, including scripts. On multisite, only Super Admins can. That makes an Editor account a meaningful target on single sites.
• Uploads. Contributors cannot upload files by default; Authors can. If guest writers need images, an editor can add them, or you can create a custom role.

Plugins can add their own roles too. Store, membership and LMS plugins often register extra roles, so check Users > All Users for roles you did not create.

Applying least privilege

Least privilege means each account gets exactly what its job requires and nothing more. A practical mapping for a business site:

• Owner: one Administrator account, used for administration only, with two-factor authentication.
• Agency or developer: one named Administrator account per person, removed when the engagement ends. Avoid shared "agency" logins.
• Marketing manager: Editor. They can publish and manage all content without touching plugins or settings.
• Staff writers: Author.
• Freelancers and guest writers: Contributor, so an Editor reviews before anything goes live. With Notes (WordPress 6.9+), reviewers can leave feedback on specific blocks; Contributors and Authors can see and add notes on their own posts.
• Customers and members: Subscriber or the role your store or membership plugin provides.
• Plugin vendor support: a temporary account, removed after the ticket closes.

Also check Settings > General. The "New User Default Role" setting decides which role people get when they register; if public registration is on, that should be Subscriber, never anything higher.

Creating custom roles

The default roles fit most sites, but sometimes you need something in between: a designer who can edit templates but not install plugins, or an SEO specialist who can edit all pages but not change users.

With code

The documentation notes that capabilities "can be assigned or removed using the add_cap() and remove_cap() functions," and that "new roles can be introduced or removed using the add_role() and remove_role() functions." Keep that code in a small plugin rather than the theme, so the roles do not depend on which theme is active.

A Site Editor role

The roles documentation now includes guidance for a custom Site Editor role. It names edit_theme_options as "the primary capability used by WordPress when determining whether a user can access and manage templates through the Site Editor," alongside edit_posts, edit_pages, edit_others_posts, read and upload_files depending on what the person needs to edit. That is a cleaner option than making a designer an Administrator. See our Site Editor guide for what that access includes.

With a plugin

Role-editor plugins provide a screen for creating roles and ticking capabilities. Two long-standing options on WordPress.org, listed neutrally:

Before installing any role plugin, check its update history and security record, and document every change you make; a mis-ticked capability is easy to forget and hard to spot later.

Multisite and the Super Admin

In a multisite network, one WordPress installation runs many sites. The Super Admin role "encompasses every possible task that can be performed within a Network," while each site's Administrator is limited to that site. Several capabilities that a single-site Administrator has become Super Admin only on multisite, including installing, updating, editing and deleting plugins and themes, editing and deleting users, updating core and posting unfiltered HTML. Network-level capabilities such as create_sites, manage_network and manage_network_plugins belong only to Super Admins.

Keep the number of Super Admins as small as possible, since one compromised Super Admin affects every site on the network. Our article on multisite WordPress agencies covers when multisite is worth the extra governance.

Application passwords

Application passwords were introduced in WordPress 5.6. They let an external app (a mobile app, an integration, an automation tool or an AI agent) authenticate to the REST API or XML-RPC without your real password. According to the official integration guide:

• they are 24-character generated passwords that "cannot be used on wp-login.php," so they are for apps, not interactive logins,
• each user creates and revokes them individually from their profile screen,
• WordPress records when each one was last used, including date and IP address,
• by default they require HTTPS, and developers can control availability with the wp_is_application_passwords_available filter,
• they inherit the full capabilities of the user who created them; there is no built-in way to scope them to fewer permissions.

That last point is the important one. An application password created by an Administrator is effectively an Administrator credential. Create a dedicated user with the lowest role the integration needs, generate the application password on that account, name it after the integration and revoke it when the integration is retired. The planned work for WordPress 7.2 includes application password hardening, but planned items may change before release.

Two-factor authentication in practice

WordPress core does not include two-factor authentication (2FA) as of October 2026. It does use bcrypt password hashing (since 6.8), which makes stolen password hashes harder to crack, but that does not help when a password is phished or reused. 2FA does.

The Two Factor plugin is published by WordPress.org (version 0.17.0, 100,000+ active installs, tested up to 7.1.2 as of October 2026). It supports authenticator apps (TOTP), email codes and backup codes. Each user sets it up under Users > Your Profile, and administrators can disable specific methods site-wide under Settings > Two-Factor. Security suites such as Kadence Security (formerly Solid Security and iThemes Security) also include two-factor options.

A rollout that works:

1. Require 2FA for every Administrator and Editor first, since they hold the most power.
2. Prefer authenticator apps over email codes; email accounts get compromised too.
3. Make every user save backup codes in a password manager.
4. Document a recovery process before someone loses a phone.
5. Extend 2FA to Authors and anyone with access to customer data.

For the wider picture, see our WordPress security guide.

A quarterly user audit

Roles drift over time. Put a short review on the calendar every quarter:

• List every Administrator and confirm each one is a named, current person.
• Remove or downgrade accounts for former staff, freelancers and vendors.
• Review application passwords on each privileged account and revoke unused ones.
• Check for unexpected roles or users created by plugins.
• Confirm 2FA is active for every privileged account.
• Confirm the New User Default Role is Subscriber if registration is open.

If you discover an Administrator account nobody recognizes, treat it as a possible compromise; our guide to what to do if WordPress is hacked walks through the response.

Conclusion

Roles and capabilities are WordPress's built-in access control, and using them well costs nothing. Keep Administrators to a minimum, match every account to the smallest role that fits, create custom roles for in-between jobs, treat application passwords as the full credentials they are and put 2FA on every privileged account. For more guides, visit the WordPress resource hub. If you would like a professional user and security review as part of ongoing care, eSEOspace offers website maintenance services.

Frequently asked questions