Account Lockout, Password Rotation & Concurrent Sessions

Two per-tenant policies that harden local (non-SSO) password logins. Both are off by default — you opt in from Settings → Security. SSO accounts are never affected; the break-glass recovery account (§5.1.1) is exempt from both so emergency access always works.

A third, separate control — prevent concurrent sessions — limits each user to one active session and applies to password and SSO sign-ins.

Account lockout (LMS-471)

After too many consecutive failed password attempts, an account is locked for a cooldown window. Admins can also unlock manually.

1. Open Settings → Security, then the Passwords & lockout tab.
2. Set Failed attempts before lock and Lock duration (minutes).
3. Click Save.

• A locked user sees: “This account is temporarily locked after too many failed attempts.”
• The counter resets to 0 on any successful login.
• Lock and unlock events are written to the audit log (locked / unlocked).

Unlocking an account manually

The Locked Accounts panel on the same page lists every currently-locked account. Click Unlock to clear the lock and counter immediately.

Password rotation (LMS-470)

Force local users to change their password every N days.

1. On the same page, set Password rotation (days).
2. Click Save.

• When a user with an expired password logs in (with the correct password), login is refused with: “Your password has expired and must be reset.” They reset it via Forgot password, which records a new change date.
• Accounts that never recorded a change date are treated as expired once rotation is on, so legacy users are forced through one reset.

Network-level login throttling (LMS-557)

Independently of the two policies above, the platform throttles password sign-in attempts to 30 per minute per IP address. This blunts automated password spraying across many accounts from one source. It is:

• Always on — not configurable per tenant.
• Per network, not per user — a large office behind one shared IP that exceeds the limit sees “Too many sign-in attempts from your network. Please wait a minute and try again.” and can retry within a minute.
• Complementary to account lockout — lockout protects a single account; the IP throttle stops one source from attacking many accounts.

SSO sign-ins are not affected (they authenticate at your IdP).

Prevent concurrent sessions (LMS-875)

Allow each user one active session at a time. When the setting is on, a successful sign-in ends every other session that user has in your organization — the newest sign-in wins. Use it to stop shared seats (one account passed around a team) or when your compliance policy forbids simultaneous logins. It is off by default.

1. Open Settings → Security, then the Access tab.
2. Under Prevent concurrent sessions, switch on One active session per user. The change saves immediately and is written to the audit log.

Who can change it. Owners, and any custom role granted Settings → Security → manage. Admins without that scope see the page only if granted view, with the switch disabled.

What users see

• The browser that was signed out shows the sign-in page with the message “You were signed out because your account signed in on another device or browser.” on its very next page load or action — it is not left working until the session would have expired.
• The browser that signed in last carries on normally.

What it covers

Good to know

• Existing sessions are not cut off when you turn it on. Sessions already open stay open until the user signs in again somewhere; from then on the newest sign-in wins. Turning the setting off lets every session continue.
• Signing out in one browser does not affect the others.
• Audit trail. Each sign-in that ends an older session writes a session.revoked_concurrent entry (user id, sign-in method, IP address, user agent — never the user’s name or email). Changing the setting writes an updated entry on prevent_concurrent_sessions with the before and after value.
• Service interruptions. While this setting is on, every request is checked against the platform’s session service. If that service is briefly unreachable, pages send users to the sign-in page and sign-in answers “Sign-in is temporarily unavailable” instead of letting unchecked sessions through. Everything resumes on its own when the service recovers — an open session is not lost. This applies to every account, including the break-glass account; Embay support can still reach your organization and turn the setting off for you. Organizations with the setting off are never affected.

Troubleshooting