WordPress Admin Governance: Roles, Approvals and MFA

WordPress user roles decide who can write, publish, install plugins and change settings, so they are the first control in any admin governance plan. For organisations with many editors, good governance means giving each person the smallest role that lets them do their job, adding an approval step before anything goes live, requiring multi factor authentication for every account with power, and removing access the day someone leaves. This guide covers the people and permissions side; technical hardening is a separate topic.

Why admin governance matters more than the login page

Most WordPress sites in growing organisations collect accounts faster than anyone removes them. A marketing agency needed access for a campaign, a freelancer fixed a form, an intern wrote a few posts, a former manager still has an Administrator login. Each of those accounts is a door, and the person behind it may no longer be accountable to the business.

Technical controls such as firewalls and file permissions protect the server. Governance protects against the more ordinary failures: a well meaning editor who publishes a draft too early, a shared password passed around a team, or an old account that is taken over because its owner reused a password elsewhere. If you want the server side controls, our WordPress security hardening baseline covers them in detail.

WordPress user roles explained in plain terms

WordPress ships with a set of default roles, each a bundle of capabilities. The WordPress roles and capabilities documentation lists them in detail; the summary below is what a business owner needs to know.

The detail that surprises most teams

On a single site install, the Editor role includes the unfiltered_html capability, which allows posting raw HTML and even JavaScript into content. That is useful for embedding a tracking snippet, but it also means a compromised Editor account can inject scripts into public pages. On multisite, only Super Admins hold that capability. Treat Editor as a powerful role, not a junior one.

When custom roles make sense

WordPress lets developers add new roles with the add_role() function, and many organisations need them. A common example is a "Content Reviewer" who can edit and publish other people's posts but cannot manage users or touch settings, or a "Shop Manager" style role limited to products and orders. Custom roles are worth the effort when a default role gives someone far more than their job needs. They are not worth it when they only rename an existing role.

Keep custom roles in code, documented and version controlled, rather than created through a plugin screen that no one remembers configuring. Plugins add their own capabilities too, so review roles each time you add or remove a plugin; our guide to plugin governance explains how to keep that list under control.

Designing a role model for many editors

The goal is admin access control that matches the organisation chart, not the history of who asked for what.

1. List every job that touches the site. Writer, reviewer, translator, SEO specialist, designer, developer, platform owner, external agency.
2. Map each job to the smallest role. Most writers should be Contributors or Authors. Very few people need Administrator.
3. Separate content power from platform power. Publishing an article and installing a plugin are different risks and should sit with different people.
4. Give agencies their own named accounts. Never a shared login, and never an Administrator account by default. Grant higher access for a defined task and remove it afterwards.
5. Write it down. A one page access policy that says which role each job gets, who approves new accounts and how often access is reviewed.

Hypothetical example: a Dubai property developer runs one WordPress site with twelve people logging in. After a review, two staff remain Administrators, three content leads become Editors, the writers become Contributors, and the external SEO agency gets a custom role that can edit metadata and pages but cannot install plugins or manage users. Nobody lost the ability to do their job, and the number of accounts that could change the platform fell sharply.

Building an approval workflow

An approval workflow stops content and changes going live without a second pair of eyes. WordPress gives you the basic building block: Contributors can only submit posts for review, so an Editor must publish them. For many organisations that is enough.

When the built in review step is not enough

• Several stages are needed, for example writer, legal review, brand review, then publish.
• Regulated content such as healthcare or financial information needs a recorded sign off.
• Arabic and English versions must both be approved before either goes live.
• Scheduled campaigns need a named approver for each launch.

In those cases, an editorial workflow plugin or a custom build can add extra statuses, assigned reviewers and notifications. On headless setups the preview and draft experience needs extra attention; our article on editorial workflow in headless WordPress covers that.

Do not forget configuration changes

Approval should also cover non content changes: new plugins, theme updates, changes to forms, redirects and user accounts. These usually belong in a simple change request process outside WordPress, with changes tested on a staging copy first and made on the live site by a named person.

WordPress MFA: making it a requirement, not an option

WordPress core does not include multi factor authentication out of the box, so WordPress MFA is added through a plugin or through a single sign on provider. The community maintained Two Factor plugin on WordPress.org, for example, supports authenticator app codes, email codes and backup codes, with security keys available through a separate add on.

Rules that make MFA work in practice

• Enforce it for every role that can publish or configure. Administrators, Editors, Authors and any custom role with similar power. Optional MFA tends to be skipped.
• Prefer authenticator apps or security keys over email codes. If someone's mailbox is compromised, email codes offer less protection.
• Plan for lost phones. Store backup codes securely and define who can reset MFA for another user, with identity checks.
• Consider single sign on for larger teams. If staff already sign in through a company identity provider with MFA, connecting WordPress to it means one place to enforce policy and one place to switch access off.

Application passwords and integrations

Since WordPress 5.6, users can create application passwords for integrations that call the REST API. They cannot be used to sign in to the dashboard, and they can be revoked from the user's profile. Include them in your reviews: an integration account with a forgotten application password is still a live credential. Disable the feature if no integration needs it.

Offboarding: the step most organisations miss

Governance fails quietly when people leave. The account stays active, the agency contract ends but the login does not, and months later no one knows whose account it is.

Offboarding checklist

• Remove or downgrade the account on the person's last day, and reassign their posts to another user rather than deleting the content.
• Revoke their application passwords and reset any MFA devices linked to shared accounts.
• Rotate any shared credentials they knew, such as hosting, DNS or SFTP access.
• Check for accounts they created for others and review those too.
• Record the change in the access log with the date and the person who made it.

For agencies and freelancers, put an end date on every account with extra rights when it is created. A quarterly access review then catches anything that slipped through: export the user list, confirm each person still works with you, and confirm their role still matches their job.

Audit logs: knowing who did what

WordPress does not keep a detailed activity history by default. An audit log, added through a reputable plugin or through your hosting platform, records events such as logins, failed logins, role changes, plugin installs, settings updates and content edits.

What a useful audit log captures

• Successful and failed logins, with time and source.
• User creation, deletion and role changes.
• Plugin and theme installation, activation and updates.
• Changes to published content and to key settings.

Store logs somewhere an Administrator on the site cannot simply delete, decide how long to keep them, and have someone actually read the alerts. Logs that contain personal data, such as names and IP addresses, fall under data protection rules; if you process personal data in the UAE, the UAE PDPL (Federal Decree-Law No. 45 of 2021) or the DIFC or ADGM regimes may apply, so confirm retention periods with your legal adviser.

Get your WordPress governance set up properly

Codeeo's WordPress development team builds sites with role models, custom roles, review workflows and audit logging designed in from the start, and reviews existing installs that have grown untidy. If your site is part of a wider platform, our web development and custom software teams can connect it to your identity provider and business systems. With an office in Dubai, UAE clients can sit down with the team in person. Contact us to talk through your current set up.