> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Session lifetime policy

> Configure inactivity and absolute session limits for an organization.

## Overview

The session lifetime policy limits how long users can remain signed in. It is
configured separately for each organization and applies to both new and
existing sessions.

You need the **Manage authentication** (`authenticationManage`) permission to
view or change this policy. Platform authentication providers remain restricted
to platform Super Admins.

## Configure session limits

<Steps>
  <Step title="Open Authentication settings">
    Go to **Settings → Authentication** and find **Session Lifetime Policy** in
    the Security Policy card.
  </Step>

  <Step title="Select the organization">
    Platform Super Admins can select an organization. Other authorized
    administrators can manage only their current organization.
  </Step>

  <Step title="Set the idle timeout">
    Enter the maximum period of inactivity before CaseBender requires the user
    to sign in again. The allowed range is **5–1,440 minutes**. The default is
    **30 minutes**.
  </Step>

  <Step title="Set the absolute lifetime">
    Enter the maximum total age of a session, even while the user remains
    active. The allowed range is **60–10,080 minutes**. The default is
    **480 minutes (8 hours)**.
  </Step>
</Steps>

The absolute lifetime must be greater than or equal to the idle timeout.
Changes are saved when you leave the field.

## How enforcement works

* Activity refreshes the idle timer but never extends the absolute lifetime.
* CaseBender evaluates protected page and API requests against the current
  organization policy.
* A policy reduction also applies to sessions that were created before the
  change.
* When either limit is reached, the server revokes the session and requires a
  new sign-in.
* Policy updates can take up to 60 seconds to propagate to every application
  process.

<Note>
  A page already displayed in a browser does not disappear at the exact timeout
  instant if it makes no server requests. The next protected navigation, data
  refresh, or action is rejected and requires sign-in.
</Note>

## Recommended starting points

* Use a shorter idle timeout for privileged or shared-workstation users.
* Keep the absolute lifetime within a normal work shift unless your security
  policy requires a shorter period.
* Test policy reductions with a non-production account before applying them to
  a large organization.
* Coordinate these limits with your identity provider's own session and
  single-sign-on policies. The shortest effective limit can require the user to
  authenticate again.

## Troubleshooting

### The policy controls are not visible

Confirm that your effective role includes `authenticationManage` and that you
are using an internal account. External collaborators cannot access
Authentication settings.

### Users remain on an open page after the timeout

This does not mean the server session is still valid. Ask the user to navigate
or refresh. The next protected request triggers session validation.

### A value cannot be saved

Confirm that the idle timeout and absolute lifetime are within their supported
ranges and that the absolute lifetime is not shorter than the idle timeout.

## Related documentation

* [Authentication and MFA](/en/security/authentication)
* [Access control](/en/security/access-control)
* [Activity logs](/en/audits/activity-logs)