Native Two-Factor Authentication


Native Two-Factor Authentication

Universal 2FA & Identity-indexed network flow logs

Feb 24, 2021

Universal 2FA

Today we’re launching native two-factor authentication to our Business and Enterprise customers, which will allow more fine-grained controls independent of your chosen identity provider and independent of the destination resource. We call this experience Universal 2FA because it can be applied to any type of resource with zero application changes.

One of the “wow” moments for our customers is using Twingate’s Universal 2FA to apply discretionary security levels to resources according to their sensitivity. For example, admins can ensure that users with production network SSH access are subject to an additional 2FA challenge. The lack of application changes, and flexibility to work with any protocol or resource, means that security changes can be made immediately. The user experience is also seamless, operating in-line with the user’s workflow thanks to Twingate’s transport-level network routing.

Identity-indexed network flow logs

Every network connection in your Twingate network is authenticated against a central IdP and authorized by security policies defined in Twingate. This means that for the first ever, our customers now have an identity-first view of their private network flow. All private traffic is always directly associated with user identity, including the authorization rule that allowed the connection, network path information, data volume transferred, and port details.

Identity-indexed network analytics make it straightforward to not only determine who accessed internal resources, but to quickly identify usage patterns, trends, and spot anomalous behavior. For forensic investigations, gone are the days of piecing together time-stamped network logs and IP addresses from disparate systems to try to understand a sequence of events. Identity ties all access information together, regardless of location, device, operating system, or network.

General Product Updates

  • You can now specify ports and ranges that are allowed as part of resource definitions. Any port restrictions are checked and applied before any traffic leaves the user’s device, meaning that traffic for disallowed ports will never enter your private network.

  • We now support group sync updates for Okta, OneLogin, Google Workspace, and Azure AD. SCIM is used for updates where supported by the identity provider.

  • We’ve updated our macOS and Windows clients to make them compatible with DNSFilter. You can read more about our partnership announcement on our blog.

  • The Connector provisioning workflow has been completely overhauled, and we now have pre-configured deployment scripts for Docker, Linux (via systemd), AWS EC2, AWS AMI, K8s (via Helm Chart), and Azure (via ContainerInstance).

  • ChromeOS is now an officially supported platform for Twingate clients, starting with Android/ChromeOS 1.0.5.

Minor Fixes and Improvements


  • Added correct handling of CNAME chains on bypass (non-protected) traffic.

  • Added “Start on Login” support in macOS 1.0.5.

  • Added native Apple M1 support in macOS 1.0.5.

  • Addresses performance improvements for any traffic that tends to send small packets (eg. SSH).

  • Added ability for the macOS client to have its Twingate network name pre-configured via plist, which is useful for MDM/EMM deployments.

  • Added ICMP proxy support so that ping requests are correctly handled via both bypass and protected routes.


  • Reduced overall Connector memory usage.