Policy Types

Twingate has two types of Security Policies, both of which are used for different purposes. Different policy types may have different rules available to them, based on what is appropriate for the use case.

• Resource Policies: These Policies are applied to Resources at the time they are accessed by a user. Use these Policies to apply extra security to more sensitive Resources on your Network. There is always one Default Policy which is applied to all new Resources by default. You can create additional Resource Policies in the Admin Console.
• Minimum Authentication Requirements: This policy is applied to all users of Twingate when they attempt to log into the network. Users must fulfill the policy’s criteria before attempting to access any Resources, even if those Resources have more permissive Security Policies. In addition to the Minimum Authentication Requirements, a user’s device must meet either the minimum OS requirements or a Trusted Profile as specified in the Device Security Guide.

There’s an additional Admin Console Security Policy that can be configured. This is managed under the Settings tab. This policy is only applied to Twingate administrators when they attempt to sign into the Admin Console. Admins do not need to sign into Twingate to access the Admin Console, so the minimum authentication requirements are not applied here. See Admin Console Security for more information.

Rule Types

The following rule types may be applied to Policies:

Rule	User-based	Device-based	Notes
Authentication	✅		Authentication for the Admin Console Security Policy cannot be modified and is tied to your Identity Provider configuration.
Two-Factor Authentication	✅		TOTP code that can be used with any third party authenticator app.
Device Security		✅	Devices meeting any of the minimum OS requirements or Trusted Profiles will be allowed to sign in to Twingate.

Policy Management

You can create a new Resource Policy by clicking the “Create Policy” button under Resource Policies.

You can edit new or existing Security Policies by selecting the relevant policy in the Policies tab. Here you can add new requirements and edit or remove existing requirements. Authentication Requirements specify the authentication needed for this policy specifically, and layers on top of broader Minimum Authentication Requirements. Device Security identifies which types of devices (all, Trusted Devices, or custom) will meet this policy. For more information, see Device Security Guide.

Policy Application

Security Policies are applied to Resources, and Groups are assigned access to Resources. If a user is in a Group with access to a Resource, they will need to fulfill any requirements of the Security Policy for that Resource. By default, all Resources will use the Default Policy; you can change this by editing the Resource.

The Resource Policy assigned to the Resource can be overriden with a different policy for specific Groups with access to the Resource. For example, in the screenshot above, the Resource Policy is the Default Policy. For any Groups that are given access to this staging environment, they will automatically have the Default Policy applied. However, for the Contractor and Normal groups, different Policies are required. This means that users within the Contractor group will need to meet the Contractor Policy in order to access the staging environment, and users within the Normal group will need to meet the Secure Policy in order to access the staging environment.

The policy for a specific Group can be modified via the Resource page.

Once a policy has been changed for a specific Group, the policy will be considered overridden. Even if the Resource Policy changes, the policy for that specific Group will not be changed. In the example above, if the staging environment’s Resource Policy is changed from Default Policy to Secure Policy, the Contractor Group will still continue to use the Contractor Policy. In order to have the Contractor Group return to inheriting the Resource Policy, the override can be removed by resetting it for that Group.

Additional Policy Configuration

In addition to selecting the Policy that can be applied, Twingate also supports ephemeral and usage-based access.

Ephemeral access can be configured at the Resource level or for a specific Group’s access to that Resource. With this, you can select an expiration date at which point that Group will be removed from the Resource. See Ephemeral Access to Resources for more information.

Usage-based access can also be configured at the Resource level or for a specific Group’s access to that Resource. With this, you can set a period of time after which a user’s access will be locked if they don’t access the Resource. Usage-based auto-lock is applied individually per user, helping you to ensure that only users who have a current need to access a Resource maintain that access. See Usage-based Auto-lock for more information.

Recommendations

Twingate recommends that you apply comparatively less strict Policies to the Minimum Authentication Requirements and focus more security controls on Resource Policies, especially those that are applied to more sensitive Resources. This will reduce the number of authentication or other security controls that users must go through, focusing them only on the times when they are actually accessing a protected Resource.