Twingate now gives users the option to route all of their traffic through an Exit Network. When using an Exit Network, your end users' traffic is fully encrypted and sent through Connectors that you've deployed in that Exit Network. Just like a full tunnel, Exit Networks can provide extra security while traveling or when connecting to unfamiliar networks like the Wi-Fi network of a coffee shop or hotel.

Exit Networks are now available for Enterprise plans. Reach out to your account manager to enable them. To learn more, read our documentation.

Twingate now integrates with 1Password Device Trust. You can now use 1Password as a verification method when creating Trusted Profiles in Twingate. This ensures that only trusted devices are accessing protected Resources, allowing for stronger device security, even in BYOD environments.

The integration automatically syncs device verification status every five minutes for Windows, macOS, and Linux devices. You can monitor device compliance status directly in the Twingate Admin Console.

For more information, see our documentation.

The Access Graph provides you with a graphical view of the permissions for a given user or Resource, displaying details on how access is being granted as well as the policies being applied. This makes it easier to troubleshoot permissioning issues while also identifying potential opportunities to achieve least privilege access by trimming unused paths.

To learn more, read our documentation.

DNS Filtering dashboards now display additional information, including the top block reasons and the top queried and blocked domains. These analytics show high-level summaries of DNS filtering activity and give admins more insight into the network activity happening in their organizations.

To learn more, read our documentation.

Twingate now supports multiple profiles for DNS filtering. A DNS filtering profile is a set of DNS filtering rules that can be assigned to one or more Groups. This update allows DNS filtering to accommodate for the different requirements of users in different Groups.

To learn more, read our documentation.

Twingate now shows a block page when a site is blocked by DNS filtering. This page makes it easier for users to understand why a specific domain was blocked by identifying the reason for the block.

To learn more, read our documentation.

We’ve added a widget on the Admin Console that displays the next steps we recommend to fully configure Twingate for your network.

We've added CloudFormation to our Connector deployment options. You can now easily deploy a Twingate Connector into your AWS environment with a native CloudFormation template.

With just a few clicks, you can easily provide granular access controls for your VPC without needing to touch the command line or fiddle with AWS.

For more information, see our documentation.

We're continuing to invest in developer tooling and are excited to announce official support for Pulumi and OpenTofu.

Twingate now has an official Pulumi provider. Our Pulumi provider has the same functionality as our Terraform provider and will be kept up to date with Terraform.

Twingate now officially supports OpenTofu starting with v3.0.4 of our Terraform provider.

We’ve extended our AWS S3 integration to support sending DNS Filtering logs to an AWS S3 bucket. When configured, your DNS filtering logs will be sent in JSON format to your selected S3 bucket every 5 minutes. This allows you to further process and analyze DNS filtering traffic, including by forwarding the data to your SIEM of choice.

For more information, see our documentation.

Version 0.10.0 of the Twingate Kubernetes Operator is now available.

We've added the ability to expose Kubernetes Service objects as Twingate Resources by annotating them instead of manually creating a TwingateResource. Additionally, you can now import Twingate Resources by their ID, making it easier to manage Twingate Resources created outside of the operator.

View the release or read our guide to deploying a Connector using the operator.

We've updated the logic used to route traffic from user devices to Resources. Now, we attempt to prioritize connecting to the closest Connectors geographically, reducing latency when Resources have been replicated across multiple locations and geographies. We've improved this routing in the backend, so no action is required by you to take advantage of this change, other than ensuring that your Connectors are up to date.

For more information on Connectors, see our documentation.

Admins can now enable DNS filtering for specific Groups. By enrolling specific Groups, admins can progressively roll out DNS filtering to their organization.

For more information, read our documentation.

We’ve extended our usage-based auto-lock feature so that users who attempt to access locked Resources can now request and obtain access directly through Twingate. This makes it easier and faster for them to get back to their work. Incoming access requests can be reviewed either in Twingate or in other channels via a webhook that allows admins to integrate these requests into the workflows that work best for them.

