# Membership site security: members, instructors and shared logins

Membership and LMS site security for WordPress: keep sign-up quiet, require two-factor of staff, cap sessions, and keep members out of the dashboard.

By M Asif Rahman, Oct 28, 2026. Updated Nov 8, 2026.

Membership site security comes down to two groups of accounts: a large crowd of members who only sign in to read, learn or take part, and a handful of staff and instructors who can change courses, members and settings. **BetterShield** looks after both with WordPress’s own accounts, roles and sign-in, and it has no settings for any particular membership or course plugin. This guide shows what to set for each group, where shared logins fit, and how to check it worked.

Two earlier guides cover the pieces in depth. [WordPress force logout all users: what each option ends](/blog/wordpress-force-logout-all-users/) explains how sessions end, and [Enforce 2FA in WordPress: pilot, recovery and rollout](/blog/enforce-two-factor-wordpress/) walks through requiring a second step. This post puts them together for a membership or LMS site.

## Quick summary

- A membership site has two sign-in problems: open sign-up and sign-in forms that scripts can reach, and a few staff accounts that hold the keys.
- The sign-in pause, the hidden bot check and **Slow repeated sign-ups** are already on. They pause a connection, never an account.
- **Require two-factor of a role** is for staff. Members are not stopped by it, because it is asked in the dashboard after the password.
- **Sessions per account** and **Sign out after idle (minutes)** are off by default. Both reach every role, so choose them for your members.
- BetterShield records role changes and has no firewall or malware scanner, so it is one part of a site’s security.

## Why a membership site has two sign-in problems

A membership or course site asks people to make an account. The same forms are open to scripts that create throwaway accounts or guess passwords, and the real members are mixed in with them. Reused passwords make guessing worse: the [OWASP description of credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing) explains how one leaked password gets tried against site after site.

The staff are the second problem. Most accounts belong to members, but a few can change courses, members and settings, and unless you add a second step, a password is all that stands in front of them. A role given to the wrong account is easy to miss among many sign-ups, and [WordPress user roles security: least privilege without guesswork](/blog/wordpress-user-roles-security/) covers how to keep that list short.

So the work splits in two. For members, keep the forms quiet and give them a few safe options of their own. For staff, ask for more.

## Members: keep sign-up and sign-in quiet

Three protections cover the forms members use, and all three are on from activation. You are checking them, not building anything.

1. Open **BetterShield › Protection › Login & Access**.
2. Under **Sign-in protection**, check that **Sign-in attempt limits** and **Block simple bots on forms** are on.
3. Check that **Slow repeated sign-ups** is on in the form limits.

| Protection | What it does on a membership site | Default |
|---|---|---|
| **Sign-in attempt limits** | After 5 failed sign-ins in 15 minutes from one connection, sign-in from that connection pauses for 15 minutes, longer if it comes back within a day. The account itself is not locked. | On |
| **Block simple bots on forms** | An invisible field and a clock on the WordPress sign-in and registration forms. A submission that fills the hidden field or arrives within two seconds of the form is refused. People see nothing and solve nothing. | On |
| **Slow repeated sign-ups** | Refuses a connection’s sign-ups once 8 arrive within 60 minutes, the eighth included. | On |

Three details matter on a site with many members. The pause belongs to a connection, not a person, so a member who forgets a password can still sign in from another network. Automatic lockout notices are limited to networks the account used within the last 30 days, or a correct password being used. On a new connection, the sign-in screen offers **Email Me an Unlock Link** for eligible lockouts. You can also press **Release Now** under **Lockouts**. And the hidden bot check is added to the WordPress and store account forms, not to a sign-in or sign-up form that another plugin draws, so a form without it is never refused for that. The login limit reaches further, because it counts wrong passwords wherever WordPress itself checks one. The docs for [Pause sign-in after repeated wrong passwords](/docs/sign-in-lockouts/) and the [hidden bot check](/docs/bot-check/) list every option.

### Opening enrollment for a class

A new course or cohort brings a rush of sign-ups. If a whole class signs up together from one school or company, they share a connection, and one person’s typos or a burst of sign-ups can pause everyone there. We recommend adding that network’s fixed address to **Always allowed**, which the form limits never hold. If you cannot, raise **Failures allowed** to about 10.

