Vigilant - 100% Free Security Suite: Firewall, 2FA, Login, Headers, Scanner…

No. Vigilant is optimized for performance. The firewall uses efficient pattern matching, database queries are cached with transients, and .htaccess rules execute at server level before PHP even loads.

Vigilant applies its default settings: all modules on, with balanced values for most sites. On Apache and LiteSpeed that writes two blocks to .htaccess, and it writes one block of constants to wp-config.php. If wp-config.php already defines DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS, FORCE_SSL_ADMIN, FORCE_SSL_LOGIN, DISABLE_WP_CRON, WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY or SCRIPT_DEBUG, Vigilant comments that line out, marks it and sets the value from its own settings in WP Hardening. If you rely on one of them, check that tab after activating. Your lines come back when you deactivate. Vigilant keeps no copy of those two files. If you want one, make it before activating.

Vigilant removes its Protection and Security Headers blocks from .htaccess, removes its constants from wp-config.php, brings back the lines it had commented out there and clears its scheduled tasks. Two things to know:

• Switch Under Attack mode off first. Its .htaccess block is removed when the mode ends, not on deactivation.
• If you delete the plugin folder by FTP instead of deactivating, nothing is reverted: remove the blocks between the Vigilante markers by hand.

Vigilant supports two 2FA methods. With the authenticator app (TOTP), you scan a QR code in your profile to link an app like Google Authenticator or Authy, then enter a 6-digit code from the app on every login. With email codes, you receive a one-time code via email after entering your password. If enabled by the site administrator, you can mark your device as trusted to skip 2FA for 30 days.

When you set up TOTP, Vigilant generates 10 backup codes. You can use any of them as a one-time replacement for the authenticator code. If you run out of backup codes, an administrator can reset your TOTP from the plugin settings.

Check your spam folder first. You can click "Resend code" on the verification form. Codes expire after 10 minutes by default. If issues persist, an administrator can temporarily disable 2FA from the plugin settings.

Yes. Go to Login Security > Two-Factor Authentication and change the verification method. If notifications are enabled, affected users will receive an email explaining the new method and how to set it up.

By default, 2FA is enforced for administrators and editors. You can customize which roles require 2FA in the Login Security settings, and exclude specific users individually.

Access your site via FTP/SFTP and either rename the plugin folder to disable it temporarily, or delete the vigilante_login_attempts table rows for your IP address in the database.

The firewall is configured to allow normal WordPress operations, including the block editor, REST API, and popular page builders. If you experience issues, you can whitelist specific IPs or adjust rate limiting thresholds. Block Bad Bots also stops SEO crawlers (Ahrefs, Semrush, Majestic, Screaming Frog) and command line clients (curl, wget, python-requests). To let one of them through, add its name to User-Agents not treated as bots, in the same tab.

Requests are blocked in two places:

• Rules in .htaccess (bad bots, bad query strings, unusual HTTP methods, protected files) answer 403 before WordPress loads, so nothing is logged.
• The PHP firewall logs what it blocks. "Bad bot blocked" shows the entry of the list that matched; the full User-Agent is in its own column.

While Vigilant works standalone, running multiple security plugins can cause conflicts. We recommend testing in a staging environment first if you need to combine security solutions.

Yes. Vigilant is compatible with popular caching plugins. The firewall runs before cache layers, and .htaccess rules don't interfere with caching mechanisms.

Yes. Vigilant includes compatibility settings for WooCommerce. The REST API security module automatically allows WooCommerce endpoints, and the firewall won't block payment gateway connections.

Use the built-in header testing tool in the Security Headers tab, or visit securityheaders.com with your site URL to get a security grade.