For more information, see our documentation.

Managed Service Providers (MSPs) can now delete Customer Networks through the MSP Portal. This allows MSPs to better manage their customers’ Twingate deployments and subscriptions. This additional self-serve capability makes it easier than ever to let customers try Twingate, while also simplifying the off-boarding process to just a few clicks.

For more information, see our documentation.

Version 0.7.0 of the Twingate Kubernetes Operator is now available.

We refactored the TwingateConnector reconciliation process to make podExtra and containerExtra mutable, enabled customer pod annotations on podAnnotation, allowed defining extra pod environment variables in containerExtra, and added extra validation when using imagePolicy with the google provider. Additionally,TwingateResourceAccess has been updated to allow referencing the principal (Group\ServiceAccount) by name.

View the release or read our guide to deploying a Connector using the operator.

We’ve extended our AWS S3 integration to support sending Network Events to an AWS S3 bucket. When configured, your Network Events will be sent in JSON format to your selected S3 bucket every 5 minutes. This allows you to further manage and analyze your traffic, including by forwarding the data to your SIEM of choice.

For more information, see our documentation.

You can now configure Clients to use Internet Security features, including DNS filtering, even when users are signed out. This lets you constantly enforce Internet Security features when the Client is running. Enable this by generating a Machine Key and distributing it to your devices running the Client.

For more information, read our documentation.

We’ve extended our CrowdStrike integration to support Linux devices. You can now configure Twingate Security Policies to prevent Linux devices from signing into Twingate or accessing protected Resources unless they are managed by CrowdStrike Falcon. This lets you combine CrowdStrike’s device controls and management with Twingate’s granular access policies.

For more information see our documentation.

We’re excited to share that we now support usage-based auto-locking as part of Twingate Security Policies. You can now set a minimum time within which your users need to access a Resource to maintain their access to it. If your users exceed this minimum time, their access to the relevant Resource will be automatically locked until an admin unlocks it. This makes it easier to achieve least privilege access through automation, ensuring that only the right people are accessing your network.

For more information, see our documentation.

Version 0.2.0 of the Twingate Kubernetes Operator is now available. You can now deploy Connectors and automatically keep them up to date using the operator.

View the release or read our guide to deploying a Connector using the operator.

Twingate now provides native DNS filtering capabilities for Enterprise and Business customers. DNS filtering gives you the ability to protect all your users from a wide range of security threats. When enabled, Twingate will, by default, block access to domains known to conduct phishing, distribute malware, and more. You can also use an allowlist and blocklist for additional control over which domains are filtered.

To learn more, read our documentation on DNS filtering.

We've added a Connection History graph to our Network Overview tab. This shows the number of successful and failed connections flowing through your Network in the past 7, 30, or 90 days. This allows you to quickly see usage trends at a glance.

For more information, see our documentation.

We've updated our billing experience! License usage is now based on the total number of Users and Service Accounts in your Twingate account. At each renewal date, you’ll be automatically billed based on the licenses used at the end of the previous billing cycle. For annual subscribers, any additional users will be assessed at the end of each calendar month during your subscription and billed on the first day of the following month.

See the Billing Policy page in our docs for more info and explore the improved Billing page in the Settings tab of the Admin Console.

You can now configure Twingate to send audit logs to an AWS S3 bucket. Events will be sent in JSON format to your selected S3 bucket every 5 minutes. This allows you to then forward the data to your SIEM of choice.

For more information, see our documentation.

We now have a Kubernetes operator available in beta. The operator allows you to define and manage Twingate Resources and access authorizations directly from your Kubernetes deployment, ensuring that configuration and access to your cluster are maintained in the same place. The beta operator currently supports Resource creation and access assignments. Connector deployment (including automatic Connector updates) and service annotations will be available soon.

For more information, see the Github project page.

