Emergency Lockdown: Enable, Use, and Recover Yourself

What Emergency Lockdown Does

Emergency Lockdown hooks the WordPress authenticate filter at priority 100 — after WordPress core’s username/password handler (priority 20) and core’s cookie authentication (priority 30). Because GuardPress runs late in the filter chain, its denial is the final value wp_authenticate() returns and cannot be silently overwritten by another plugin. The result:

• Every new sign-in is rejected, regardless of credential correctness, regardless of surface. This includes wp-login.php, WooCommerce /my-account/, MemberPress, BuddyPress, theme login forms, REST API basic auth, Application Passwords, XML-RPC, and any custom AJAX login handler.
• Existing sessions are not touched. Anyone currently logged in stays logged in and can continue working until their session naturally expires. This is intentional — it means the admin who flipped the switch doesn’t accidentally lock themselves out the moment they enable it.
• An admin notice appears on every wp-admin screen for users with manage_options, reading: “GuardPress Emergency Lockdown is ACTIVE. All new logins are being rejected site-wide. Existing sessions are unaffected. Disable in settings.” This is non-dismissible so it can’t accidentally get left on.
• Two CRITICAL severity entries are written to the audit log — one on enable (action: emergency_lockdown_enabled), one on disable (action: emergency_lockdown_disabled). The timeline is forensically reconstructable from the audit log post-incident.

Users attempting to sign in see this error inside their login form:

Site temporarily locked down. Sign-ins are disabled
by an administrator. Please try again later.

The internal WP_Error code is gp_emergency_lockdown — useful if you’re writing custom error handlers that need to distinguish lockdown rejections from credential failures.

When to Use It

Emergency Lockdown is a deliberately heavy hammer. Reach for it when you need to freeze the front door right now and brute-force lockout / IP blocking aren’t enough on their own.

Good reasons to enable it

• Active credential-stuffing or brute-force attack that’s overwhelming brute-force lockout — attackers rotating through many IPs faster than your block thresholds can keep up
• You suspect an admin password is in a breach corpus and you need to freeze sign-ins while you rotate every admin credential and force-logout all sessions
• You’re actively investigating a suspected compromise and want to prevent new sessions from being created while you triage the file integrity scan, audit log, and database
• Pre-announced maintenance window where you need guaranteed quiet on the auth surface (e.g. rotating session salts in wp-config.php, migrating to a new auth plugin)

Bad reasons (use a lighter tool instead)

• Routine maintenance — just use WP’s built-in maintenance mode or a coming-soon plugin. Lockdown blocks sign-ins; it doesn’t put up a maintenance page for visitors.
• One specific user attacking you — use IP blocking under GuardPress → IP Management instead. No need to lock out every other legitimate user.
• You forgot to set up 2FA — turn on 2FA. Don’t lock out the entire site as a substitute.

How to Enable Emergency Lockdown

How to Disable Emergency Lockdown (Normal Case)

The normal way out is the same as the way in — flip the toggle off:

That’s it. The whole disable flow takes about 30 seconds if you have a working admin session. The next section is for when you don’t.

Locked Yourself Out? Use the wp-config Bypass

If Lockdown is ON and you don’t have a working admin session anymore (yours expired before you disabled it, the browser cleared cookies, you tried from a different device), you need to bypass the lockdown check from outside WordPress. GuardPress ships a wp-config constant for this exact scenario.

define( 'GUARDPRESS_EMERGENCY_BYPASS', true );

Multi-Admin Considerations

If your site has more than one administrator:

• Co-admins with active sessions can continue working uninterrupted. They’ll see the same red admin notice everywhere, so they know the site is in lockdown mode.
• Co-admins whose sessions have expired will get the lockdown error when they try to sign in. They’ll need to either wait for you to disable Lockdown, or you give them the bypass procedure above.
• Newly-created admin accounts can’t sign in until Lockdown is disabled. Don’t create new admin accounts during a lockdown unless you also have a plan to let them in.
• The bypass constant works for everyone — it’s not user-scoped. If you add it to bypass yourself, every other admin can also sign in while the constant is set. Disable Lockdown and remove the constant promptly so co-admins don’t accidentally use the bypass window for routine sign-ins.

Common Mistakes

Leaving Lockdown on after the incident

The persistent admin notice is loud and non-dismissible specifically to prevent this. But if you only ever check wp-admin from a long-lived session, the notice can blend into the chrome. Set a calendar reminder: “Emergency Lockdown enabled at HH:MM — disable by HH:MM+X.” The audit log’s CRITICAL severity entry on enable makes it easy to find the original timestamp later.

Adding the bypass to wp-config and never removing it

The bypass constant is harmless when Lockdown is off, but it means Lockdown is effectively neutered for your site — if a real attack happens later and someone enables Lockdown, the leftover constant will let attackers right through. Always remove the bypass after recovering.

Using Lockdown when IP blocking would suffice

If one IP (or a small set of IPs) is the source of an attack, IP blocking under GuardPress → IP Management is far less disruptive. Lockdown is for distributed attacks or compromise-investigation scenarios where individual-IP precision isn’t enough.

Forgetting to tell co-admins before enabling

The biggest source of “wait, why can’t I sign in?” messages. Send a heads-up to anyone who might need access during the lockdown window.

Still Stuck? Email Priority Support

If the bypass constant isn’t letting you sign in even after editing wp-config.php — or you need help triaging an active incident that prompted the lockdown in the first place:

Email support@royalplugins.com with the diagnostic info below. Priority email support is included with your GuardPress Pro license — typical response time is within 24 hours, and we treat active-incident lockdown recovery as highest priority.