Control Remote Access Sessions

How session lifetime, idle timeout, and device logout controls end a user's remote access in SonicWall Cloud Secure Edge (CSE)

  • Last validated: Sep 25, 2026
  • 5 minutes to read
  • Contributors

Overview

A user’s remote access in CSE lasts as long as their session. While the session is valid, the CSE desktop app can connect Service Tunnels and reach the private resources the user’s policies allow, without asking the user to sign in again.

Admins control how and when that session ends with three settings:

Setting What ends the session Where to configure it
Authentication token and trust certificate lifetime Reaching the maximum session length Settings > Configuration > Advanced
Session idle timeout A period with no user input on the device Settings > Configuration > Advanced
End session on desktop logout or reboot The user signing out of the device or restarting it Settings > Configuration > Advanced

All three end the session the same way. The CSE desktop app logs the user out and disconnects the connections it carries, which are Service Tunnels and infrastructure services. The user’s next attempt to reach one of those resources starts a new login flow.

Warning: Hosted websites are the exception. A hosted website is reached through the browser, so ending a session does not revoke access to one unless it has Secure CORS Requests enabled. If you are enabling these settings to meet a requirement that all access stop, read Hosted websites first.

Session idle timeout and end session on desktop logout or reboot are both off by default. Leaving them off preserves the smoothest experience for users, so turn them on when a compliance requirement or an internal policy calls for them.

Maximum session length

The longest a session can last is set under Authentication Tokens and Certificates, which controls how often the CSE app re-authenticates an end user’s session. Elsewhere in the console this cap is referred to as the session duration.

One expiration time covers everything CSE issues for the session: the TrustToken (a JWT id_token), the TrustCert (an X.509 client certificate), the SSHCert (an SSH client certificate), and the WireGuard key pairs. It accepts 8 to 240 hours, in 1 hour increments, and defaults to 24 hours.

This expiration runs on a clock, not on what the user is doing. It ends the session on schedule whether or not anyone is at the device. That is why it cannot on its own meet a requirement to end sessions that have gone unused, which is what session idle timeout below is for.

This setting is not new, and it applies whether or not the two controls below are enabled. The desktop app shows the remaining time at the top of its window, where it is labeled as the session timeout.

Once this expiration time is reached, the session ends regardless of how active the user has been. A user working continuously for longer than the configured expiration is signed out and asked to authenticate again.

Session idle timeout

Session idle timeout ends a session after a configured period with no user input on the device. When the timeout is reached, the CSE desktop app logs the user out, disconnects the connections it carries, and the user must reauthenticate to reconnect.

In this release, idle timeout applies to the CSE desktop app on Windows, macOS, and Linux.

What counts as inactivity

Inactivity means no user input at the device for the configured duration. Keyboard, mouse, and touch all count as input. CSE reads the operating system’s own user-input idle signal, the same one that triggers the OS screen lock.

CSE does not count network traffic as activity. Sync clients, update agents, and apps that poll in the background all produce traffic while nobody is at the device, so a session could stay open indefinitely on an unattended machine. Using user input instead means the timeout reflects whether someone is actually there.

This is also the definition an auditor will look for, so you can answer that question directly: no user input at the device for the configured duration.

Locking the screen does not by itself end a CSE session. The idle timeout is what ends the connections.

Choosing a value

The field accepts 5 minutes to 480 minutes, which is 8 hours. Set it to 0 to disable it, which is how it ships.

  • 15 minutes is where most frameworks land, including PCI DSS. Start here if you are configuring this to meet a compliance requirement.
  • 5 to 10 minutes is available if your own security policy is stricter. IRS Publication 1075 recommends 5 minutes for workstations.
  • Above 30 minutes suits a policy meant to cover a full working day. No framework asks for a value this high.

Warning: An idle timeout set at or above your maximum session length never takes effect, because the session ends first. The shortest maximum session length you can set is 8 hours, so a 480 minute idle timeout does nothing in an org using that value. Keep the idle timeout well below your maximum session length.

Note: Changes take effect for each user at their next login or app restart. They do not apply to a session already in progress.

This is a separate control from maximum session length, and the two work together. Maximum session length caps how long a session can last regardless of activity. Idle timeout ends a session early when the device has been left unattended.

What the user sees

When the timeout fires:

  • Service Tunnel and infrastructure service connections are ended, and the user is logged out of the app.
  • The user gets a native operating system notification titled “Logged out due to inactivity,” explaining that the logout followed a period with no activity per their organization’s policy, with a button to log in again.
  • The desktop app comes to the front of the screen, and its login screen carries a banner explaining that the session ended after inactivity.

Compliance frameworks requiring an inactivity timeout

Many frameworks require a timeout of this kind. The values below are what each one asks for, and every one of them is within the range you can configure.