Security Check is an on-demand audit built into the Dashboard. It runs more than 50 checks across 6 categories (SSL/TLS, HTTP headers, WordPress exposure, access and authentication, sensitive files, and internal checks) and returns a 0–100 score with an A–E grade. Unlike external online scanners, it runs entirely on your server and has access to 17 exclusive internal checks: PHP end-of-life status, PHP security fixes, pending updates, closed/removed plugins, Vigilant self-protection, file permissions, default salts detection, administrators without 2FA enrolled, and more.

No. All checks run on your server. The only external traffic is three DNS lookups against public blacklists (Spamhaus, Barracuda, SpamCop) for the reputation category: standard DNS queries with no authentication, no API keys, and nothing sent beyond your site's IP address.

It adds the points of every check that passes, out of the checks it could run.

• Some checks test the live site: HTTPS, the headers the browser receives, files that should not be reachable.
• Others read a Vigilant setting, such as the custom login URL, the login attempt limit or two-factor. They count while the module that applies the setting is switched on, and tell you whether it is on, not whether a CDN or your host changes the result.
• A check that could not be run, because the site did not answer in time for example, is left out of the score and counted as not measured.

Run it manually after any significant change (plugin update, server migration, new user role configuration). For ongoing monitoring, enable the weekly automatic scan from the widget. You'll only receive an email if the score drops by 10 points or more, or if a new critical check starts failing — so no spam from routine scans.

You can require users to change their passwords after a set number of days (30, 60, 90, etc.). Users are warned before it expires. Once it does, they are taken to their profile to set a new one before they can do anything else. Password history prevents reusing recent passwords.

When enabled, new user registrations require manual approval by an administrator before the account becomes active. Pending users cannot log in until approved. You can configure auto-rejection after a set number of days.

New users must verify their email address by clicking a link before their account becomes active. This prevents fake registrations and ensures valid contact information.

You can limit how many concurrent sessions each user can have. When the limit is reached, either the new login is blocked or the oldest session is terminated, depending on your configuration.

Yes. The security audit log can be exported to CSV format for external analysis or compliance reporting. You can also filter logs by event type, user, or date range before exporting.

Every event is logged as Info, Warning or Critical. By email you get:

• Security Audit alerts: Critical events by default, such as a closed plugin. Choose "Warning and Critical" to get more.
• Admin monitoring, in Users: a new administrator, a change of role to administrator and changes to an administrator's email or password. Each has its own checkbox.
• File Integrity: the findings of each scan, according to the level you chose.
• Self-protection: always, when Vigilant's own files change.

It checks:

• WordPress core, against the checksums WordPress.org publishes, plus any file added to wp-admin or wp-includes.
• Plugins from WordPress.org, against their checksums.
• Themes from WordPress.org, against the package WordPress.org publishes for the installed version. It is downloaded once per version.
• In both, files that changed, files that are missing and PHP files that are not in the published copy.
• Plugins and themes from anywhere else, must-use plugins and drop-ins (advanced-cache.php, object-cache.php and the like). There is no official copy of them, so they are searched for obfuscated code.
• The uploads directory, for PHP and other scripts, double extensions, .htaccess files and PHP configuration files.
• The other folders of wp-content (languages, upgrade and the like), for hidden code in their PHP files, unless they are in Excluded Paths. A translation file has to hold text and nothing else.
• The site root, wp-content and the plugins folder, for loose files that do not belong there, backups left within reach and a .user.ini or php.ini that loads another file.
• wp-config.php and .htaccess, for any change since you last approved them.

• Modified: the file does not match the copy on WordPress.org. Usually an update that did not finish or a manual edit. Reinstalling the plugin, theme or WordPress fixes it.
• Suspicious: code where none is expected (PHP in uploads or in the site root) or obfuscated code. Real infections land here, and so do the cache or template files some plugins generate.
• Extra: a file that WordPress, the plugin or the theme does not ship. Often legitimate. A copy of wp-config.php or a database dump in the site root should be moved out.
• Critical config: wp-config.php or .htaccess changed since you last approved them.
• Closed or removed: WordPress.org closed the plugin. Replace it.

