WordPress Multisite centralizes many websites under one WordPress installation. That can simplify updates and governance, but it also concentrates risk. A vulnerable network-enabled plugin, stolen super-admin session or server compromise can affect many sites at once.
The security model should reflect that shared architecture. Site administrators have reduced capabilities, while super administrators control plugins, themes and network settings. Protecting that small group and the shared codebase is the foundation of Multisite security.
Book a free, no-obligation strategy call and we'll map out your next move.
1. Confirm Multisite is the right boundary
Multisite is useful when sites share ownership, infrastructure and governance. It is not strong tenant isolation for unrelated organizations with conflicting compliance, data residency or administrator requirements. Sites share core files, plugins, themes and commonly the same database service.
If one customer requires independent server access, release timing or incident containment, a separate installation may be safer and easier to explain. Architecture should follow risk and operating responsibility, not only convenience.
2. Harden super-administrator access
Use the smallest possible number of super admins, individual accounts, password-manager-generated credentials and MFA. Review the list monthly and after staff or vendor changes. Do not use a super-admin account for routine editing on individual sites.
Apply the account review process in how to find and remove rogue WordPress administrators across both network and site-level roles.
- Reserve super-admin privileges for network operations.
- Use a separate lower-privilege account for normal content work.
- Revoke sessions and application passwords during offboarding.
- Alert on super-admin creation, deletion and privilege changes.
3. Govern plugins and themes centrally
Only trusted maintainers should install code. Keep a documented approved set, remove abandoned extensions and test network-wide updates on a representative staging network. A plugin activated for the entire network expands the blast radius of a flaw or compatibility problem.
Evaluate ownership, update practices and dependencies with our WordPress plugin supply-chain security guide before adding network-level code.
4. Control uploads and storage
Define allowed file types and storage quotas for the network. Treat user-uploaded SVG, archives and office documents according to their actual risk. Ensure uploads cannot execute as code, and keep sensitive tenant documents behind authorization rather than relying on a public media URL.
Use the directory ownership and server rules in the WordPress file permissions guide to protect shared core, plugin, theme and upload locations.
5. Protect domains, cookies and HTTPS
Mapped domains need valid HTTPS, controlled DNS and consistent redirect behavior. Review cookie scope carefully so authentication behaves as intended across domains and paths. Test logins, password resets and administration from every domain pattern after proxy or CDN changes.
6. Design backups for network-wide and site-level recovery
A full-network backup protects shared files and databases, but operational recovery may require restoring one site without rolling back every tenant. Confirm what the backup product can restore, how domain mappings are handled and whether large networks exceed execution or storage limits.