What it does: One switch that disables user registration, comment submission, XML-RPC and anonymous REST writes while you work out what happened. Thrown by hand it stays on until you turn it off; since 1.2.0 Guard Forge can also throw it itself, and an automatic one lifts itself. How to access: GuardForge > Lockdown (manual), GuardForge > Settings (the auto triggers). Free/PRO: Pro (lockdown). Auto-lockdown, and its defaults:

• Off until switched on (auto_lockdown_enabled, default off).
• Trigger 1, on by default once auto-lockdown is enabled: twenty distinct IP addresses crossing the brute-force lockout threshold inside a ten-minute window. The threshold is a setting (1–1000, default 20); the window is not, deliberately.
• Trigger 2, off by default: a single finding from the malware scanner.
• It lifts itself after auto_lockdown_lift_minutes (default 60, 1–10080) via a one-shot cron event, and a manual lift cancels that event.
• Both ends are written to the audit log (lockdown_auto_enabled / lockdown_auto_lifted) and the owner gets a plain e-mail. The guardforge/lockdown_toggled action fires, which is what the alert channels listen for.
• Never on a staging copy, for the same reason a copy does not enforce a lockout.

Notes:

• Both triggers listen to actions the existing modules already fire (guardforge/ip_locked, guardforge/malware_finding); neither module was edited to add them.
• The ten-minute window is computed in PHP from the site’s own clock, not from the database server’s NOW(). The login log writes event_time with current_time('mysql') — the site’s clock — so on a host whose site runs ahead of its database every row looked like it was from the future and the threshold counted the whole retention window; on a host behind it, the trigger was silently dead.