How Sessions Work

How Twingate's authentication frequency controls work and how re-authentication is handled in practice.

Twingate gives admins two authentication frequency controls: the Sign In Policy and Resource Policies. Together, these determine how often users must re-authenticate during normal use of the network. Behind the scenes, Twingate also stores a copy of the user’s IdP (Identity Provider) session and uses it to manage re-authentication smoothly. Understanding how these pieces interact is key to building a policy configuration that balances security with a smooth user experience.

Authentication Frequency Controls

Two timers govern when a user is asked to re-authenticate:

• Sign In Policy session: Set on the Sign In Policy. When this timer expires, the user is signed out of the Twingate Client and must re-authenticate to sign back in. This is the baseline session that gates access to Twingate as a whole.
• Resource Policy session: Set on each Resource Policy. When this timer expires, the user must re-authenticate before continuing to access Resources protected by that policy. Each Resource Policy has its own timer.

The two timers are configured independently, but they interact: a successful Resource Policy re-authentication resets the Sign In Policy timer.

How Twingate Handles Re-authentication

When a Twingate timer expires and re-authentication is required, Twingate does not automatically send the user back to your IdP. Instead, it first checks a stored copy of the user’s IdP session (captured at the user’s last successful sign-in) to determine the right flow:

• Stored IdP session is still valid: A Twingate-hosted page briefly opens in the user’s browser, confirms the existing session, and completes re-authentication. The user is not redirected to the IdP and (unless MFA is required by the Resource Policy) does not need to take any action.
• Stored IdP session has expired: The user is redirected to your IdP to sign in again. After successful authentication, all Twingate timers reset.

The stored IdP session is an internal mechanism. Admins do not configure it in Twingate. Its lifetime is controlled by the IdP itself:

• Enterprise IdPs (Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin): Admins can configure session lifetimes on the IdP side.
• Social IdPs (Google, Microsoft, LinkedIn, GitHub social logins): Session lifetimes are set by the provider and cannot be modified by the organization.

Other SSO-linked applications a user accesses through Twingate manage their own sessions independently. Whether or not those applications are affected when Twingate triggers a re-authentication varies by application. Twingate does not directly influence their session state.

Aligning IdP session lifetime with Twingate policies

If you use an enterprise IdP, the IdP session lifetime can be used as an additional layer alongside your Twingate policy timers. For example, a shorter IdP session lifetime will cause users to be redirected to the IdP more often when Twingate triggers a re-authentication check. In most environments, admins should rely on Twingate’s policy timers as the primary control.

The Rolling Window

The Sign In Policy session timer uses a rolling window. Each time a Resource Policy re-authentication succeeds, the Sign In Policy timer resets to its full duration.

In practice, this means users who regularly access Resources with authentication requirements will have their Sign In Policy session extended automatically. Users who stop accessing Resources will eventually hit the Sign In Policy expiry and be signed out.

Device-only policies do not extend the Sign In Policy

Resource Policies with authentication disabled (device-only policies) do not satisfy the Sign In Policy’s authentication requirements. Accessing Resources behind device-only policies will not reset the Sign In Policy timer.

Session Evaluation Walkthrough

With the default Sign In Policy (30 days) and a Resource Policy set to 8 hours, the experience for most users is low-friction:

Sign-in: The user authenticates once through the Twingate Client. The Sign In Policy session is valid for 30 days. The Resource Policy session expires after 8 hours.

Resource Policy check: When the 8-hour timer expires, Twingate checks the stored IdP session. If it is still valid, the user is re-authenticated automatically and timers reset. If the stored IdP session has expired, the user is redirected to the IdP to re-authenticate, after which timers reset.

Day-to-day: As long as the user accesses Resources regularly, the Sign In Policy timer rolls forward automatically. Under normal usage, most users will not see a Sign In Policy expiry prompt.

User Offboarding

When a user needs to be removed from the network, whether planned or in response to an incident, the speed of access revocation depends on which systems are updated and how.

Recommended approach

To revoke access within 5 minutes:

• Block the user’s devices in Twingate: via the Admin Console or the API. Device blocks are enforced within 5 minutes for active connections. This step works for all users regardless of IdP type.
• Suspend the user in your IdP (enterprise IdPs only): and revoke all active sessions. The IdP will sync the update with Twingate, which disables the user. The timing of this update depends on the IdP but can be up to an hour.
• Disable the user in Twingate (social logins only): via the Admin Console or the API. Disabling the user entry will cause existing sessions to be revoked within 5 minutes on average and will prevent the user from accessing any additional Resources.

For users on enterprise IdPs, doing both steps together covers two failure modes: if the SCIM update is delayed, the device block still takes effect, and vice versa. For users on social IdPs (Google, Microsoft, LinkedIn, GitHub), SCIM is not available. Blocking devices and disabling users in Twingate are the primary revocation mechanisms.

Deactivate rather than delete (enterprise IdPs)

Most enterprise IdPs recommend deactivating (suspending) a user rather than deleting them. Deactivation preserves audit logs and IdP records while still revoking all access. The effect on Twingate access is identical: the user is disabled within 5 minutes either way.

Policy Design Best Practices

Sign In Policy

Set the Sign In Policy authentication frequency to a long interval (up to 30 days). The Sign In Policy acts as a baseline gate, not the primary security control. Resource Policies handle per-Resource security, so a lenient Sign In Policy reduces unnecessary friction without weakening your security posture.

Resource Policies for long-lived connections

Resources that support long-running sessions (such as servers accessed via RDP or SSH) should use a longer authentication frequency (12 to 16 hours). This avoids mid-session disconnects while still requiring re-authentication at the start of each workday.

Resource Policies for short-lived connections

Resources behind short-lived connections (such as internal web applications) can follow the same pattern or use shorter intervals, depending on sensitivity. For most internal tools, a 12- to 16-hour frequency works well.

Business-critical Resources

Resources with high sensitivity should use shorter authentication frequencies regardless of connection type. How short depends on your organization’s risk tolerance, but these Resources typically warrant more frequent re-authentication than the once-per-day baseline.

Device-only policies

Use device-only policies for Resources that should remain accessible without user interaction, for example system services or monitoring endpoints that need connectivity before a user signs in interactively. Device-only policies enforce device requirements but skip authentication, so the Resource is accessible as long as the Sign In Policy session is valid and the device meets the required profile.