WordPress User Management Guide

• Model type: role-based
• Description: WordPress uses a role-based access control (RBAC) model. Each role is a named collection of capabilities (granular boolean flags). Core ships with six roles: Super Admin, Administrator, Editor, Author, Contributor, and Subscriber. Capabilities can be added or removed from roles programmatically via add_cap() and remove_cap(), or via plugins such as Members or User Role Editor. Roles are stored in the wp_options table (wp_user_roles) and per-user capability overrides are stored in wp_usermeta.
• Custom roles: Yes
• Custom roles plan: Custom roles are available on WordPress.org self-hosted (free, via code or plugin). On WordPress.com, custom roles require a plugin-capable plan (Business plan, $25/month, or higher). WordPress VIP supports custom roles via code deployment.
• Granularity: Over 70 built-in capabilities covering content types (posts, pages, custom post types), taxonomy management, plugin/theme management, user management, and site options. Custom post types can register their own capability sets. Individual user capability overrides can be set independently of their assigned role.

1. Log in to wp-admin as an Administrator.
2. Navigate to Users → Add New (URL: /wp-admin/user-new.php).
3. Enter the new user's username (required, cannot be changed after creation).
4. Enter the new user's email address (required).
5. Optionally enter First Name, Last Name, and Website.
6. Set a password: WordPress auto-generates a strong password, or enter a custom one. Check 'Send User Notification' to email login credentials to the new user.
7. Select a Role from the dropdown (Subscriber is the default).
8. Click 'Add New User'.

Required fields: Username (unique, alphanumeric, cannot be changed after creation), Email address (unique per site)

Watch out for:

• Usernames cannot be changed after account creation through the WordPress admin UI; a plugin or direct database edit is required.
• Email addresses must be unique across the site; attempting to add a duplicate email returns an error.
• On WordPress Multisite, 'Add New User' at the site level adds an existing network user to the site. Creating a brand-new network user requires Network Admin → Users → Add New.
• The 'Send User Notification' checkbox sends credentials in plaintext email; advise users to change passwords immediately.
• On WordPress.com, users must accept an invitation email before they appear as active site members.
• WordPress.com free and Personal plans limit the number of users who can be added to a site.

• Can delete users: Yes
• Delete/deactivate behavior: WordPress does not have a native 'deactivate' or 'suspend' user state in core. The only built-in options are: (1) Delete the user account permanently, or (2) Change the user's role to a role with no meaningful permissions (e.g., Subscriber or a custom no-access role) as a soft-disable workaround. Some plugins (e.g., Disable Users, WP User Manager) add a true deactivation/suspension capability. On WordPress Multisite, a user can be removed from a specific site without deleting their network account.

1. To soft-disable without a plugin: Navigate to Users → All Users, click the user's name or 'Edit', change their Role to 'Subscriber' (or a custom no-permission role), and click 'Update User'. This prevents meaningful access without deleting the account.
2. To use a plugin-based deactivation: Install a plugin such as 'Disable Users', then use the plugin's interface to mark the user as disabled, which blocks login while preserving the account and content.
3. On Multisite, to remove a user from one site without deleting: Network Admin → Sites → [Site Name] → Users, then remove the user from that site. Their network account and other site memberships remain intact.

Watch out for:

• There is no undo for user deletion in WordPress core. Content reassignment or deletion must be decided at the time of the delete action.
• On Multisite, deleting a user from the Network Admin permanently removes them from all sites on the network. Removing them from a single site only revokes that site's access.
• Application Passwords (introduced in WordPress 5.6) issued to a user are all invalidated when the user is deleted; any REST API or XML-RPC integrations using those credentials will fail immediately.
• WordPress does not log user deletion events natively; an audit log plugin (e.g., WP Activity Log) is needed to track who deleted whom and when.
• If the deleted user was the sole Administrator, the site may be left without an admin account. WordPress.com has safeguards; self-hosted installs do not enforce this.