We now support disconnecting a configured identity provider from your Twingate account. This is useful if you need to change the identity provider you use with Twingate. For example, if your organization needs to switch its identity provider from Google Workspace to Okta, you can now disconnect Google Workspace from your Twingate account. This lets you connect Okta and sync its users and groups with Twingate.

For more information, see our documentation.

We've improved our Network page by adding an Overview tab that provides a snapshot of your current Network, showing key high level information and recent activity. This allows admins to quickly understand usage and easily drill down for more details.

We’ve updated the Billing page in the Admin Console to show details about your license usage. You can now view the number of users and service accounts, and current and upcoming license counts on the Billing page so you can easily make adjustments as needed.

Additionally, you’ll see a callout if your bill is expected to increase when we update our billing model on December 1, 2023. On the date, we’ll be changing the way we calculate your license usage to make it easier to understand and manage. Your license usage will now be the total number of users and service accounts in your Twingate account.

For more information, see our documentation.

We’re excited to announce improvements to our Google Workspace integration. Twingate admins can now enable Selective Sync for Google Workspace to sync only a subset of Google Workspace users with Twingate. For example, you can choose to sync only your DevOps and Engineering groups and their users instead of syncing every single user and group in Google Workspace.

For more information, see our guide to setting up Selective Sync.

We’re excited to announce that we now support ephemeral access as part of Twingate Security Policies. You can now set an expiration time for Groups that have been granted access to Resources. Once a Group’s expiration time has elapsed, access to the relevant Resource will automatically be revoked. This makes it easier to achieve least privilege access and support “break glass” scenarios.

For more information, see our documentation.

We’ve expanded our macOS device posture check capabilities. You can now require macOS devices to have a firewall enabled before they are able to access protected Resources. Additionally, you can require hard drive encryption for users of our new standalone macOS Client. These measures allow you to improve security by allowing only devices that have met these device posture checks to join your network or access particular Resources. Learn more

We're excited to announce that it's now possible to download the Twingate macOS Client without needing to use the Mac App Store. This change makes it easier to install the Client if you don't have an Apple ID and provides more control when rolling out the Twingate Client using MDM.

Since the standalone Client is distributed outside of the App Store, it relies on a system extension for networking. Learn more

The standalone macOS Client can be be downloaded from the Client changelog under the latest macOS changelog.

Resource Policies are changing to being directly associated with Resources instead of Groups. This matches how admins today view Resources and the Policies that need to be met in order to allow access to those Resources. We are also continuing to support the ability for a specific Policy to be applied to a specific Group that needs to access a specific Resource.

For more information, see our documentation.

If a device has not been used to sign in or access a Resource for 90 consecutive days, it will now be automatically archived. Archival of a device will not block users from signing in or accessing Resources with that device, but users will need to re-authenticate if using the device.

Archived devices can be manually unarchived in the Admin Console or through the API, and will be automatically unarchived when they are used to successfully sign in.

For more information, see our documentation.

Devices can now be verified by uploading a list of serial numbers. This allows customers who are not using our device security integrations to bulk verify devices without requiring those devices to sign into Twingate first. This makes device management easier when onboarding users onto Twingate, hiring multiple employees, or upgrading multiple devices.

For more information, see our documentation.

We've extended our two-factor authentication (2FA) capabilities so that you can now register and sign in via biometrics on mobile devices. This makes it easier and more secure for your team members to meet 2FA requirements configured across Twingate. Team members need to be using the latest version of a mobile Client to register and use biometrics.

For more information, see our documentation.

Clients now allow Resources to be favorited. Favorited Resources are placed in their own easy-to-access section of the Client, giving users an easier way to find their most frequently used Resources.

We've extended our two-factor authentication capabilities so that you can now authenticate into the Admin Console via biometrics or a security key. By bringing our WebAuthn offerings to the Admin Console, admins can now use more secure and easier methods to log in to and manage Twingate.

For more information, see our documentation.