Usually not. Cache, security and redirection plugins rewrite their own blocks in those files, often on every update, and Vigilant reports every change it did not make itself. Open File Integrity, press Review changes and read the lines. If they belong to a plugin you use, press Approve: that records the current content as the reference and does not touch the file. Lines you cannot explain need a closer look, above all the ones that load a file (auto_prepend_file, include) or send requests to a PHP file. You get that email once per change, not after every scan. The change stays listed in File Integrity until you approve it.

• Ignore hides one file.
• For a folder where a plugin keeps generating PHP (compiled templates, caches), add the folder to Excluded Paths, for example wp-content/uploads/cache.
• If the scan says it ran out of time in a folder of wp-content, such as a very large cache, add that folder to Excluded Paths too.
• A .htaccess inside uploads that only denies access protects that folder, and is not reported. WooCommerce writes several.

On Apache and LiteSpeed, two blocks in .htaccess, between the lines # BEGIN Vigilante Protection and # END Vigilante Protection, and # BEGIN Vigilante Security Headers and # END Vigilante Security Headers. While Under Attack mode is on there is a third one, # BEGIN Vigilante Under Attack. In wp-config.php, one block between /* BEGIN Vigilante Security Constants */ and /* END Vigilante Security Constants */, and the prefix // [VIGILANTE_ORIGINAL] on any line of yours that defined one of the same constants. Vigilant writes these blocks when you save its settings and after it updates, not in between. If another plugin or a person removes one, save that tab again to write it back.

Previous versions kept a copy of wp-config.php in an option, with the database password and the eight authentication keys and salts. Updating removes the copy, but cannot undo an exposure that already happened. If your database, or a backup of it, may have been read by somebody else while that copy was stored:

• Replace the eight keys and salts in wp-config.php with fresh ones from the WordPress.org secret-key service. Everybody is signed out, you included, which is the point. If File Integrity watches a wp-content/secrets.php, approve it once more afterwards.
• Have a backup code at hand first if you use an authenticator app with Vigilant: new keys stop the app codes from working. A backup code still lets you in, and you can set the app up again from your profile.
• Do not replace WP_SECRETS_KEY with them, if your wp-config.php has it: it is not one of the eight, and a new one makes every secret kept with the WordPress Secrets API unreadable.
• Change the database password if your host lets you.

Not on a very large one. A scan runs for 60 seconds at most and starts from the beginning each time. With many plugins, a large uploads folder or a large cache, it may not reach every plugin and theme, and it is the same part that is left out on every scan.

• File Integrity says when the last scan was partial, and names the plugins, the themes and the areas it did not reach. The scan email says it too.
• Security Check does not count a partial scan as a clean one.
• If the server stops the scan before it ends, or WordPress does not run its scheduled tasks, nothing is stored. File Integrity and Security Check then say that no scan has finished since the date shown.
• To check what was left out, File Integrity lists the folders the scan did check: add them to Excluded Paths, run a scan by hand, and take them out again.
• While the whole folder of a plugin or of a theme, or the uploads folder, is in Excluded Paths, File Integrity and Security Check keep saying so: no scan looks inside it.
• Adding large folders that do not need checking to Excluded Paths leaves more time for the rest.

You can configure automatic scans to run daily or weekly. You can also run manual scans at any time. Email notifications support three levels: every finding, serious findings only (suspicious and extra files, changes in wp-config.php or .htaccess and closed plugins), or disabled. The email goes out when a scan finds something new, so a finding you were already told about is not repeated.

Vigilant verifies its own files against the checksums WordPress.org publishes for your version, the MANIFEST.sha256 file shipped with the plugin and a fingerprint of that manifest stored in your database. The result appears in File Integrity, with the results of the last scan, and in Security Check. To check from outside WordPress, run wp plugin verify-checksums vigilante, or php bin/verify-manifest.php inside the plugin folder, which also reports added files and accepts line endings rewritten by the host. SECURITY.md lists every option.

