Session security

Two account-protection controls ship in CyberGuard and are managed from one place: an idle session lock that covers an unattended screen, and an account lockout that blunts password guessing. Both are aimed at the access-control expectations of frameworks such as CMMC and NIST SP 800-171, and both are on by default.

Where to find it

Extra → Settings → General → Security. The block sits inside the collapsible Security section, and only administrators on the global domain can change it.

Idle session lock

Enable session lock on inactivity locks the interface after a configured idle period and requires the person to prove who they are again before continuing. It is on by default.

Idle timeout (minutes) appears underneath once the lock is enabled. It accepts 1 to 480 minutes and defaults to 15. Mouse movement, clicks, key presses, scrolling, the mouse wheel and touch all count as activity and restart the countdown, so the lock only fires on a genuinely unattended screen.

What the user sees

When the timer expires, a full-screen panel covers the application:

• The heading reads Session locked, with the explanation that the session was locked after a period of inactivity, and the signed-in email address underneath.
• A password field with an Unlock button. Entering the current password dismisses the panel and leaves you exactly where you were — nothing in the page is lost, and no navigation happens.
• Log in with SSO when SSO is enabled on the instance. This re-asserts identity through the identity provider and returns with a fresh session, which clears the lock. Accounts that sign in only through SSO have no usable local password, so for them this is the only unlock path and the password field is not shown.
• Sign out, which ends the session and returns to the login page.

The lock covers the browser tab; it is not a substitute for locking the workstation, and it does not end the server-side session. Two failure cases are deliberate:

• If the password is wrong, the panel stays up with an error and you can try again — attempts count towards the account lockout below, and once the account is locked the panel says so and stops accepting attempts.
• If the underlying session has expired while the screen was locked, CyberGuard does not pretend to unlock anything: it sends you to the login page for a full sign-in.

Tip

Fifteen minutes suits shared or open-plan environments. Teams doing long uninterrupted reading in an audit will find it abrupt — raise it rather than switch the lock off, so the control remains in place for a compliance review.

Account lockout

Lock accounts after repeated failed logins temporarily locks an account after 5 consecutive failed login attempts, for 30 minutes. It is on by default. Someone who trips it sees a message on the login page saying the account is temporarily locked because of too many failed attempts, and that they should try again later.

The counter is per account and resets on a successful sign-in, or when a previous lock window has elapsed. The thresholds are fixed in this build — the toggle is the control an administrator has.

Every authentication attempt is recorded with the email address used, the source IP address, whether it succeeded and why it failed. Attempts against addresses that do not correspond to an account are recorded too, so an enumeration sweep leaves a trail rather than vanishing.

Caution

A locked account cannot be unlocked from the interface — it clears itself after the lock window. Keep at least one administrator account whose credentials are held somewhere you can actually reach, and prefer waiting out the window to disabling the control.

Related

• Multi-factor authentication — the second factor, and organisation-wide enforcement.
• SSO — signing in through your identity provider, including from the lock panel.
• Settings — the rest of the general settings page.
• Logging in — the sign-in flow these controls sit on top of.