We've added the ability to add aliases to Resources. Aliases let your users access Resources using an alternate address. For example, a server with the IP address 10.0.0.10 could be aliased to myserver.internal with zero configuration outside of Twingate.

For more information, including required Connector and Client versions, see our documentation.

Twingate now allows users to be automatically added or synced from a linked identity provider’s user directory, while also allowing users who use social logins (e.g. Google or LinkedIn) to be manually added by an admin. This can be useful if you need to provide access to external parties like contractors who don’t have accounts that are managed through your identity provider. Previously, admins were limited to adding users from either an identity provider or a social login provider, but not both at the same time. 

To enable this functionality for your Twingate account, please contact Twingate support.

For more information on our supported identity providers, see our documentation.

Our Device Security integrations now include Kandji!

You can now configure Twingate Security Policies so that only Kandji-verified devices can sign into Twingate or access protected Resources.

This means organizations using Kandji can opt not to use manual device verification and choose to identify company-managed devices through Kandji instead.

For more information, see our documentation.

Twingate has expanded its native two-factor authentication capabilities. Twingate now supports authentication with WebAuthn using biometrics and security keys, in addition to our existing time-based one-time password authentication option. Authenticating via methods such as Touch ID or YubiKeys are more secure as they provide device-based two-factor authentication while also offering more ease of use. Users will now be given the option to configure biometrics or security keys for authentication, allowing these methods to be used to meet Twingate’s native two-factor authentication requirements.

For more information, see our documentation.

We’ve expanded our Device Security integrations to now include SentinelOne.

Twingate Security Policies can now be configured so that only SentinelOne-compliant devices can sign into Twingate or access protected Resources.

This means SentinelOne users can bypass manual device verification and opt to identify company-managed devices through SentinelOne instead.

For more information, see our documentation.

Twingate admins can now archive and block devices.

Old or decommissioned devices can be archived and hidden from the Admin Console.

Lost devices can be blocked so that they can no longer authenticate with or access Twingate.

For more information, see our documentation.

Twingate admins are now able to hide specific Resources from the main list of Resources displayed in end user Clients. Marking a Resource as hidden will move it into a “Background Resources” sub-menu in the Client. Additionally, admins can now disable the “Open in Browser” shortcut for Resources that aren’t intended to be opened directly from the Client or that don’t open in a web browser.

For more information, see our documentation

Client requirements

• macOS 1.0.25 or newer

• Windows 1.0.23 or newer

• iOS 1.0.25 or newer

• Android 1.0.23 or newer

• Linux 1.0.74 or newer

Protocol restrictions that apply to Resources are now displayed wherever Resources appear in the Admin Console. This allows you to quickly see if a Resource is allowed, restricted, or blocked from using TCP, UDP, or ICMP.

We’ve revamped the Team page in the Admin Console. With this update, you can now search, sort, and filter users, groups, and service accounts. This lets you easily find users and identify their access rights at a glance, or search for a group to quickly determine its resource policy. Scrolling endlessly to find a user is now a thing of the past!

We’re excited to announce that we’ve expanded our Device Security capabilities with a new integration with Microsoft Intune. You can now configure Twingate Security Policies so that only Intune-compliant devices can be used to sign into Twingate or access protected Resources. This removes the burden of manual device verification by automatically identifying company-managed endpoints.

For more information, see our documentation.

We’ve updated our self-serve billing functionality to allow you to manage your plan within the Admin Console. Admins will now be able to modify billing plan and frequency from the Billing page.

For more information, see our documentation.

Twingate now integrates with NextDNS, a leading DNS filtering service that protects users from a wide range of internet security threats. NextDNS can be enabled directly from the Twingate Admin Console, allowing admins to extend DNS security protections to all Twingate users on desktop platforms. No additional app installation or network configuration is required beyond enabling NextDNS in Twingate. Profiles that are configured in NextDNS, which allow sets of different DNS security settings to be defined, can be selected directly within the Twingate Admin Console.

