# Ask for your password before anyone removes a WordPress protection

Turn on BetterShield’s password check so removing a protection needs the administrator’s password first. What it covers, what it skips, and how to undo it.

By M Asif Rahman, Nov 5, 2026.

**Ask for my password before removing a protection** is a BetterShield setting that makes WordPress ask the signed-in administrator for their password before an action that lowers protection goes through. It is off by default, it takes one switch, and it means an unattended browser tab cannot quietly undo your hardening.

Our guide to [WordPress hardening](/blog/wordpress-hardening/) explains the fixes you might switch on. This post is about the other half: making sure a fix you switched on stays on unless someone who knows the password chooses to remove it.

## Quick summary

- The switch is **Ask for my password before removing a protection**, under **BetterShield › Settings › General**. It is off by default.
- When it is on, BetterShield asks for the password before it undoes a hardening item, imports settings, changes sign-in behavior, ends sessions, mutes alerts or turns a protection off.
- Adding protection and reading are not asked about.
- One successful confirmation lasts 15 minutes for that sign-in. It ends sooner if the user signs out or resets the password.
- Safe mode stands the check down, and accounts that sign in with a passkey only are not asked for a password.

## Why a password check helps

Most security settings are changed by someone who is signed in and meant to be there. The risk the check addresses is narrower: a signed-in browser that is not being watched. A laptop left open in a shared office, a tab left on a screen share, or a session that someone else is now using can all change a setting without ever typing a password, because the sign-in already happened.

Asking for the password again before a protection is removed puts a short pause at the exact moment it matters. The [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) describes the same idea in general terms, under its guidance on requiring re-authentication for sensitive features. This setting applies that idea to the actions that reduce what your security plugin is doing for you.

Nothing about it is meant to feel alarming. It is a plain confirmation, in the same spirit as a dialog that asks you to be sure before you delete something.

## What the check asks about, and what it leaves alone

The check is aimed at actions that reduce or remove protection. The list is short and specific.

| When this happens | Does BetterShield ask for the password? |
|---|---|
| Undoing a hardening item | Yes |
| Importing settings | Yes |
| Changing sign-in behavior | Yes |
| Ending sessions | Yes |
| Muting alerts | Yes |
| Turning a protection off | Yes |
| Adding protection | No |
| Reading a page, a finding or a report | No |

The last two rows matter. You can look around, review findings and turn more protection on without ever seeing the prompt. It only appears on the way down.

A few examples of how this shows up in practice:

- You open **Protection › Hardening** and turn a fix off. Turning a fix off uses its undo, so this is a protection being removed, and BetterShield asks first. Our [hardening guide](/docs/hardening/) lists the fixes and where each one lives.
- You lower what an alert address receives. Making alerts quieter counts as removing a protection, so the password is asked for first. The [alert recipients](/docs/alert-recipients/) guide describes the choices.
- You move the script-blocking policy back to watching. The [script-blocking policy guide](/docs/content-security-policy/) notes that this asks for the password when the setting is on, and that starting to enforce never does.

## Set it up

You need to be an administrator who can open BetterShield’s settings.

1. Open **BetterShield › Settings › General**.
2. Find the **Plugin data & tools** group.
3. Turn on **Ask for my password before removing a protection**.
4. Save if the screen asks you to.

From then on, the next covered action opens a prompt that reads **Confirm your password**, and it says that once confirmed you are not asked again for fifteen minutes. Enter the password of the account you are signed in with and carry on.

The full walkthrough, with a screenshot of the row, is in the [password confirmation guide](/docs/confirm-before-removing-protection/).

## How long one confirmation lasts

A successful confirmation lasts 15 minutes for that sign-in. During those 15 minutes you can make several covered changes without being asked again, which keeps a maintenance session from turning into a string of prompts.

The window ends sooner in two cases:

- The user signs out.
- The user resets the password.

The confirmation belongs to that sign-in.

## What the password check does not cover

It is useful to be exact about the limits, because a setting like this is easy to over-trust.

