Resource Policies
Create and assign policies that control authentication, device, and location requirements for individual Resources.
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.
Rolling policy window
Any successful authentication event resets the timer across all Resources, not just the one being accessed. Users who access multiple Resources in a session will not be prompted to re-authenticate at each one — each successful authentication rolls the window forward for the entire session.
You can disable authentication requirements entirely to create a device-only policy. See Device-only Resource Policies for details.
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.
Location Requirements
Enterprise only
Geoblocking is available on the Enterprise plan.
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.
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.
Overrides always take precedence over the Resource-level policy
If a user belongs to at least one Group with a policy override for a Resource, Twingate disambiguates only among the policies associated with that user’s Groups, not the Resource-level policy itself.
For example, if a user is a member of two Groups with overrides (Policy A and Policy B) for a Resource whose Resource-level policy is Policy C, Twingate only chooses between Policy A and Policy B. Policy C is never evaluated for that user.
If instead Group A has no override and inherits the Resource-level policy while Group B overrides to Policy B, Twingate disambiguates between the Resource-level policy and Policy B, since the Resource-level policy is now one of the Group policies in play.
How Twingate Disambiguates Between Multiple Policies
A user can end up with more than one policy applicable to the same Resource, usually because they belong to multiple Groups that resolve to different policies. When that happens, Twingate picks a single policy to enforce using the following order.
Twingate first looks for a policy the user already satisfies. If the user has an existing authenticated session that meets one of the applicable policies, Twingate uses that policy and grants access without prompting the user again.
If the user hasn’t authenticated into any of the applicable policies yet, Twingate favors whichever one is easiest to satisfy given the user’s current state. For example, it will pick a policy that doesn’t require MFA over one that does, or a policy whose device requirements the user’s device already meets over one it doesn’t. Twingate is looking for the path of least resistance to the Resource, not defaulting to the strictest policy in the set.
The set of policies being compared always follows the override rule described above: each Group the user belongs to contributes either its override or, if it has none, the Resource-level policy.
Every requirement of the selected policy is still enforced
This logic only decides which policy to check the user against. It doesn’t relax or skip requirements. Once a policy is selected, the user must fully satisfy it, including MFA and device checks, before being granted access.
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.
Last updated