For more information, see our documentation.

We’re happy to share that our Device Security capabilities now support an integration with Jamf. Admins can configure Twingate Security Policies so that only devices managed in your Jamf tenant can be used to sign in to Twingate or access protected resources. This allows you to define what it means to be a Trusted Device using your existing Jamf deployment, bridging your device source of truth and network access management policies.

For more information see our documentation.

We’ve updated our Admin Console so you can see which devices across your team are currently connected to Twingate. Device connectivity can now be seen across Device and User pages and the total count of currently connected devices is visible on the Devices page. Now, you can more easily monitor active devices, troubleshoot issues, and identify realtime Twingate usage throughout your company.

We’ve added new functionality to the Twingate Client to display a Resource’s authentication state. This change gives your users insight into what they can access at any given time. For each Resource, users can now see whether they are currently authenticated and how much time is left before they need to authenticate again. Users can also manually authenticate before accessing a Resource, giving them more control over how authentication fits into their workflow.

Client requirements

• macOS 1.0.23 or newer

• Windows 1.0.21 or newer

• iOS 1.0.23 or newer

• Android 1.0.21 or newer

• Linux support will be available in a future release

Our latest Linux Client (1.0.68) now supports ARM64 architecture, which means that the Client can now run on endpoints such as newer Raspberry Pi and other IoT devices. Virtualized Linux environments running on ARM-based Apple Silicon devices are also now supported. Combined with running the Linux Client in headless mode using our Service functionality, this enables Twingate to be used across a broader range of use cases and devices within your network.

For more information, see our documentation.

We’ve enabled network events in the admin console, bringing details about network traffic to the individual user and resource pages. You can now navigate within the admin console to see details about recent network traffic associated with a team member or protected resource. This enables you to easily understand who’s accessing what across Twingate and investigate or troubleshoot issues directly from the admin console.

For more information see our documentation.

We’ve added new reporting functionality to the admin console: now you can export a list of active users on Twingate and their last access time. This allows you to easily see who’s recently been using Twingate, which can help with auditing, tracking, and monitoring.

For more information, see our documentation.

We’re pleased to announce Twingate’s first capability to protect user privacy and improve security posture on any network by automatically encrypting DNS traffic. Despite advancements to protect DNS such as DNSSEC, the vast majority of DNS requests are still both unencrypted and unvalidated, and hence vulnerable to a range of exploits from data collection to DNS poisoning and phishing.

A solution to the problem of unencrypted DNS traffic already exists in the form of DNS-over-HTTPS (DoH), which simply encapsulates standard DNS requests into HTTPS requests, hiding the contents of the requests from third parties. The Twingate Client’s transparent DNS proxy not only enables configurationless private DNS resolution, but it also allows us to offer automatic DoH protection for the entire operating system. Any DNS request on a user’s device, both foreground and background, will be encrypted, regardless of the application, and automatically forwarded to a trusted DoH resolver.

Enabling DoH for your users in Twingate is very simple. Simply turn on DoH in the “DNS Security” section in your Admin Console Settings page, and any macOS, Windows, or Linux users will automatically have DoH protection enabled. Select from a number of trusted DoH resolvers, or use the custom resolver option to use your existing DoH provider, which can also be used to enable DNS filtering for all Twingate users automatically.

We’re excited to announce that we’ve extended our Device Security capabilities to integrate with CrowdStrike. You can now configure your Twingate Security Policies so that only devices managed in your CrowdStrike Falcon platform can be used to sign in to Twingate or access protected resources. This enables you to layer on the best of CrowdStrike’s device controls and management with Twingate’s granular access policies.

For more information see our documentation.

We’ve added new admin roles to our Twingate Admin Console, enabling restricted access for DevOps and Support team members. With the new admin roles, DevOps team members can set up and modify Resources, Remote Networks, and Connectors while only having read access to groups, policies, etc. Support team members will only have read-only access to the entire admin console. This new feature allows admins to delegate admin management and support responsibilities to the right people without granting overprivileged access.