- **It does not stop someone who knows the password.** It is a second look at the moment of removal, not a lock that outranks the account holder.
- **It does not ask about reading or adding protection.** That is by design.
- **It is paused in safe mode.** Safe mode stands the check down.
- **It does not ask passkey-only accounts for a password.** An account that signs in with a passkey and has no password to confirm is not asked for one.
- **It leaves the 15-minute window open.** Anything covered that happens inside the window after a confirmation will not ask again.

None of this is a flaw. It is a clear description of what the setting does, so you can decide where else you need a guard. If your concern is who may change the site address, the administrator email or who can register, that is a different fix. **Admin-only key settings** under **Protection › Hardening** limits those changes to administrators, and the [key site settings guide](/docs/guard-site-settings/) explains it. The two work well together, but they answer different questions.

## What it can break, and how to undo

The one thing that can go wrong is simple. An administrator who does not know the account password cannot complete a covered action, and will be stopped at the prompt.

To undo the setting, sign in the normal way for that account, or use the account’s usual recovery path, then turn **Ask for my password before removing a protection** off again. If you have not yet set up a way back in, do that first. Our [recovery guide](/docs/set-up-recovery/) walks through it, and the post on [recovery mode and a recovery link](/blog/wordpress-recovery-mode/) explains which route covers which problem.

If a change goes through that you did not mean, the [settings history](/docs/restore-settings-change/) can put the previous value back.

## Check it is working

You can test this in a few minutes on a site where nothing depends on the result.

1. Turn the switch on.
2. Pick a reversible protection and start to turn it off.
3. The password confirmation should appear before anything changes.
4. Cancel, or confirm and then turn the protection back on.
5. Open the activity log and look for the entries your test produced. The [activity log guide](/docs/activity-log/) covers filters and export, and our post on the [WordPress activity log](/blog/wordpress-activity-log/) explains what is worth reading each week.

If the prompt does not appear, check that the switch is actually on and that the action is one in the list above. Adding protection will never ask.

## Recommended settings

We recommend turning it on for administrator accounts that use passwords, and for any site where a browser might be left signed in on a shared or unattended computer. If every administrator signs in with a passkey only, the check will not ask them for a password, so weigh whether it adds anything for that team.

We also suggest pairing it with a short list of habits: sign out of shared computers, keep a working recovery method, and review the activity log. If you ever need to end every session at once, the [site lockdown](/blog/wordpress-site-lockdown/) post covers that tool, and ending sessions is itself one of the actions this setting asks about.

## Frequently asked questions

### Is the password check on by default?

No. **Ask for my password before removing a protection** is off by default. You turn it on under **BetterShield › Settings › General**, in the **Plugin data & tools** group.

### Does it ask for a password every time I change a setting?

No. It asks only for actions that reduce or remove protection, such as undoing a hardening item, importing settings, changing sign-in behavior, ending sessions, muting alerts or turning a protection off. Adding protection and reading are not asked about, and one confirmation lasts 15 minutes.

### What happens if I forget the password?

You cannot complete a covered action until you can confirm it. Sign in through the account’s normal recovery path, then turn the setting off if you need to. Setting up your recovery method before you need it makes this much calmer.

### Does it work if I sign in with a passkey?

Accounts that sign in with a passkey only are not asked for a password, because there is no password to confirm. If your whole team uses passkeys only, this setting will not add a prompt for them.

### Does safe mode switch the check off?

Safe mode stands the check down while it is on.

### Is this part of the free plugin?

Yes. The setting is part of the free BetterShield plugin on WordPress.org.

## Conclusion

A password check before a protection is removed is a small habit with a clear purpose: it keeps a protection you chose from being undone by an unattended session. It is off by default, it asks only on the way down, and one confirmation covers 15 minutes. We recommend turning it on for password-based administrator accounts and keeping a recovery method in place first.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/). The full setup is in the [password confirmation guide](/docs/confirm-before-removing-protection/).