Resource Policies

Resource Policies define the security requirements that users must satisfy to access a specific Resource. Each policy can combine authentication requirements, device security requirements, and location restrictions into a single rule set that is applied at the Resource level.

Resource Policies are managed under the Resource Policies tab on the Policies page in the Admin Console.

Creating a Resource Policy

Click Create on the Resource Policies tab to create a new policy. Each policy has a name and up to three types of requirements (Authentication, Device, and Location), all of which are optional.

Every Twingate network includes a Default Policy that is automatically assigned to all new Resources. The Default Policy can be edited but not deleted.

Policy Requirements

Authentication Requirements

Authentication requirements control how often users must re-authenticate when accessing Resources protected by this policy. Two settings are available:

• Authentication frequency: How often the user must re-authenticate, ranging from 1 hour to every 31 days. When the timer expires, Twingate checks the stored IdP session. If it is still valid, the user continues without interruption. If it has expired, the user is redirected to the IdP.
• MFA: Whether Twingate’s native multi-factor authentication is required. When enabled, users must complete MFA at the frequency specified above.

You can disable authentication requirements entirely to create a device-only policy. See Device-only Resource Policies for details.

→ Multi-Factor Authentication

Device Security

Device security requirements control which devices can access Resources protected by this policy. Three modes are available:

• Any Device: Any device that can successfully sign in to the network, meaning it meets the Approved Operating System requirements or a Trusted Profile. This is the default.
• Only Trusted Devices: Only devices that meet the requirements of a Trusted Profile. Devices that meet Approved Operating System requirements alone are not sufficient.
• Custom: Select specific Trusted Profiles and Approved Operating System configurations that satisfy this policy.

The Manage Device Security link on the policy detail page opens the Device Profiles configuration, where you define the profiles and OS requirements referenced here.

→ Device Profiles

Location Requirements

Location requirements restrict access based on the geographic location of the user’s device. You can configure either an allowlist (only specified countries can access) or a denylist (specified countries are blocked).

Certain countries are always blocked due to embargoes and cannot be overridden: Cuba, Iran, North Korea, and Syria.

→ Location Requirements

Assigning Policies to Resources

A Resource Policy is assigned on the Resource’s detail page. The assigned policy applies to all Groups with access to that Resource by default.

To change the policy for a Resource, open the Resource in the Admin Console and select a different policy from the available options.

Group-level Policy Overrides

You can override the Resource-level policy for specific Groups. This is useful when different teams require different levels of access to the same Resource — for example, applying a stricter policy to a contractors Group while keeping the default for internal teams.

To set an override, open the Resource detail page and change the policy for an individual Group’s assignment. The override applies only to users in that Group.

Once a Group’s policy is overridden, it stays overridden even if the Resource-level policy changes. To return a Group to inheriting the Resource-level policy, reset the override for that Group.

Session Behavior

Before a Resource Policy’s authentication timer expires, Twingate checks whether the user is actively accessing the Resource. If they are, a prompt is displayed approximately 10 minutes before expiry, giving them the option to extend the session. If the user is not actively using the Resource, no prompt is shown.

If the user chooses to re-authenticate, Twingate checks the stored IdP session. If it is still valid, the user is re-authenticated without being redirected, and all session timers reset. If the IdP session has expired, the user is sent to the IdP to re-authenticate — after which all timers reset.

If the user ignores or dismisses the prompt, the session expires and access to the Resource is cut off. The next time the user attempts to access the Resource, they will be prompted to authenticate before a new session is established and access is restored.

For a detailed walkthrough of how session timers interact, including edge cases around IdP session expiry and device-only policies, see the sessions guide.

→ How Sessions Work