For more information see our documentation.

A new version of our Terraform Provider, v0.1.7, is now available from Terraform’s Provider Registry.

In addition to a number of bug fixes, we have made the following enhancements:

• Added support for a new twingate_group resource that allows you to both import existing and create Twingate Groups in your Terraform configuration.

• Added a new DENY_ALL shorthand port restriction when configuring a twingate_resource resource.

• Added a new GKE + Helm deployment guide to our documentation.

We’re continuing to work on a number of highly-requested enhancements to our Terraform Provider, and so expect to see another update here in the near future. The full changelog for v1.0.7 is available on Github.

We’re excited to launch Device Security, a new controls framework that allows fine-grained definition over which devices are authorized to access specific Resources. Device Security includes native device posture checks across all platforms and is integrated into Twingate’s existing Security Policies.

For more information see our blog post and documentation.

We’ve updated our public GraphQL Admin API to include all create, update, and management actions for our Service Accounts functionality. This allows Service Accounts to be created and managed programmatically as part of our commitment to automation on our platform.

We’ve updated our Resources page within the Admin Console so that admins can more easily see and manage Resources. With this overhaul, admins can now sort, search, and view more details about the Resources configured within Twingate. This makes it easy to audit and make changes, including enabling and disabling the Resource as well as adding and removing access.

JumpCloud integration

Today we’re excited to share that we now integrate with JumpCloud. Adding to our existing identity provider integrations with Azure AD, Google Workspace, Okta, and OneLogin, you can now connect Twingate to your JumpCloud account for authentication and user & group sync. This makes it easier than ever to get your team set up and deployed with Twingate.

For more information, see our documentation.

We’re excited to introduce a significant upgrade to our network infrastructure that reduces round trip latency and incorporates the latest networking standards. Clients and Connectors will now prioritize negotiating a direct peer-to-peer connection whenever possible; our Relay infrastructure remains available as a secondary data path.

This upgrade also introduces the use of QUIC at the network transport level. QUIC was designed to address the challenges of real-world internet usage by:

1. Maximizing throughput for concurrent data streams

2. Reducing connection startup time

3. Improving resilience to network changes

We are in the process of rolling out this functionality to all of our customers. If you’d like to opt in for early access, please contact your account manager. For more on how we think about Twingate’s underlying network architecture, including these most recent upgrades, see our blog post.

Client and Connector requirements

• Connector 1.31.0 or newer

• Windows 1.0.13 or newer

• macOS 1.0.16 or newer

• Linux 1.0.32 or newer

• iOS 1.0.16 or newer

• Android support will be available in the next release

Admin Actions Report

Today we’ve expanded our reporting capabilities. Adding to our previous analytics on network traffic, we now offer Business and Enterprise admins the option to export reports on admin actions. This gives insight into what’s being created, deleted or edited across Remote Networks, Connectors, Users and Groups, Service Accounts, and more. It’s now easier than ever to keep track of what changes and updates are being made across your Twingate network.

For more information, see our documentation.

We’ve added email notifications for Connector availability status changes, making it easier for admins to be aware of and troubleshoot access issues. With this feature, admins will receive emails if Connectors go offline and also when they come back online. Admins have the option to mute status emails if these availability status changes are expected behavior.

For more information, see our documentation.

We’ve revamped and optimized our Devices page within the Admin Console. With this overhaul, we’ve improved the performance of the Devices page so admins can quickly see their organization’s details. This makes it easy to view which devices have been used to access Twingate, ensure they’re up to date, and manage Trusted Devices.

For more detailed information, see our documentation.

Platform Requirements and Trusted Devices in Resource Policies

