Free tools Windows power users keep installed
One-click scans. No signup required.
Secure a WordPress Multisite network as one shared control plane, not as a collection of unrelated sites. The user table, core files, network settings and any network-activated plugin or theme are shared; a stolen Super Admin account or vulnerable shared code can therefore expose every site. Start by reducing Super Admin access, enforcing strong passwords and two-step authentication, patching the entire software stack, requiring HTTPS and SFTP, restricting files and database privileges, and controlling registration, uploads and code installation in Network Settings. Finish with tested off-server backups, logging and a Multisite-aware review of every rewrite rule.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Why Multisite needs a different security model
Multisite runs several sites from one WordPress installation. Each site has its own content tables, but the network shares the user table and the installation’s core files. Depending on the configuration, sites use subdirectory addresses or domain and subdomain addresses. This creates a larger blast radius than a single site:
As an Amazon Associate I earn from qualifying purchases.
- A compromised Super Admin can change settings, install code or access all sites.
- A vulnerable network-activated plugin or theme is available across the network.
- A stolen shared user account can be used against every site where that account has a role.
- A mistake in server configuration, DNS, TLS or rewrite rules can affect all sites simultaneously.
Use a written inventory that identifies every Super Admin, network-activated extension, server, database, domain, certificate, backup location and integration. Treat those shared assets as the highest-impact controls and review them more often than individual site content.
Choose and document the network architecture before launch
WordPress asks you to choose subdirectory or domain/subdomain addressing during network setup. That choice is not a casual switch later, so settle the operational details before production sites are created.
#1 Best Overall
| Decision | What to verify | Security consequence |
|---|---|---|
| Subdirectory addresses | Permalink behavior, web-server rewrites and whether the existing site can safely host additional paths | One host and certificate can serve many sites, but an incorrect rewrite can route requests to the wrong site or break media |
| Domain or subdomain addresses | DNS records, wildcard or individual certificates, domain-mapping ownership and renewal procedures | Each hostname becomes part of the trust boundary; forgotten DNS or certificates can expose an abandoned site |
| Operational ownership | Who approves new sites, domains, certificates, plugins, backups and emergency changes | Clear ownership prevents unreviewed additions from bypassing network controls |
Record the selected mode, DNS provider, certificate method, renewal contacts, rewrite configuration and rollback procedure. Test a new site, login, upload, password reset and deletion in a staging network before opening registration or accepting production traffic.
Protect Super Admin accounts first
Super Admin is the network’s most powerful role. WordPress’s Hardening WordPress guidance warns that a strong password protects more than blog content because an administrator who is compromised may install malicious scripts that compromise the entire server. Apply the following controls in order.
Inventory and minimize access
- Open My Sites > Network Admin > Users and export or record every Super Admin.
- Remove the role from former staff, contractors, test accounts and accounts that only need site-level administration.
- Give each remaining administrator a separate named account. Do not share credentials or use a generic “admin” identity.
- Keep a break-glass account offline or otherwise tightly controlled, and document who may use it and how its use is reviewed.
Use strong authentication
- Require a unique, long password for every Super Admin and never reuse it on another service.
- Require two-step authentication through a trusted identity or security plugin, and store recovery codes outside the production server.
- Protect the email account used for password resets with the same two-step standard; a secure WordPress login is not enough if the mailbox is exposed.
- Review active sessions after a role change, suspected phishing or staff departure, and revoke sessions that are no longer needed.
Two-step authentication reduces the value of a stolen password but does not make a compromised browser or endpoint safe. Administrators should use patched devices, a password manager and a separate browser profile for network administration.
Patch every layer, not just WordPress
Maintain supported stable releases of WordPress, PHP, the operating system, web server, database engine and all plugins and themes. WordPress notes that older versions no longer receive security updates and that exploit details often become public after a fix is released. A delayed update can therefore increase risk even when no attack has yet been observed.
A safe update workflow
- Maintain a staging copy that includes representative subsites, domain mappings, uploads, scheduled jobs and integrations.
- Read the release notes and check compatibility with the active PHP and database versions.
- Take a fresh, restorable database and file backup before changing shared code.
- Update staging first. Test front-end pages, logins, media, forms, cron jobs, REST and AJAX actions, and network administration.
- Schedule production updates in a maintenance window. Update core and extensions, then verify every subsite and review error logs.
- Record versions, test results and the rollback point. If a release fails, restore the known-good state rather than leaving a partially updated network online.
Subscribe to security advisories for the software you run. Emergency patches should follow the same backup and verification discipline, but the window may be shorter.
Control plugins, themes and other code sources
Install code only from WordPress.org or reputable vendors whose ownership, update process and support contacts you can verify. Avoid abandoned, modified or unofficial copies. A plugin that is inactive on one subsite may still be installed in shared directories and become a future attack surface.
Network activation rules
- Limit network-level installation and activation to a small group of trusted Super Admins.
- Keep a register of every installed plugin and theme, its purpose, version, update owner and whether it is network-activated.
- Remove unused plugins and themes instead of merely deactivating them.
- Review code before network activation in staging, including its administrator capabilities, remote requests, file-write behavior and update source.
- Separate essential network-wide functionality from optional features that only one site needs; site-specific code should not receive network-wide reach without a reason.
Do not let site administrators install arbitrary extensions. If a business unit requests a new plugin, require a ticket, security review, staging test, backup and named owner.
Encrypt administration and server access
Require HTTPS everywhere administrators work
Use HTTPS for the front end, wp-login.php, wp-admin, Network Admin, password resets and API endpoints. Redirect plain HTTP to HTTPS at the web server, renew certificates before expiry and check that domain-mapped subsites receive the intended certificate. Secure cookies and mixed-content warnings should be part of the verification checklist.
Use SFTP, not unencrypted FTP
Use SFTP with individual accounts and key-based authentication for server access. Disable unused FTP services, restrict access by network where practical and log file-transfer activity. Hosting-panel passwords should not be reused for WordPress or database access.
Be careful with an extra Basic Authentication layer
A second HTTP authentication prompt can reduce exposure of an administration path, but a naive BasicAuth rule may block WordPress AJAX endpoints and cause editors or plugins to fail. Test login, the block editor, media uploads, REST requests and scheduled tasks in staging before applying such a layer. If exceptions are required, document each one and monitor them.
Apply least privilege to files and the database
File permissions should allow normal operation without making the entire installation writable by the web process. Keep WordPress core, wp-admin and wp-includes writable only where an update procedure explicitly requires it. Treat wp-content, especially uploads, as user-supplied content and prevent execution of scripts from upload directories at the web-server level.
| Asset | Practical control | What to test |
|---|---|---|
Core, wp-admin, wp-includes |
Readable by the web service; writable only during controlled updates | WordPress can run normally, while an uploaded request cannot modify core files |
wp-content/uploads |
Allow media writes but block script execution and direct access to sensitive file types | Images and documents upload correctly; a test script is downloaded or denied rather than executed |
| Configuration and secrets | Restrict access to wp-config.php, environment files, keys and server credentials |
Web requests cannot download them and only the required service accounts can read them |
| Database account | Normally allow SELECT, INSERT, UPDATE and DELETE for application work | Backups, normal requests and restoration work with the documented account |
Schema updates may require structural privileges during core or plugin upgrades. Reducing database privileges without a tested upgrade procedure can turn a security measure into an outage. Use a controlled maintenance account or temporary, audited elevation for migrations, then return to the least-privilege account.
Use Network Settings to close common entry points
In My Sites > Network Admin > Settings, review every field and record the intended value. The exact labels can vary slightly by WordPress version, but the controls cover the following areas.
Registration and onboarding
- Disable “Both sites and user accounts can be registered” unless open registration is a documented requirement.
- If users or sites must register, require email verification where available, moderate new sites and review the first administrator account before granting additional rights.
- Use the banned names list to reserve names such as
admin,administrator,root, support identities and names that could impersonate the organization. - Use allowed or blocked email domains to keep registration within the intended organization or to reject disposable and known-abuse domains.
Uploads and file types
- Set a network upload quota appropriate to the sites’ business needs; an unlimited quota lets one site consume shared storage.
- Allow only the file extensions and MIME types that users genuinely need. Do not enable executable formats for convenience.
- Pair these settings with server-side execution blocking, malware scanning and storage monitoring; an extension allow-list alone is not a complete upload defense.
Administrator capabilities
Restrict the menus and settings exposed to site administrators when those controls are managed centrally. Limiting theme, plugin, user and upload administration reduces accidental changes and makes it easier to distinguish a site-level compromise from a network-level one. Revisit the restrictions whenever a new business requirement is approved.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchReview every new site and user
Make onboarding a checklist: verify the owner, domain, purpose, administrator identity, required plugins, storage quota, privacy setting, backup inclusion and expiration or decommission date. Remove dormant sites and accounts rather than leaving them as permanent attack surfaces.
Review Multisite rewrite rules before deployment
Multisite needs more complex rewrite support than a single site. Do not paste a generic single-site hardening snippet into Apache or Nginx configuration without testing it against your network mode.
The official Multisite guidance specifically warns that a common rule blocking wp-includes/*.php can stop ms-files.php from generating images. Omitting that line preserves the media behavior but provides less blocking, so the decision is a documented trade-off rather than a universally safe setting.
- Copy the production rewrite configuration into staging.
- Test a fresh upload, an older media URL, image resizing, protected files, login, REST and AJAX requests on several subsites.
- Check both a subdirectory site and a domain or subdomain site if the network supports more than one addressing pattern.
- Review web-server error logs and HTTP status codes for unexpected 403, 404 or redirect responses.
- Deploy only after recording the chosen rule, its reason, test date and rollback command.
When changing rewrites, also verify that sensitive files such as configuration backups, logs and environment files are not directly downloadable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Back up the whole network and rehearse restoration
A usable Multisite backup includes the database and files. The database holds the shared user table, network settings and each site’s content tables; files hold core code, plugins, themes, uploads and configuration. Back up both on a schedule that matches how much data the network can afford to lose.
Minimum backup design
- Keep copies separate from the production server so a server compromise or ransomware event cannot erase every copy.
- Encrypt backups in transit and at rest, restrict who can retrieve them and log access.
- Use retention that covers daily operations, monthly history and the period in which a compromise might remain undiscovered.
- Capture a full network backup before core, database or network-activated extension changes.
- Include DNS, certificate, web-server, cron, rewrite and environment configuration in the recovery documentation, without placing secrets in unsecured notes.
Test restoration, not just backup completion
- Restore the database and files into an isolated staging network.
- Verify the network URL, table prefixes, user login, Super Admin role, every representative subsite, uploads, scheduled tasks and domain mappings.
- Measure how long restoration takes and record any manual steps.
- Correct the backup job when a required file, table or credential is missing; a green backup status is not proof of recoverability.
WordPress describes backups and a recovery plan as preparation that reduces downtime after a compromise. Keep the restore procedure accessible when production is unavailable.
Log, monitor and prepare an incident response
Collect logs centrally where possible and protect them from alteration. At minimum, record authentication successes and failures, Super Admin changes, role changes, plugin and theme installation or activation, network-setting changes, new sites, new users, password resets, file-integrity alerts and server access.
Alerts worth acting on
- A new Super Admin or an unexpected role elevation
- Plugin or theme installation outside a maintenance window
- Repeated login failures followed by a successful login from an unusual location
- Changes to registration, upload limits, allowed file types or domain mappings
- Unexpected PHP files, modified core files or execution attempts in uploads
- Backup failures, deletion of backup copies or a sudden storage spike
First-response procedure
- Declare an incident owner and preserve relevant logs before making broad changes.
- Disable or suspend suspected accounts and revoke their sessions; do not delete evidence.
- Isolate affected sites or the entire network when shared code or credentials may be involved.
- Rotate WordPress, SFTP, database, API and hosting credentials from a clean device.
- Identify the initial access, remove malicious code and compare core, plugin and theme files with trusted copies.
- Restore clean database and file backups when integrity cannot be established, then patch the entry point before reopening traffic.
- Review every subsite, user and network setting, notify affected stakeholders and document corrective actions.
Monitoring cannot prevent every compromise, but it shortens the time between a dangerous change and a controlled response.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Managed versus self-managed hosting: what to compare
Hosting responsibility changes who performs routine controls; it does not remove the need to verify them. Ask prospective providers for written answers specific to Multisite.
| Capability | Questions for a managed service | Questions for self-managed operations |
|---|---|---|
| Patching | Who patches WordPress, PHP, the operating system, web server and database, and how are emergency fixes handled? | Who owns advisories, staging tests, maintenance windows and rollback? |
| Isolation | How are networks, databases, backups and management panels isolated from other customers? | Are separate service accounts, firewalls and management networks enforced? |
| Backups | What is retained, encrypted and tested, and can a complete network be restored? | Where are off-server copies stored and who performs restore drills? |
| Logging and alerts | Are authentication, file, plugin, role and network-setting events available to you? | Where are logs stored, how long are they retained and who receives alerts? |
| WAF and response | Does protection understand domain-mapped subsites, and what is the support response during an incident? | Who tunes false positives, handles blocking rules and leads response? |
| DNS, TLS and rewrites | Can the service support your addressing mode, certificates, wildcard records and Multisite rewrite requirements? | Are these configurations documented, tested and reviewed after every change? |
Routine review schedule
- Every day: review authentication, integrity, backup and high-severity alerts.
- Every week: review new users, Super Admins, site registrations, plugin and theme changes, storage growth and failed updates.
- Every month: patch supported components, remove unused code and accounts, test a representative restore and inspect DNS and certificate status.
- After every architectural change: test rewrites, HTTPS, uploads, login, REST, AJAX, backups and domain mappings in staging before production deployment.
- At least annually: rehearse the incident plan, rotate recovery credentials, review hosting responsibilities and verify that the documented network architecture still matches reality.
WordPress’s own guidance summarizes the mindset well: “Fundamentally, security is not about perfectly secure systems.” The objective is to reduce the chance and impact of compromise, detect abnormal changes quickly and recover without guessing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