Framework Control Threshold
PCI DSS v4 8.2.8 15 minutes
HIPAA 45 CFR 164.312(a)(2)(iii), Automatic Logoff Not specified
NIST SP 800-171 / CMMC 2.0 3.13.9 / SC.L2-3.13.9 Organization-defined
FedRAMP and NIST SP 800-53 AC-11, AC-12, SC-10 15 minutes at Moderate and High
NIST SP 800-63B Reauthentication 30 minutes at AAL2, 15 minutes at AAL3
CJIS Session lock 30 minutes
IRS Publication 1075 Federal tax information 15 minutes
CIS Controls v8 4.3 15 minutes
IEC 62443-3-3 SR 2.6 Configurable, for OT environments
HITRUST CSF 01.t Per framework

NIST SP 800-171 3.13.9 asks you to end network connections, not just lock the screen. Idle timeout does end connections rather than only locking the screen, which a screen lock on its own does not do, so it addresses that requirement for Service Tunnels and infrastructure services. If your assessment also covers access to hosted websites, see Hosted websites for what it takes to bring those under the same control.

Configure session idle timeout

1. In the Command Center, navigate to Settings > Configuration > Advanced.

2. Under Idle Timeout, enter the number of minutes of inactivity that should end a session. Use a value between 5 and 480, or 0 to disable.

3. Select Update.

Note: Session idle timeout applies to the CSE desktop app. It is a separate setting from User and Device Inactivity in the same Advanced section, which archives users and devices after a number of days of inactivity. See Archive Users and Devices after Inactivity.

Idle timeout in your logs

Idle timeout is recorded in three places, which together let you show both how the setting was configured and when it took effect:

  • Admin audit log. An entry each time an administrator enables, changes, or disables the idle timeout, including the values before and after a change.
  • Console event log. When a timeout ends a session, an Access event appears with the message “Service Tunnel Disconnected - Idle Timeout.”
  • Desktop app log. A matching entry on the device itself, which is useful if you need to open a support case.

End session on desktop logout or reboot

When this setting is enabled, the CSE desktop apps log out the user’s identity session and disconnect any sessions whenever the operating system is rebooted or the user logs out. Users must re-authenticate to regain access. Without it, a session continues for the remaining life of the authentication token.

The end result is the same as an idle timeout. The difference is what triggers it. Idle timeout responds to inactivity; this setting responds to an operating system event.

Without this setting, a session survives a reboot. If a user authenticates on a token with a 24 hour lifetime and then restarts their machine, the session is still valid when the machine comes back up. Admins had no control over that behavior before this release.

Two reasons to turn it on:

  • Compliance and internal policy. Some environments require that a session cannot outlive the device login it started under.
  • Lost or stolen devices. If a session survives a reboot, anyone who can get into the operating system inherits a live session to every resource the user could reach. Ending the session at logout or reboot removes that path.

Configure end session on desktop logout or reboot

1. In the Command Center, navigate to Settings > Configuration > Advanced.

2. Toggle on End Session on Desktop Logout or Reboot. The console confirms the change with a success message; there is no separate Update button for this setting.

Hosted websites

Whether the end of a session revokes access to a hosted website depends on how that website authenticates its users.

A classic hosted website keeps working

A classic hosted website authenticates in the browser. The Access Tier redirects the user to your identity provider, sets a CSE TrustCookie for that website’s fully qualified domain name, and validates the cookie on every request.

That cookie lives in the browser, not in the desktop app, so nothing the desktop app does at the end of a session revokes it. The cookie keeps granting access until it reaches the expiration set under Authentication Tokens and Certificates or the user closes their browser. This is a known limitation.

Secure CORS Requests changes that

Secure CORS Requests moves authentication out of the browser and into the connection. The desktop app’s local proxy attaches the user’s ID and access tokens to the HTTP CONNECT request it opens to the Access Tier, and the Access Tier binds the identity to that connection rather than to a cookie. This is also why preflight OPTIONS requests succeed under this design, since a browser never sends cookies on a preflight.

Because the identity now belongs to a connection the desktop app owns, ending the session ends access to the website, the same way it ends Service Tunnels and infrastructure services.

Bring a hosted website under these controls

Two things are required.

1. The device has to route its browser traffic through CSE, so that the desktop app’s local proxy is in the path. In the desktop app, version 4.4.0 and later, this is the Enforce CSE HTTP Proxy toggle. See Enforce CSE HTTP Proxy toggle. Without it, the desktop app is not in the path, and the cookie behavior above applies.

2. The hosted website has to have Secure CORS Requests enabled:

  • 2.1 In the Command Center, open the hosted website and go to the Advanced step of its configuration.
  • 2.2 Under Additional Configurations, enable Secure CORS Requests.
  • 2.3 Save the hosted website.

Note: See Register a Hosted Website to Users for the full configuration flow, and Exemptions and Cross-origin Resource Sharing (CORS) for how CSE handles CORS requests.

If you cannot meet both conditions, the way to bound hosted website access is a shorter expiration under Authentication Tokens and Certificates, which caps how long the browser cookie can stay valid. See Maximum session length.

How these settings interact with auto-login

Neither setting bypasses or breaks auto-login. When a session ends, the desktop app starts a new login flow rather than granting access.

  • If auto-login completes that flow without user interaction, the user is signed back in and their tunnels reconnect.
  • If auto-login cannot complete the flow, the user is challenged by your identity provider and completes the sign-in themselves.

What’s next

Was this page helpful?