# No persistent Browser Sessions > This Conditional Access Policy prevents users from maintaining persistent browser sessions, requiring them to re-authenticate more frequently. This Conditional Access Policy prevents users from maintaining persistent browser sessions, requiring them to re-authenticate more frequently. It helps reduce the risk of unauthorized access from shared or unmanaged devices. ## Settings this baseline controls | Setting | What it does | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Policy name | Specifies a display name for the Conditional Access Policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Enable policy | Specifies the state of the conditional Access Policy. Possible values are: enabled, disabled, enabledForReportingButNotEnforced. Required. [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Included users | User IDs in scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Included roles | Role IDs in scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Included groups | Group IDs in scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Included guest types | Guest or external user types in scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Excluded users | User IDs excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Excluded roles | Role IDs excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | **3 more settings** | Setting | What it does | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Excluded groups | Group IDs excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Excluded guest types | Guest or external user types excluded from scope of policy [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | | Persistent browser session | Session control to define whether to persist cookies or not. All apps should be selected for this session control to work correctly. [Learn more](https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-policy-persistent-browser-session) | [Adding a baseline](https://docs.octiga.io/baselines/adding-a-baseline/) — Add, configure or remove a single baseline on a tenant, a user or a group, without deploying a whole scheme. ## Configure it Add this baseline when users shouldn't stay signed in across browser restarts. It's useful on shared or unmanaged machines, where a persistent session is the easiest way for the next person at the keyboard to inherit someone else's access. 1. Add the baseline to the tenant directly (see [Adding a baseline](https://docs.octiga.io/baselines/adding-a-baseline/)), or carry it in a scheme you deploy to every tenant you manage (see [Deploying a scheme](https://docs.octiga.io/baselines/deploying-a-scheme/)). 2. Leave **Included users** covering everyone, and use **Excluded users** or **Excluded groups** for your organisation's break-glass accounts. 3. Leave **Persistent browser session** set to never persist. This session control only takes effect when the policy targets every resource. If you narrow the resources it applies to, some browser tabs stay persistent and others don't, because all tabs in a session share one token. 4. **Save.** Turn on **Auto-remediation** if you want Octiga to reapply the policy whenever it's changed in Microsoft 365. > **Licence: Entra ID P1 or P2:** This baseline needs Entra ID P1 or P2 on the tenant. Without it, Octiga excludes the baseline rather than reporting it as deviated — see [Licence requirements](https://docs.octiga.io/reference/licence-requirements/). ## Check it worked After the next sync, this baseline shows **Passing** once a policy with `state` set to `enabled` and persistent browser sessions set to never persist exists in Microsoft Entra. You can confirm it in the Microsoft Entra admin centre under **Entra ID > Conditional Access > Policies**. End users are asked to sign in again each time they close and reopen their browser, instead of being offered a "Stay signed in?" prompt. ## Standards this addresses ### CIS - **v8 4.1** — CIS Controls v8 Safeguard 4.1 - **v8 6.8** — CIS Controls v8 Safeguard 6.8 ### NIST - **PR.AC-4** — NIST CSF 2.0 PR.AC-4 - **AC-17** — NIST SP 800-53 AC-17 - **SC-7** — NIST SP 800-53 SC-7 ### ISO 27001 - **A.8.3** — ISO/IEC 27001:2022 Annex A.8.3 - **A.8.5** — ISO/IEC 27001:2022 Annex A.8.5 **Doing this for every tenant?** Step through the deploy wizard to apply a scheme to a tenant, groups or users, and see what Managed and Direct do at deploy time. [Deploying a scheme](https://docs.octiga.io/baselines/deploying-a-scheme/)