A list of the SHA-256 checksum of every file in the plugin, in the standard format of the sha256sum tool, generated as the last step of each release. It is what lets Vigilant, and you, notice a changed file even when WordPress.org cannot be reached. readme.txt and changelog.txt are not in it, because WordPress.org allows updating them without a new version.

Usually nothing. Vigilant has already scheduled them again, and the notice is not about changed files.

• WordPress itself drops a scheduled task when it cannot save its next run, for example if the database does not answer at that moment.
• A cleanup or optimization plugin can remove scheduled events: exclude the ones whose name starts with vigilante_.
• The notice goes away by itself after a week with no task missing.
• If it turns critical, the same task was missing three times in one week or four in a month: something is removing it. Look for the plugin or the hosting job that does it, and if you find neither, review recently installed plugins and the administrator accounts.

No. It detects that Vigilant's files were changed, deleted or added to, not bugs in its code. Vulnerabilities are fixed in new releases, so keep Vigilant updated, and report any you find as SECURITY.md explains.

Standard applies balanced settings suitable for most sites. Maximum applies stricter rules: lower rate limits, tighter CSP policies, required admin notifications, session limits, and more aggressive hardening. Maximum may require adjustments for sites with complex functionality.

Nowhere on the server. The configuration backup (wp-config.php, .htaccess and robots.txt) is a ZIP built on the fly and sent to your browser, and Vigilant keeps no copy of those files, because they hold your database password and other secrets. A database backup you download is generated as a temporary ZIP with an unguessable name and removed right after the download.

Under Attack mode is an emergency feature you can activate when your site is experiencing an active attack. It adds a JavaScript challenge that real browsers solve automatically in a few seconds, while bots and automated scripts are blocked completely. It also applies aggressive rate limiting, blocks restricted HTTP methods, and restricts API access.

No. Logged-in users, admin pages, cron jobs, AJAX requests, and the login page are all excluded from the JavaScript challenge. Only unauthenticated frontend visitors see the verification page.

It automatically deactivates after 4 hours. You will also receive an email notification when it activates and deactivates.

No. It operates independently from your preset configuration (Standard or Maximum). Your regular settings are untouched and continue working normally after Under Attack mode deactivates.

Go to Vigilant > Tools > Database Backup. Select which tables to include (or leave all selected), then click Download. The backup is generated as a temporary ZIP with an unguessable name, streamed to your browser and deleted from the server immediately after the download.

WordPress uses wp_ as default table prefix. Changing it to a random prefix adds a layer of protection against SQL injection attacks that target default table names. Go to Vigilant > WP Hardening > Database Hardening. Always create a backup before changing the prefix.

Go to Vigilant > Firewall > User-Agent Lists and add the service name (e.g., ManageWP, MainWP, UptimeRobot) to User-Agents not treated as bots. Partial matching is used, so "ManageWP" matches any User-Agent that contains it. This only exempts it from the bad bots rules: any client can send any User-Agent, so every other firewall rule still applies. If you also use a custom login URL, add the management dashboard's IP address to the firewall IP Whitelist as well. Some operations (for example pushing a plugin update from MainWP) reach wp-admin without a WordPress session and with a generic WordPress user agent rather than the service name, so the User-Agent rule alone would not match them. A whitelisted IP is allowed past the hidden login/wp-admin protection (it still has to authenticate).

Yes. Go to Vigilant > Settings & Tools > Notification settings. You can add additional email recipients (one per line) and optionally uncheck the WordPress admin email. This is useful for maintenance professionals managing multiple sites who need to receive all security alerts.

Yes. Use the vigilante_notification_recipients filter. It receives and returns an array of email addresses used for all administrative notifications: add_filter( 'vigilante_notification_recipients', function( $recipients ) { $recipients[] = 'security-team@example.com'; return $recipients; } );