2026 WordPress 7.2 Multisite Permissions: Can Sudo Mode Isolate Sites?

No. WordPress 7.2's roadmap describes sudo mode as planned re-authentication for certain sensitive actions, not as isolation between sites; do not rely on it to separate sites. If your sites share code, files, databases, or runtime accounts, assess those boundaries directly and split installations or runtime environments where the trust or business impact calls for it.

This guide is for site owners managing several independent WordPress properties, ecommerce leads reviewing team permissions, and operators maintaining websites for multiple clients.

As of November 1, 2026, the roadmap targets WordPress 7.2 for early December 2026; its listed work is not a promise that every item will ship.

Last updated

Last updated November 1, 2026. The status and planned release timing were checked against the WordPress 7.2 roadmap, the WordPress 7.2 project page, and the official Multisite and multiple-installation documentation.

WordPress 7.2 multisite permissions address authentication, not site isolation

The key distinction is the security goal. Re-authentication asks, “Is the person currently performing this sensitive action really the authorized user?” Isolation asks, “Can a compromised site, plugin, account, or process affect another site?” Those are separate controls.

The WordPress 7.2 roadmap describes preliminary work on sudo mode that may require users to confirm their identity again before certain high-privilege actions. The roadmap also says that listed work may not all be included in the final release. Treat this as planned functionality until the final release documentation confirms what shipped and how it works.

Even if sudo mode ships as described, it would not, by itself:

• Prevent a plugin with broad access from changing files used by other sites in the same installation.
• Create separate database credentials or restrict one site's code from using shared credentials.
• Run each site's PHP code under a distinct operating-system account.
• Stop an administrator who is authorized across a network from changing network-wide settings.

Do not plan a security boundary around a re-authentication prompt. First inventory what each person and process can actually access.

Separate the WordPress role from the server account

WordPress permissions govern actions inside the application. Server permissions govern access to files, processes, and system resources. One does not replace the other.

In a Multisite network, a site administrator manages the site-level functions assigned to that role. A network super administrator has broader control over network settings and sites. Check both levels: a team member who only needs to update content may not need network administration, while a developer who can alter themes or plugins may have a much wider effect.

Then review how staff sign in to the server. A WordPress administrator account is not the same as an SSH account, a deployment account, or the operating-system user running PHP. If multiple people share a server login, you may not be able to trace who changed files or limit one person's access without changing the deployment model.

For each team member, record:

• Which WordPress sites and network settings they can change.
• Whether they can install or update themes and plugins.
• Whether they can edit configuration, deploy code, or access the database.
• Which server account they use, and whether that account is shared.
• Whether their access is still required for every site they can reach.

A small team can still have a large permissions problem. The important question is not how many people have accounts; it is whether one person's credentials can change code or data across sites with different owners or risk levels.

Shared code and plugins create a common risk area

WordPress Multisite uses one WordPress installation to run a network of sites. Its sites share the installation's core files, and network administrators can manage themes and plugins across the network. The official Multisite administration guide describes these network-level controls.

That setup can be convenient when the sites have the same owner, compatible release schedules, and a shared maintenance team. A central update can reduce repetitive work. But shared code also means that a faulty or compromised plugin may affect more than the site where a problem first appears, depending on its permissions and how the installation is configured. Sudo mode does not isolate plugin execution from other sites in the same installation.

Separate WordPress installations offer more control over release timing and code changes. You can stage updates for one property without necessarily updating every other installation at the same time. The tradeoff is operational: you must maintain separate codebases, update routines, monitoring, and recovery processes.

Consider a cross-border retailer that runs a Japanese-language store and several regional content sites. If the same team owns all properties and tests every plugin update against the whole network, Multisite may fit. If an external agency manages one site, or a store has a different maintenance window and incident impact, shared code and shared administration may create an avoidable risk. In that case, separate installations can make the operational boundary clearer.

Database separation helps with credentials, but it is not complete isolation

WordPress Multisite uses one installation and one database instance for the network. The official Multisite documentation explains this architecture. WordPress also documents multiple independent installations, which can be configured with separate databases.

A separate database and database user can improve credential management. It can also make it easier to assign backups, access rules, and database maintenance to a particular site. If every site uses the same database credentials, a compromise that exposes those credentials may put more than one site's data at risk.

However, do not treat separate databases as a complete security boundary. If all sites run with the same operating-system account, can write to shared directories, or use a shared deployment credential, the separation is incomplete. A database split does not automatically create a separate PHP process, file owner, or administrator.

Use separate database credentials when you need clearer data access and recovery boundaries. If sites belong to different customers or have different trust levels, also examine code ownership, file permissions, process users, and server access.

File ownership and PHP execution determine the remaining boundary

The filesystem is where many plans for “separate sites” either hold up or fail. WordPress's file permissions guidance explains how ownership and permissions affect which accounts can read or write WordPress files.

Check the actual deployment, not just the directory layout. Two sites in separate folders may still be writable by the same PHP user. A shared deployment account may be able to replace code in both. Conversely, distinct file owners do not help if the PHP process or a privileged administrator can write to every site's directory.

For each installation, verify:

