Do we actually need SSO, or are WordPress logins enough?

Native login with standard roles is our default, and often the right answer. SSO earns its complexity in three situations: your security policy requires identity to live in one directory, the team is large enough that manual offboarding will eventually be missed, or you need multi-factor enforced consistently rather than per user. We run SAML single sign-on and an activity log on this site, so the trade-offs below are not theoretical.

Which SSO option do you implement?

It depends on the identity provider you already operate, and on budget. miniOrange SAML SSO: free tier, quick to stand up against common providers, limited customization and a cumbersome admin interface. Auth0: multi-factor, a rules engine and enriched profiles, with paid plans once the user count grows. LDAP, Azure AD or Google Workspace direct: the right call when the directory is already the system of record. Introducing a new identity provider to solve a WordPress problem is usually the wrong trade.

What happens if SSO breaks and nobody can log in?

You use the local administrator account we set up for exactly that. It bypasses the identity provider, your team holds the credentials, and the recovery path is in the handover documentation. We test the full flow in staging with more than one provider account before production. A misconfigured SSO integration fails closed, which is the safe direction and also the one that locks out the people who could fix it.

Can we require approval before content goes live?

On WordPress VIP, yes. Automattic's VIP Workflow plugin adds reviewers and approvers inside the editor and holds publication until the right person signs off, which matters when content passes through legal or communications. Outside VIP we have not standardized on an equivalent. Edit Flow and Oasis Workflow both work, but Edit Flow's interface is dated and Oasis can be heavy to maintain, so we choose per project. Before reaching for a plugin, check how far native WordPress gets you. Pending review, scheduled publishing and revision history cover a surprising amount of what teams describe as workflow.

How do permissions work when we run more than one site?

Roles are granted per site, which is the part that surprises people. A user added to the network is not an editor everywhere by default, and network administrator is a separate and much larger grant. That is usually an advantage. Regional teams get real authority over their own property without touching anyone else's. It does mean the role matrix has to be designed once and applied consistently rather than rebuilt at every launch. More on that shape is on our WordPress multisite page.

Where does user management end and security begin?

User management answers who is allowed to do what, and proves what they did. Security covers everything that happens regardless of who is logged in: hardening, patching, vulnerability monitoring, firewall rules and backups. The two overlap at the audit log, which is a compliance artifact and a detection tool at once. We scope them together and deliver them as separate workstreams, because sign-off comes from different people. The security side is on our WordPress security page.

User management

Enterprise WordPress user management, from single sign-on to audit trail

Federated login against the identity provider you already run, roles that match what people actually do, and an activity log that answers who changed this without anyone opening the database.

Home
Capabilities
User Management

What we configure

Seven decisions that turn user accounts into an access model

WordPress ships with five roles and a login form. That is enough for a team of five. At two hundred users spread across editorial, legal, agency partners and regional offices, the gaps stop being cosmetic.

Federated login against your identity provider

SAML or OAuth against Azure AD, Google Workspace, LDAP or Auth0, with multi-factor enforced by the provider instead of bolted onto WordPress. Accounts stop living in two places, so removing someone from your directory removes them here.

A break-glass account that does not depend on SSO

Every federated setup gets a local administrator that bypasses the identity provider, tested in staging before launch and documented as an emergency path. Federated login is a single point of failure until you plan for it failing.

Roles named after jobs, not WordPress defaults

Capabilities assigned in code with add_role and add_cap, or through the Members plugin when the client wants to adjust them without a deploy. Regional Editor, Compliance Reviewer and Report Editor are roles people recognize. Author and Contributor are not.

A written role map handed to your team

Every role is documented with what it can and cannot do, so who is allowed to publish this becomes a question your team answers on its own. Editors get a short guide for the tasks they run themselves, like scheduling a post or sending one for review.

An approval gate before anything publishes

On WordPress VIP we use Automattic’s VIP Workflow plugin, which puts reviewers and approvers inside the editor. Off VIP we have not standardized on one plugin, so we evaluate Edit Flow or Oasis Workflow per project.

Activity logging your compliance team can export

WP Security Audit Log, or the Melapress premium tier when retention and notification rules matter. Logins, content changes, user changes and configuration changes, with export paths agreed up front. On VIP we push events to external logging over API or webhook.

Joiners and leavers as a documented process

Onboarding and offboarding steps written down, with a scheduled permission review so access does not quietly accumulate. Permission creep is rarely a configuration error. It is an account nobody removed.

Proof

Role-based access at five-thousand-document scale

Everest Group, a research and consulting firm, ran its gated reports portal and its marketing site on separate platforms with an access system that could not keep up. 40Q unified both on one WordPress instance with federated login and a granular permissions layer. These figures describe the access model we built, not campaign results.

5,000+

Reports migrated onto a single WordPress instance, each one served behind role-based access

Auth0 SSO

Unified authentication across the reports portal and the marketing site, replacing two separate login paths

Membership tiers

Role-based access mapped to what each subscriber level is entitled to open

How we scope it

Three questions, and they do not share an owner

Access work goes wrong when it is run as one project. Authentication, authorization and accountability have different owners, different failure modes and different sign-off.

Authentication: who gets in

Owned by IT. The decision is whether WordPress trusts your identity provider or keeps credentials of its own. Once it trusts the provider, offboarding becomes a directory task, which is where it belongs.

Authorization: what they can touch

Owned by whoever runs the content organization. This is a mapping exercise before it is a technical one. List what each team genuinely does, then grant only the capabilities those actions require.

Accountability: what happened

Owned by security and legal. Decide which events are worth recording, how long they are kept and whether they need to leave WordPress for a SIEM. Answer that before installing a logging plugin, not after.

What enterprise teams ask us about WordPress access

The questions that come up in the first call with IT.

Related insights

Keep reading on access and governance

Controls, editorial workflow and the IT conversation that sits behind both.

IT manager reviewing CMS security checklist

Mar 28, 2026

WordPress

Request an access and permissions review

We will look at how people authenticate today, which roles exist and what your activity log actually captures, then send you the findings whether or not you work with us.

Request an access review Talk to a WordPress engineer