• Where to check usage: WordPress.org self-hosted: Dashboard → Users → All Users (shows total user count and roles). WordPress.com: My Sites → [Site] → Users → Team (shows all invited members and their roles).
• How to identify unused seats: WordPress core has no built-in last-login tracking. To identify inactive users, install a plugin such as 'WP Last Login' or 'Inactive Logout' which records last login timestamps. On self-hosted installs, last login data can also be queried from wp_usermeta if a plugin has written it. No native idle-user report exists in core or WordPress.com admin.
• Billing notes: WordPress.org self-hosted has no per-seat billing; all user management costs are $0 at the software level. WordPress.com plans are billed per site, not per user seat, so adding or removing users does not directly change the monthly invoice. WordPress VIP pricing is based on monthly unique visitors and contracted scope, not user count. Plugin licenses for SSO, SCIM bridges, or role management tools are separate costs paid to third-party vendors.

WordPress.org self-hosted carries no per-seat cost at the software level; every app your team connects to WordPress pays only for hosting and infrastructure. WordPress.com plans are billed per site, not per user seat, so adding or removing users does not change the monthly invoice directly.

WordPress VIP pricing starts at $25,000/year and scales with monthly unique visitors - not headcount. Plugin licenses for SSO bridges, role management tools, or SCIM connectors are separate costs paid to third-party vendors and should be budgeted independently.

Because WordPress core has no native last-login tracking, identifying and removing inactive users requires an additional plugin. That hidden operational overhead - installing, maintaining, and auditing plugin-based tooling - is the real cost of manual lifecycle management at scale.

The most consistent friction point practitioners report is the absence of native SCIM support. Enterprises must rely on third-party plugins or custom development for automated provisioning and deprovisioning, which introduces maintenance risk and compliance gaps.

Two other issues surface repeatedly: there is no native user deactivation or suspension state in core (workarounds require plugins or role-demotion to Subscriber), and usernames cannot be changed after account creation through the admin UI. Both create friction during employee name changes or offboarding.

On Multisite deployments, the boundary between site-level and network-level user management is a persistent source of errors. Deleting a user from Network Admin removes them from every site on the network - a destructive action with no undo in core.

Common complaints:

• No native SCIM support; enterprises must rely on third-party plugins or custom development for automated provisioning and deprovisioning.
• No native user deactivation/suspension state in core; workarounds require plugins or role manipulation.
• Usernames cannot be changed after account creation through the admin UI, causing friction when employees change names or email handles.
• No built-in last-login or user activity reporting; audit and compliance use cases require additional plugins.
• On Multisite, the distinction between site-level and network-level user management is confusing and error-prone for administrators unfamiliar with the architecture.
• WordPress.com invitation-based user addition requires the invitee to accept via email before access is granted, which can delay onboarding.
• No native bulk user import via CSV in core; this is a frequently requested feature that requires a plugin.
• Plugin dependency for provisioning features creates maintenance overhead and potential security surface area.
• VIP SSO setup has specific requirements for support access that differ from standard SSO implementations.
• Deleting a user with a large volume of content requires a manual reassignment decision at deletion time with no batch or scheduled option.

WordPress is the right choice for teams that need a flexible, self-hosted content platform and are comfortable managing user lifecycle through plugins or custom code.

Every app in your stack that relies on WordPress user roles will inherit whatever gaps exist in your provisioning process, so the role model and offboarding workflow deserve explicit design before rollout.

WordPress.com hosted plans are appropriate for smaller teams with straightforward role needs. WordPress VIP is the only hosted tier with enterprise SSO integration support, but it still lacks native SCIM - JIT provisioning via SSO is the closest available substitute.

Teams with strict deprovisioning SLAs or audit requirements should plan for plugin-based tooling (audit logs, deactivation, last-login tracking) from day one rather than retrofitting later.

Bottom line

WordPress gives teams a capable, role-based permission model with meaningful flexibility at the self-hosted tier, but it offloads nearly every enterprise identity management requirement - SCIM, user deactivation, audit logging, last-login reporting - to third-party plugins or custom code.

For organizations where timely deprovisioning and access auditability are non-negotiable, the plugin dependency chain is a real operational commitment, not a minor footnote. Plan the tooling stack before you scale the user base.