• The owner and group of WordPress core, themes, plugins, uploads, and configuration files.
• Which account runs PHP and which paths it can write.
• Which deployment or update account can change executable code.
• Whether one site's plugin or upload directory is writable from another site's runtime.
• Whether configuration files expose database credentials to other site processes.
• Whether backups are stored outside the same writable area as the live site.

Separate installations are often a practical step up from one shared Multisite network, but they are not equivalent to separate virtual machines or separate physical servers. If your threat model requires a compromised site to have a limited effect on another customer's site, validate the process and operating-system boundaries too.

Choose the deployment model by trust and impact

Use the relationship between sites, administrators, code, and recovery requirements to make the decision. No single setup is right for every group.

Multisite is a reasonable fit when:

• The sites have the same owner and a trusted administrator group.
• They can share a codebase and a coordinated update schedule.
• A network-level administrator is acceptable for all sites.
• A shared incident or maintenance window would not create an unacceptable business impact.

Several independent installations are a better fit when:

• Different teams or clients need separate WordPress administration.
• Sites need different plugin sets or release schedules.
• Separate databases, credentials, and backups are part of your operations plan.
• You want a failure or update on one installation to be easier to diagnose without changing every site's code at once.

Stronger runtime separation may be necessary when:

• Sites belong to parties that do not trust each other.
• A compromise must not let one site's process modify another site's executable files.
• Regulatory, contractual, or business-impact requirements call for a tighter boundary.
• Shared operating-system accounts, PHP workers, or deployment credentials are unacceptable.

The tradeoff is straightforward. Multisite centralizes management but shares more of the application surface. Separate installations give you more control but add maintenance work. Stronger runtime boundaries can reduce shared exposure, but they require deliberate configuration and ongoing operations. Do not choose a model based only on the number of sites or on whether sudo mode appears in a release plan.

Complete this permissions and isolation review before choosing

Use this checklist with the person responsible for WordPress, the server, and incident response. If you cannot verify a boundary, treat it as shared until you can.

• [ ] List every site, owner, business purpose, and team responsible for changes.
• [ ] Mark which sites share a WordPress installation, themes, plugins, and update schedule.
• [ ] Review WordPress site administrator and network super administrator access; remove roles that are broader than the person's duties.
• [ ] Identify shared SSH, deployment, database, and hosting-panel credentials; assign named accounts where your operations model supports them.
• [ ] Record the database name and database user for each site, then verify which sites can access each credential.
• [ ] Check file owners, write permissions, PHP runtime users, and writable paths for every installation.
• [ ] Confirm that backups are recoverable and not exposed to the same account or writable path as the live site.
• [ ] Decide what one site's plugin failure or administrator mistake is allowed to affect.
• [ ] Choose Multisite only when shared administration and shared code match your trust model; otherwise compare separate installations or stronger runtime boundaries.
• [ ] Recheck the final WordPress 7.2 documentation before treating sudo mode as an available control.

If your current setup uses one shared administrator account, shared database credentials, and a common writable codebase, start by documenting those facts and narrowing access. Do not wait for a planned authentication feature to solve an isolation problem.

Frequently asked questions

Can sudo mode separate sites from each other?

No. The roadmap describes re-authentication for certain sensitive actions, not a technical boundary between websites. Even if the feature ships, it does not imply separate files, database users, plugins, or PHP processes. Check the final WordPress documentation, then assess the actual access paths that connect your sites.

What is the practical difference between Multisite and separate installations?

Multisite organizes a network through one WordPress installation and one database instance. Independent installations can use separate codebases and databases, which helps with updates, credentials, and maintenance boundaries. That setup still needs correct file permissions and runtime separation if you need to limit what a compromised site can affect.

How do I assign permissions across several WordPress sites on one server?

Separate WordPress roles from server access. Give each person only the site-level or network-level permissions they need, then check SSH and deployment access, database credentials, file ownership, and the PHP runtime user. If different clients or teams should not trust one another, do not assume separate folders alone provide sufficient isolation.

Should every WordPress site have its own database and database user?

Use separate database users when you need distinct credentials and clearer access control. Separate databases can also make backup and maintenance ownership easier to manage. But neither creates full isolation if the sites share writable files, privileged system accounts, or a PHP process that can access every installation.

Match the server choice to the isolation model

A dedicated server gives you control over the machine's resources; it does not automatically isolate WordPress sites from one another. You still need to design application roles, database credentials, file permissions, PHP execution, backups, and deployment access. A shared VPS or public-cloud instance may be enough for a few low-risk sites, but shared infrastructure can also bring resource contention, less predictable CPU allocation, and limits on how much of the environment you can configure. Those issues are separate from WordPress permissions, so evaluate both the hosting model and the application boundary.

If several business-critical sites need stable, long-running resources and you want the whole physical server dedicated to your workloads, an AmdMetal AMD physical server in Tokyo is worth comparing with a shared instance. It can give your team a dedicated machine for its chosen deployment design, but it is not a turnkey site-isolation service. Review the server deployment information alongside your permissions plan, and use the AmdMetal server overview to assess whether a dedicated machine fits your operating needs.

Before choosing, write down which sites share administrators, code, databases, and runtime accounts. If the sites do not share the same trust level, separate the boundaries that matter instead of treating sudo mode—or a server purchase—as the security control.

Frequently asked questions