Session Idle Timeout

This page describes the nowisor-session-timeout check from the nowisor Instance Scan Pack v1.0.0. The check audits the glide.ui.session_timeout system property and produces a finding when the configured timeout exceeds 30 minutes (the recommended baseline), is set to a non-numeric value, or has been removed from sys_properties entirely.

What this finding means

Your ServiceNow instance keeps authenticated sessions alive longer than the 30-minute baseline recommended for regulated workloads. The system property glide.ui.session_timeout controls how many minutes of inactivity the platform will tolerate before invalidating an authenticated session and forcing re-authentication.

The default on Zurich Patch 6 is 30, which clears the baseline. Earlier releases shipped with 90 (an hour and a half), and some long-running instances still carry that legacy value forward through clone chains. A 90-minute timeout means a session cookie stolen from a workstation left unattended at lunch is still valid when the user returns from a meeting at 2pm.

The check is a threshold, not a binary. It fires when the value is missing, non-numeric, or numerically greater than 30. A finding at value 60 is materially different from a finding at value 9999 (effectively unlimited) — your scan report carries both the actual value and the delta from the threshold in the finding metadata.

Why it matters for your compliance

Session timeout is one of the controls regulators consistently look at when they want concrete evidence that an organization understands the window of exposure created by every authentication event.

NIS2 Article 21§2(j) — identity and access management. NIS2 expects entities to manage the lifecycle of authenticated sessions, not just the moment of authentication. A 90-minute idle window doesn't fit a defensible identity-management program because it gives an attacker an hour and a half of free time after every stolen cookie or unattended workstation.

ISO 27001 A.8.5 — secure authentication. The control text requires that authentication procedures resist common attack patterns. Session theft via stolen JSESSIONID is one of the most common attack patterns; the timeout is the structural mitigation. A session that lasts longer than the user's typical workflow is a session that holds value for the attacker after the user has walked away.

DORA Article 9 — ICT risk management framework. Financial entities under DORA face explicit expectations around session lifecycle as part of operational resilience. A long idle timeout extends the blast radius of any single compromise event, which is a finding the JST (Joint Supervisory Team) is trained to flag during onsite reviews.

The check's 30-minute baseline is the conservative end of the regulator-comfortable range. Some entities run at 15 minutes for admin sessions and 30 for end-user sessions; both are defensible. Anything above 60 minutes starts requiring a documented compensating control.

The attack path

The risk is not theoretical. The path is the same one that has driven session-management hardening for two decades.

Step 1 — Cookie capture. An attacker obtains a JSESSIONID cookie via one of several routes: a stolen laptop with cached browser state, an XSS payload that read document.cookie before HttpOnly was enforced, a network sniff against an HTTP-served subresource if the Secure flag was not enforced, or a malicious browser extension. The cookie itself is opaque, but it's all the attacker needs.

Step 2 — The dwell window. The attacker submits the cookie to the instance from their own machine. As long as the session has not exceeded the idle timeout, the platform accepts it. With a 90-minute window, the attacker has a working hour and a half to operate against the instance — long enough to enumerate roles, exfiltrate data, or plant persistence (a malicious Business Rule, an admin role grant on a sleeper account).

Step 3 — The fadeout. When the timeout finally expires, the session invalidates. The attacker is locked out — but everything they did during the window is permanent. The user, returning from lunch, sees a re-authentication prompt and assumes nothing unusual happened.

The defense is structural: a 30-minute window cuts the attacker's working time by two-thirds versus the 90-minute legacy default. Combined with concurrent-session limits and absolute (not just idle) timeouts, the dwell window collapses to a length where the attacker cannot complete a meaningful action without re-detecting.

How to fix it

The fix is one property change in System Properties:

glide.ui.session_timeout = 30

Apply via System Properties → glide.ui.session_timeout. The new value takes effect on the next session establishment; existing sessions are not retroactively shortened.

If you operate in a regulated industry — financial services under DORA, critical infrastructure under NIS2 — consider going further:

• Admin sessions at 15 minutes. Implement via the ServiceNow Authentication Policy module or via a Business Rule that checks for admin role and forces re-authentication at a shorter interval.
• Absolute session timeout. Idle timeout protects against unattended workstations; absolute timeout (typically 8-12 hours) protects against persistent session abuse. Configure via glide.security.session_window or equivalent depending on release.
• Concurrent session limits. Cap users at 3-5 concurrent sessions; cap admin role holders at 1-2. Prevents an attacker from running a parallel session on a stolen cookie while the legitimate user remains authenticated.
• Invalidation on password change. Ensure that changing a user's password invalidates all active sessions for that user. This is the standard ServiceNow behavior but verify it has not been disabled by a customization.

The 30-minute baseline is the floor for compliance. The hardened configuration above is what regulators want to see in a mature deployment.

How to verify the fix

Run this Background Script after applying the property change. It reads the live value and reports compliance with explicit baseline context:

// Verify nowisor-session-timeout. Read-only, safe for production.
// Confirms glide.ui.session_timeout is within the recommended baseline of 30 minutes.
(function verifySessionTimeout() {
    var prop = 'glide.ui.session_timeout';
    var value = gs.getProperty(prop, 'NOT_SET');
    var n = parseInt(value, 10);
    gs.print('Property ' + prop + ' = ' + value);
    if (value === 'NOT_SET') {
        gs.print('[FAIL] Property is not registered. Set to 30.');
    } else if (isNaN(n)) {
        gs.print('[FAIL] Value is not numeric. Set to 30.');
    } else if (n > 30) {
        gs.print('[FAIL] Value of ' + n + ' exceeds baseline of 30 minutes.');
    } else {
        gs.print('[PASS] Value of ' + n + ' minutes is within baseline.');
    }
    gs.print('Companion: glide.guest.session_timeout = ' + gs.getProperty('glide.guest.session_timeout', 'NOT_SET'));
    gs.print('Companion: glide.unauthorized.session_timeout = ' + gs.getProperty('glide.unauthorized.session_timeout', 'NOT_SET'));
})();

Re-run the nowisor scan after applying the fix. The check should no longer produce a finding for this property.

What to do next

Session timeout rarely appears alone. The same operational era that left a 90-minute timeout in place usually left the cookie security flags off as well — review these companion findings:

• nowisor-cookie-http-only — without HttpOnly, an XSS finding becomes a session-theft primitive, which extends the impact of a long timeout.
• nowisor-cookie-secure — without Secure, sessions can be sniffed over plain HTTP.
• nowisor-csrf-token-enforcement — CSRF + long timeout = phishing click leads to admin role assignment without the attacker ever stealing a cookie.
• nowisor-mfa-enforcement — MFA does not stop session theft (the session is already authenticated), but it makes the credential-recovery path materially harder.

For DORA-compliant deployments, the nowisor advisor product is being built to package session-management findings into the DORA Article 9 evidence cluster with the absolute-timeout, concurrent-session, and IdP-coexistence findings, giving your compliance team a single export to attach to ICT operational resilience documentation. See the DORA evidence flow →