We’ve extended Resource Policies so that they now support Device Requirements. In addition to the previous options on Sign-In Policy and Authentication Requirements, Resource Policies now support setting requirements on the operating system and Trusted Device state. With this update, Resources can be configured so that they can only be accessed via devices marked as Trusted Devices or running specific platforms.

For more information, see our documentation.

Today we’re excited to share three updates to our Google Workspace integration. These changes make our integration more fully featured and performant so that you can get your team organized and configured within Twingate. The three major updates are support for Organizational Units, use of webhooks to sync changes, and support for multiple Google Workspace domains. For more detailed information, see our documentation.

Google Organizational Unit sync

Twingate’s Google Workspace integration now supports syncing Organizational Units (OUs) and Google Groups. Customers using Google Workspace as their identity provider will have the option to sync either or both OUs and Groups as Twingate groups, which can then be granted access to specific resources. This makes it easier than ever to seamlessly integrate existing user management architecture into Twingate.

Google Workspace webhooks

We also updated how we sync users via our Google Workspace integration. By using webhook-based triggers to identify changes, Twingate is now able to reflect updates even faster, significantly reducing sync times. With this, you’ll be able to easily get your team set up and stay up to date within Twingate.

Multiple Google Workspace domains

Customers using Google Workspace as an identity provider will now also be able to sync multiple domains from a single Google Workspace account (secondary domains within Google Workspace). This ensures that users from these different domains will be able to authenticate, sync changes, and be given access to resources as needed.

Now updated: MacOS pre-configuration updates

We’ve expanded support for pre-configuration of the MacOS Twingate client via Apple property list files (.plist). The first change is that the client can be pre-configured to start at login via a setting in the .plist. The second update is that the client can now read .plist files from /Library/Managed Preferences/ in addition to the previously supported /Library/Preferences/. This makes it easier to deploy and manage Twingate across your organization’s devices. These two updates are now live in our latest version of the MacOS client (1.0.16), available in the Mac App Store.

For more information, see our documentation.

Now available: Service accounts

We’ve expanded support for CI/CD pipeline integration and automated processes by adding service accounts to Twingate. Services can be created in the Admin console and access can be provided to any existing resources. Service keys assigned to a service are used to authorize access using the new headless mode available in our Windows and Linux clients. Upgrading connectors to 1.0.30 or later is required to enable service access to resources.

For more information, see our product announcement and documentation.

Minor Fixes and Improvements

Clients

• Linux 1.0.21 and Windows 1.0.11 Clients now support service accounts with headless modes.

Admin Console

• The Google Workspace integration now supports webhook-based triggers for user changes.

• Connectors are now given random names, and connector names can be edited after creation.

• The admin user who created a given Admin API key is now visible in the admin console.

• Resources can now be edited directly from the resource list view in the Network page.

Admin API

• Added support for devices into the Admin API, including updating device trusted status.

Connector Real-time Connection Logs

We’ve added real-time network logging to the Connector to enable feeding this information directly into a SIEM system. Logs are output in JSON format and are identity-indexed, allowing you to link user identity directly to the resource that was accessed, the rule that allowed access, which device was used, and how much data was transferred. For more detailed information, please see our documentation.

Connector Metadata

We’ve augmented the Connector detail page in the Admin console to display additional information about each Connector. We now:

• Report the Connector’s current version

• Indicate if an update is available for the Connector

• Display any custom metadata

See our documentation for information on setting custom metadata. We will be continuing to enhance the Connector information we provide over the coming weeks.

Minor Fixes and Improvements

Clients

• Added NixOS distribution support in Linux 1.0.12.

• macOS and iOS Clients are now available in the corresponding French Apple App Stores.

General

• Improved the Twingate Universal 2FA experience by introducing a sliding window for code entry. This prevents user codes from being rejected just after the 2FA code transitions.

Device Details

Twingate now displays information about all of your users’ devices across all platforms. This information is exposed in both the user detail page for an individual user and in the new Devices tab in the Admin console. At a glance, you are now also able to see what devices are connected to Twingate, detailed information about devices, and whether the device is trusted. This information can also be sorted, exported, and summarized in the Devices tab.

