Overview

Twingate is introducing new functionality called Security Policies, which is a flexible way to manage access control more granularly throughout your network. This is an addition to our security capabilities; when this functionality is enabled for your Twingate Network, your existing security configuration will be preserved.

Understanding Security Policies

Access Policies are currently a property of your Identity Provider (IdP) configuration and have a limited set of configuration options. Security Policies will significantly expand the range of access control configuration available directly within the Twingate Admin Console. With this expanded functionality, we’ve introduced new terminology that is summarized below.

We also strongly encourage you to read the Security Policies documentation to gain additional familiarity.

Existing functionality	New functionality	Comments
Default Access Policy	Network Sign In policy Default Policy	The Default Access Policy is currently used to both authenticate users when they connect to your Network using the Twingate Client and is made available as the default policy for Groups. Security Policies introduces two changes:An explicit Network Sign In policy, which is the policy that applies when users connect using the Client application.A Default Policy that is applied to every new Group by default. This default policy assignment to Groups can be changed later.
Admin Access Policy (Okta & OneLogin only — for Google Workspace and Entra ID this is identical to the Default Access Policy)	Admin Console Sign In policy	This sign in policy for the Admin Console remains unchanged in behavior except for a new name.
Custom Access Policies	Custom Resource Policies	Custom access requirements are still possible, but with expanded and more flexible capabilities via Resource Policies. A Resource Policy defines conditions that you wish to apply to Resource access. Normally this consists of a combination of a Sign In policy and any additional access requirements you wish to define in the custom Resource Policy.

What new capabilities will Security Policies introduce?

Currently it is not possible to apply different security controls for different Resources on your network without IdP support and configuration. Security Policies will enable this functionality by creating the concept of rule sets that can be customized entirely within the Twingate Admin Console.

Security Policies will be configured in a new Policies section in the Admin Console and assigned to Resources using the existing Group concept in Twingate that you already use for access control. Assigning a Security Policy to a Group will apply that Policy anytime a User in the Group accesses a Resource in the Group.

Here are some examples of things you will be able to do with Security Policies that aren’t currently possible:

• Two-Factor Authentication will be available without requiring an IdP to be configured.
• You can now configure 2FA to apply only on access to certain Resources, instead of for login only.
• Similarly, you can configure a custom session lifetime for specific Resources, to require users to authenticate more frequently when they try to access them.

While the number of available rules will initially be limited, going forward, Security Policies will be the foundation upon which we will build all our upcoming security functionality, including device posture and geolocation restrictions.

Migration for existing Twingate Networks

After migration, the behavior that you and your users experience with Security Policies will be identical to the experience you had previously. The sections below detail how your existing Access Policies will be migrated depending on your IdP configuration.

Google, Entra ID, and no IdP configured

• The Network Sign In Policy will be configured with the session lifetime that is configured for your Default Access Policy currently. 2FA will also remain enabled, if you have 2FA enabled currently.
• The Default Policy will be configured with the same session lifetime as your existing Default Access Policy. No additional controls beyond authentication will be added to this policy.
• The Default Policy will be assigned to all existing Groups.
• The Admin Console Sign In policy will be created with 2FA enabled, if it is enabled in the existing Admin Access Policy.

Okta and OneLogin

All of the above migration changes apply, with the addition of the following. (This situation is not common, and does not apply to the majority of Twingate Networks.)

If you configured additional Access Policies beyond the Admin and Default Access Policies:

• Additional Security Policies will be created with the same session lifetime as the existing Access Policy.
• The name of any new Security Policies will match the existing name(s).
• Any new Security Policies will be assigned to the same Group(s) as the existing Access Policy.

Questions?

Please contact us if you have any questions about Security Policies, or if you would like recommendations on how to structure them most effectively.