## Staff: put a second step in front of the dashboard

Staff are where a requirement belongs. Under **BetterShield › Protection › Two-Factor**, **Require two-factor of a role** asks every account in the roles you tick to set up an authenticator app.

1. Set up two-factor for your own account first, because the requirement covers you too.
2. Tick the roles under **Require two-factor of a role**. We recommend Administrator, Editor and any staff role that edits content, and leaving the member roles unticked.
3. Leave **Grace period, in days** at its default of 14, or set what suits your team.
4. Press **Save requirement**.

During the grace period, staff work as normal and see a notice with **Set it up now**. After it, every dashboard page sends them to the setup screen until they finish. The password still signs people in, and a passkey does not satisfy this requirement, only the app codes do. Before it saves, BetterShield checks your way back in, a working recovery link or an unused printed code, so the requirement cannot be the thing that locks you out. See [Require two-factor of a role, with a grace period](/docs/require-two-factor/).

Members are a different case. Because the requirement is asked in the dashboard, a member who never opens it is not stopped by it, so it is not a way to make two-factor mandatory for everyone. Members can still set it up themselves, and add a passkey, on their own **Profile** screen.

## Shared logins and sessions

Many members signing in from several devices is normal. One membership signed in on far more devices than one person uses is a different matter, and the **Sessions** card on **Login & Access** has two tools for it. Both are off by default.

| Option | What it does | Default |
|---|---|---|
| **Sessions per account** | When an account signs in past the limit, its oldest session ends. 1 to 100, or 0 for no cap. | 0 (no cap) |
| **Sign out after idle (minutes)** | Ends a session that has gone this long without activity. 5 to 1440, or 0 for none. | 0 (no timeout) |

We recommend a **Sessions per account** of 2 or 3 on a membership site. That leaves room for a phone and a laptop, and it makes sharing one login less convenient, though it is a limit on devices, not a way to tell who is using an account. A limit of 1 signs people out of their phone every time they use their laptop, so leave it at 0 unless you have a reason.

Be careful with the idle timeout. There is one timeout for everybody, members included, and it cannot be set per role. Activity means opening a page or saving something, and watching a lesson video makes no requests, so set it longer than your longest lesson, or leave it at 0. [Sign people out and limit sessions](/docs/sessions/) lists what counts as activity.

### When a member sees a sign-in they do not know

On their own **Profile** screen, a member sees **Where you are signed in**. **This was not me** ends one session, and **Sign out everywhere except this device** ends the rest. From your side, **Who is signed in** lists every account with a live session, and **Sign out all their sessions** ends one account’s sessions on every device. It leaves the account and its password alone.

## Keep members out of the dashboard

Members have no work in wp-admin. **Dashboard lock for customers and subscribers**, under **Signing in** on **Login & Access**, sends the roles you choose from any dashboard screen to the front page, while they keep their own profile, where their password, two-factor and signed-in devices are. It starts off, and it never applies to an account that can manage the site or has work in the dashboard.

1. Under **Which accounts to keep out**, tick your members’ role if it is listed. Only roles with no work in the dashboard are offered.
2. Press **Preview the change**. Its first line says how many accounts it reaches, and nothing changes.
3. Run **Monitor first** for 24 hours to see whether members reach the dashboard for anything, then turn the switch on.

A course plugin may send members to a dashboard screen for something real, which is why we recommend watching first. [Keep subscribers and customers out of wp-admin in WordPress](/blog/keep-users-out-of-wp-admin/) covers the fix, and the [low-privilege accounts doc](/docs/low-privilege-dashboard/) has the details.

## Watch who is given which role

New accounts arrive all the time, and nearly all of them are members. One quietly given a staff role, or a change to who can register and which role new sign-ups receive, can sit for weeks. The activity log records accounts created, role changes, changes to what a role may do, and changes to open registration and the default role, with who and when. Giving someone a role that can manage settings or users, or changing open registration or the default role, emails you straight away. See [WordPress activity log: what it records and what to look for](/blog/wordpress-activity-log/).

