Solid Security plugin review and common issues

Access recovery options: (1) wait for the lockout period to expire (default: 15-60 minutes depending on configuration); (2) add your IP to the whitelist via FTP — edit wp-config.php and add: define(‘ITSEC_DISABLE_MODULES’, true); — this temporarily disables Solid Security; (3) connect via FTP and rename the Solid Security plugin folder (wp-content/plugins/better-wp-security → better-wp-security-disabled) to deactivate it; (4) if database access is available, clear the lockout from the itsec_lockouts table.

File change detection alerts fire when any monitored file changes. To reduce volume: (1) in Solid Security → File Change → Settings, reduce the scan frequency (daily rather than hourly); (2) exclude known-safe directories from scanning (wp-content/uploads, wp-content/cache) — these change frequently with normal site operations; (3) after a WordPress or plugin update, manually clear the file change detection baseline so the new file state becomes the reference point; (4) configure Solid Security to only alert on changes to core WordPress files rather than all files.

Login URL changes require permalink flushing to take effect. If the new URL is not working: (1) access wp-admin via the old URL — it may still work if caching serves the old version; (2) if completely locked out, use FTP to create a file named “emergency.php” in the site root with the code: <?php require('wp-load.php'); itsec_hide_backend_disable(); — this disables the hide-backend feature; (3) alternatively, deactivate Solid Security via FTP (rename the plugin folder) and flush permalinks by visiting Settings → Permalinks.

In Solid Security → Two-Factor → Settings, configure 2FA requirements by user role. Set Administrator role to require 2FA. Users in the required role see a 2FA setup prompt on their next login. They can choose their 2FA method (authenticator app TOTP, email code, or passkeys if Pro). The grace period setting gives users a configurable number of logins before 2FA becomes mandatory — set to 0 to require immediate 2FA setup. Backup codes are generated for each user to prevent account lockout if they lose their 2FA device.

Solid Security’s vulnerability scanning uses the Patchstack database to identify vulnerable plugins and themes. Go to Solid Security → Site Scan → Auto-Patching Settings. Enable automatic updates for vulnerable plugins: Solid Security can automatically update a plugin when a security update is available that patches the detected vulnerability. Configure notification settings to alert administrators when a vulnerability is detected and when a patch is applied. This automatic patching significantly reduces the window between vulnerability disclosure and site protection.

Both provide excellent WordPress security, with different strengths. Wordfence has a larger community, more extensive documentation, and a very powerful real-time malware scanner. Solid Security’s strengths are its approachable setup wizard, Patchstack vulnerability integration, and the SolidWP ecosystem cohesion (Security + Backups + Central). For teams already using SolidWP products, Solid Security is the natural fit. For those who want maximum security depth, Wordfence’s scanner and firewall are hard to match. Neither is definitively better — the right choice depends on your team’s technical comfort and existing stack.

Solid Security provides vulnerability scanning (checking for known vulnerable plugin/theme versions) and file change detection (alerting when files change unexpectedly). It does not provide a server-level malware scanner that scans file contents for malicious code — that capability is Wordfence’s or Sucuri’s speciality. For malware detection, combine Solid Security’s prevention features with a dedicated malware scanner (MalCare provides excellent cloud-based scanning as a complement).

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.