Over time we will be expanding the range of device information that we collect, both via the Twingate client application and from 3rd party integrations with MDM and EDR products our customers already have deployed. We will also be enriching our existing identity-based network analytics information with collected device information to continue to provide our customers with the most complete picture of network activity.

Devices running Twingate Clients of the following versions or later support sending device details to Twingate:

• Windows 1.0.8

• macOS 1.0.9

• iOS 1.0.8

• Android 1.0.11

Clients running prior versions of Twingate will be shown as a generic Device without additional details or metadata. We recommend that your users update to the latest version of the Twingate Client to take advantage of this and future functionality.

Trusted Devices

The Trusted Device functionality that we’re launching today is a very first step towards building a dynamic trust status. Admins are now able to mark devices as trusted, which allows defining Security Policies that take this status into account. This policy requirement can be enforced for any device, on any platform, and in any location with nothing but the Twingate client app required.

While this trusted/untrusted status is suitable for many scenarios where access must be restricted to known devices, we see this functionality as a fundamental building block for more nuanced policies in the future. We will soon be extending this concept to make device trusted status be conditional on a number of factors, including the destination resource that is being accessed, 3rd party reporting from MDM and EDR systems, and additional context collected from the Twingate client application itself.

Minor Fixes and Improvements

Clients

• Modified the Client authentication flow so that users no longer need to click a deeplink notification to open Twingate and complete the authentication flow.

• Improved the Admin console sign-in experience by allowing login directly from twingate.com.

Today we’re proud to release Twingate Terraform Provider 0.1.0, which is available now in Terraform’s Provider Registry. Many of our customers have fully standardized on Infrastructure-as-Code processes, and we’re pleased that they can now integrate secure zero trust access into these processes automatically using our Terraform Provider.

One of the major benefits of Twingate is that it allows you to decouple planning decisions around network infrastructure from user access. By deploying Connectors in any network segment where access is needed, it’s no longer necessary to route traffic between networks to accommodate the need for access. You can focus on managing and securing your network to best practices, knowing that access can be provided anywhere it’s needed.

We’ve gotten valuable early feedback on our Provider as we were developing it, and if you have any feedback once you’ve given it a try, we’d love to hear from you, too.

We’re excited to announce Twingate Security Policies, which is a new framework to help you manage access to Resources. This will enable you to apply more granular security rules to sensitive assets. For example, you may want to require 2FA, but only for users accessing billing systems with customer financial data.

Twingate has three types of Security Policies, each of which come together to protect access to your Twingate network. 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 Groups by default. You can create additional Resource Policies in the Admin Console.

• Network Sign In: This policy is applied to all users of Twingate when they attempt to log into the network. Users must fulfill the criteria in this Policy before attempting to access any Resources, even if those Resources have more permissive Security Policies than the Network Sign In policy.

• Admin Console Sign In: This policy is only applied to Twingate administrators when they sign into the Admin Console. Admins do not need to sign into Twingate to access the Admin Console, so the Network Sign In policy is not applied here.

General Product Updates

• Twingate now has a SOC 2 Type 2 report available on request from our team.

Minor Fixes and Improvements

Clients

• Added Windows “Start on Login” support in 1.0.4.

• Added support for unqualified DNS names on macOS 1.0.7 and Windows 1.0.5.

• Fixes Sophos incompatibility issues on macOS 1.0.7.

• Added support for Arch Linux in Linux 1.0.6.

Connectors

• Improved the speed and resiliency of Connectors when switching between different Relay cluster regions.

Admin console

• Added wanrning for admins when attempting to create multiple Resources with the same address.

• Added ability to disable group sync for Google Workspace.

• Added Universal 2FA support for non-IdP configurations.

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

Clients

• 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.

Connectors

• Reduced overall Connector memory usage.