The audit also raises a High finding, “Anyone can sign up and get more than Subscriber access”, when new accounts get a role that can write. Open registration into a reading role such as Subscriber is not flagged. The [WordPress roles and capabilities documentation](https://wordpress.org/documentation/article/roles-and-capabilities/) explains what each default role can do.

## What it can break, and how to undo

- **A shared connection.** Members on one school or office network can pause each other. Add the fixed address to **Always allowed**, or press **Release Now**.
- **Members signed out mid-lesson.** The idle timeout reaches every role. Raise it or set it back to 0.
- **Devices pushing each other out.** With a low **Sessions per account**, each new sign-in ends the oldest session.
- **A member sent home.** If a course screen lives in the dashboard, the member is sent to the front page. Turn the fix off and everyone reaches the dashboard as before.
- **Staff who ignore the setup.** After the grace period they are sent to setup until they finish. Untick the role to stop asking.

Each one is undone from the same screen: turn the switch off, or set the number back to 0, and press **Save**. With **Ask for my password before removing a protection** on, that asks for your password. Ended sessions stay ended, and people sign in again with their usual password.

## Check it is working

- **The form.** View the source of your sign-in page and look for “Leave this field empty”.
- **A test pause.** From a phone on mobile data, sign in to a test member with a wrong password five times. Watch the row appear under **Lockouts**, then press **Release Now**.
- **Sessions.** Sign in to a test account on three devices with a cap of 2 and see the oldest end. **Who is signed in** lists what is live.
- **The log.** The activity log records “Sign-in lockout started”, “Sessions signed out” and “Two-factor requirement changed”.
- **A staff account.** Under **Users**, the **Two-factor sign-in** section says whether an account uses two-factor.

## Recommended settings

We recommend leaving the three sign-in protections on at their defaults, requiring two-factor of your staff roles, and trying the member-side options one at a time.

| Account | What we recommend |
|---|---|
| Members | Defaults for the pause, bot check and sign-up limit. **Dashboard lock for customers and subscribers** after 24 hours of **Monitor first**. |
| Staff and instructors | **Require two-factor of a role**, with the 14-day default. |
| Shared logins | **Sessions per account** of 2 or 3. Keep the idle timeout at 0, or longer than your longest lesson. |
| Your own account | Two-factor and a passkey, set up before you require anything of anyone else. |

## Frequently asked questions

### Can I require two-factor for every member?

Not through **Require two-factor of a role**. It is asked in the dashboard after the password, so a member who never opens the dashboard is not stopped by it. Use it for staff, and let members set up two-factor on their own **Profile** screen.

### Does the hidden bot check cover my membership plugin’s own forms?

It is added to the WordPress sign-in and registration forms, the comment form and a store’s account forms. A sign-in or sign-up form that another plugin draws may not carry it, and a form without it is never refused for that.

### What happens when a member gets their password wrong too many times?

By default, 5 failed sign-ins in 15 minutes from one connection pause sign-in from that connection for 15 minutes, longer if it happens again within a day. The account is not locked, and an automatic lockout notice is sent only for a network the account used within the last 30 days, or when its correct password was used. Otherwise, use **Email Me an Unlock Link** on the sign-in screen for an eligible lockout.

### Can BetterShield stop members sharing one login?

It can limit how many sessions one account holds at a time with **Sessions per account**, and it can end an account’s sessions. It cannot tell who is using an account, so treat the cap as a limit on devices.

### Can members sign in with a passkey?

Yes. Anyone signed in can add a passkey on their own **Profile** screen, up to 10 per account, and passkeys need HTTPS. A passkey is an extra way in: the password keeps working unless the member’s role is ticked under **Sign in with a passkey only**.

## Conclusion

A membership site’s security is mostly its accounts: members whose forms should stay quiet, and a few staff who should have a second step. Leave the sign-in protections on, require two-factor of your staff roles, and add the session cap and the dashboard redirect once you have watched how members use the site.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/). The docs cover each part: [Require two-factor of a role](/docs/require-two-factor/), [Sign people out and limit sessions](/docs/sessions/) and [Keep subscribers and customers out of the dashboard](/docs/low-privilege-dashboard/). The [membership and LMS use case](/use-cases/membership-lms/) shows the whole picture.