Security Policies

Configure access requirements for your Twingate network using Resource Policies, the Sign In Policy, and Device Profiles.

Twingate uses policies to control who can access your network and under what conditions. All policy configuration is managed under the Policies tab in the Admin Console, which is organized into three sections: Resource Policies, Sign In Policy, and Device Profiles.

Resource Policies

Resource Policies define the security requirements that users must meet when accessing a specific Resource. Each policy can include up to three types of requirements:

Authentication: How often users must re-authenticate and whether MFA is required.
Device Security: Which devices are allowed to access the Resource, based on Trusted Profiles or approved operating systems.
Location Requirements: Country-level access restrictions via geoblocking (Enterprise only).

Every Twingate network includes a Default Policy that is automatically assigned to new Resources. You can create additional policies to apply different levels of security to different Resources.

→ Resource Policies

Assigning Policies to Resources

A Resource Policy is assigned at the Resource level and applies to all Groups with access to that Resource. You can override the policy for specific Groups if certain teams need stricter or more permissive access.

For example, a database in a production environment might use the 1D-MFA-AllTrusted for most teams (meaning 1 day session length, multi-factor required, only Trusted devices) but allow a less strict policy for an engineering Group. If the Resource-level policy changes later, any Group-level overrides remain in place until you explicitly reset them.

Policy Overrides

Each Resource has a policy assigned, and Groups accessing that Resource can optionally have a policy override. When an override is set, Twingate applies whichever of the two policies is more permissive.

Apply the strictest policy at the Resource level and use Group-level overrides to relax requirements for specific teams where needed.

Disabling Authentication Requirements

You can disable the authentication requirement on a Resource Policy to create a device-only policy. When authentication is disabled, the policy only checks device requirements. The user does not need to re-authenticate to access Resources protected by that policy, as long as their Sign In Policy session is still valid.

→ Device-only Resource Policies

The Sign In Policy controls the baseline requirements for signing in to the Twingate Client. Every user must satisfy this policy before they can view or access any Resources, regardless of what Resource Policies are in place.

The Sign In Policy includes three requirements:

Device Security: The user’s device must meet the Approved Operating System requirements or a Trusted Profile defined in Device Profiles.
Authentication frequency: How often the user must re-authenticate via your identity provider (IdP). This session timer uses a rolling window that resets each time a Resource Policy re-authentication succeeds.
MFA: Whether Twingate’s native two-factor authentication is required at sign-in.

The Sign In Policy tab showing device security, authentication frequency, and MFA settings

Recommended configuration

Keep the Sign In Policy relatively lenient (for example, a 30-day authentication frequency) and use Resource Policies to enforce stricter requirements on sensitive Resources. This reduces unnecessary re-authentication prompts for users while maintaining strong controls where they matter most.

→ How Sessions Work

Device Profiles

Device Profiles define what it means for a device to be trusted and set baseline requirements for the operating systems that can access your network. The Device Profiles tab has two sections:

Trusted Profiles

Trusted Profiles identify devices that meet a specific verification method, either manual verification or an MDM/EDR integration. Each profile targets a single platform and can include additional device posture checks on top of the verification method.

Supported verification methods:

Once created, Trusted Profiles can be referenced in both the Sign In Policy and Resource Policies to restrict access to verified devices.

Approved Operating Systems

Approved Operating Systems set the baseline requirements for each platform. You can enable or disable each platform individually. Blocking a platform here prevents users on that platform from signing in to Twingate entirely.

For each enabled platform, you can require native device posture checks such as hard drive encryption, screen lock, firewall, and minimum OS version. These requirements vary by platform.

→ Device Profiles

→ Device Posture Checks

How Policies Work Together

Twingate evaluates policies in layers. A user must satisfy all applicable layers to access a Resource:

Device Profiles: The device must meet either the Approved Operating System requirements or a Trusted Profile. This is checked at sign-in and periodically thereafter (approximately every 5 minutes).
Sign In Policy: The user must have a valid sign-in session. If the session has expired, the user must re-authenticate via their IdP.
Resource Policy: When the user accesses a specific Resource, the Resource Policy requirements are evaluated. If the policy requires authentication, Twingate checks whether the IdP session stored at sign-in is still valid. If it has expired, the user is redirected to the IdP to re-authenticate.

When a Resource Policy re-authentication succeeds and its requirements are a superset of the Sign In Policy requirements, the Sign In Policy session timer resets. This extends the sign-in session without requiring a separate sign-in prompt.

IdP session lifetime matters

At sign-in, Twingate captures and stores the session expiry time returned by the IdP. When a policy check requires re-authentication, Twingate compares the current time against that stored expiry. If it hasn’t elapsed, the session is treated as valid and no redirect occurs. Once the stored expiry has passed, Twingate redirects the user to the IdP, captures the new session expiry, and continues from there.