Last updated April 3, 2024

This document is intended for privacy, legal, and security professionals who want to understand what customer data Twingate collects and what Twingate does with that data.

Twingate Private Access

How Twingate Private Access works

Twingate is a secure remote access solution for businesses. When an end user wishes to access a resource that is protected by Twingate (e.g. a corporate server or application), Twingate authenticates that user’s identity, and then checks if the user is authorized to access that resource based on factors such as the user’s assigned permissions, device posture, and any other security policies and requirements defined by the customer via Twingate’s web-based admin console or the Twingate API. End users need to install the Twingate Client on their device in order to access resources protected by Twingate.

If a connection is authorized, Twingate will facilitate the establishment of an end-to-end encrypted connection between the end user’s device and the destination resource. Similar to how a post office handles sealed postal mail, Twingate does not store or inspect the contents of the data flowing over that connection – Twingate only assists with routing it efficiently across the internet (via use of a Twingate Relay) to its destination.

The diagram below represents Twingate’s architecture. Controllers, Relays, and the Admin Console are components operated by Twingate in the cloud. Clients, Resources, and Connectors are components that are operated and controlled by the customer within their infrastructure.

What types of customer data does Twingate Private Access process?

There are 3 categories of customer data handled by Twingate:

1. Services Data

Description: This is data sent via the “control plane” and generally includes information that is accessed through the Admin Console. For example, user details (names and email addresses), user groups, resource definitions, remote network names, security policies, network logs, access tokens, and other configuration information. We do not store user passwords, since user authentication is handled by identity providers with whom we integrate (e.g. Okta, OneLogin, social logins). Services data includes information sent to Twingate by customers as part of support requests.

The control plane is responsible for coordinating authentication and authorization, so data relating to those processes belongs to this category of data.

Storage: Services data is stored on Twingate’s Controller infrastructure, which is located on servers in the United States (some of which are provided by vendors such as Google Cloud). This data is mirrored in multiple locations for resiliency and backup purposes.

Use: We use this data to provide, maintain, support and improve our services. For example, we may need to access this data to troubleshoot a support request, and in addressing that request we may make changes to our services that improve its reliability or performance.

2. Content Data

Description: This is data sent via the “data plane.” It consists of the actual content data (payloads) that is communicated between Clients and destination Resources (e.g. files, media, commands). Content data is sent over an end-to-end encrypted connection to protect the data from unintended third parties (including Twingate) as it transits the internet. Twingate Relays help to broker peer-to-peer connections between Clients and destination Resources.

Under certain technical conditions, a peer-to-peer connection may not be able to be established, and a Relay is additionally used to facilitate the efficient routing of network traffic, essentially making the Relay one of the multiple intermediate devices (“hops”) that content data passes through as it transits the internet. Similar to all those other intermediate devices, Relays do not have visibility into the encrypted content data that passes through it.

Storage: Content data is not stored by Twingate. Relays do not store any traffic or network-identifiable information, and we do not have visibility into the unencrypted contents of that data (due to the end-to-end encryption). No data-carrying connections are terminated at a Relay.

Use: We do not use content data. Similar to a post office, a Relay helps to efficiently route content to its destination. Unlike a post office, the data we route is encrypted, so we are not able to read that data even if we “opened the envelope,” so to speak.

3. Usage Data

Description: This is data derived from the operation and support of our services, such as statistical and diagnostic data about the configuration, use and performance of the services. Examples include application crash reports, user interactions with user interfaces, bandwidth use, and application telemetry. This category of data overlaps with services data, but we define this as a separate category due to the additional uses we make of this data (see below).

Storage: This data is generally stored in the same locations as services data.

Use: We use this data to provide, maintain, support, and improve our services. We may also publish this data to the extent that it does not contain customer confidential information, or if it has been anonymized and de-identified. For example, we may publish useful or interesting information for customers such as “X% of customers have users who work from more than Y locations.” or “The average Twingate user has X.X devices that they use to access corporate resources, and of those devices Y% are mobile.“

Twingate DNS Filtering

How Twingate DNS Filtering works

Twingate DNS Filtering gives organizations the ability to control what websites their users can access. By default, DNS Filtering will automatically protect users from a wide range of potential security threats, blocking sites known to host phishing, distribute malware, and more. Additionally, DNS Filtering can be used to restrict what kinds of content users can access, restricting access to things ranging from unauthorized SaaS apps to websites not appropriate for work.

What types of customer data does Twingate DNS Filtering process?

Data Processed: DNS Filtering, when enabled by an administrator, collects and logs the domain names that users attempt to access on their devices (including the time of access, the user’s identity, and details about the user’s device). This data is only collected from users who are running the Twingate Client and who are not excluded from having DNS filtering applied to them by an administrator.

Storage: DNS Filtering log files are stored on Twingate’s infrastructure, which is located on servers in the United States (some of which are provided by vendors such as Google Cloud).

Use: We only use this data to provide, maintain, support, and improve our service. For example, we may need to access this data to troubleshoot a support request, and in addressing that request we may make changes to the service that improves its accuracy, reliability, or performance.

Twingate Agentless Beta

How Twingate Agentless Beta works

Twingate Agentless Beta (“Agentless”) is a service that allows users to access private resources through a controlled, secure environment, without requiring users to install a software agent on their devices. Users use a web browser on their own device to access a remote computer, which is served by an “agent server” that is hosted within the customer’s infrastructure environment or by Kasm (an independent, third party partner of Twingate). Users send inputs (e.g. mouse and keyboard commands) to the remote computer, which processes such inputs and sends a stream of audio and video back to the user’s local device. A Twingate Client is installed on the remote computer to allow it to access private resources secured by Twingate’s Private Access product. The remote computer can also be configured by a customer to provide data loss prevention functionality, such as disabling copying text to clipboards.

The administration and configuration of remote computers is conducted through an administrative console hosted by Twingate. The administrative console and associated components that orchestrate the administration of this service are referred to as the control plane.

What types of customer data does Twingate Agentless Beta process?

There are 3 categories of customer data handled by Twingate in relation to Agentless:

1. Services Data

Description: This is data processed by the “control plane” and generally includes information that is accessed through the Admin Console. For example, user email addresses, client IP addresses, session timestamps and durations, user security profiles, and configuration information such as data loss prevention settings. We do not store user passwords, since user authentication is handled by identity providers with whom we integrate (e.g. Okta, OneLogin, social logins). The control plane is responsible for coordinating authentication and authorization, so data relating to those processes belongs to this category of data. Services data includes information sent to Twingate by customers as part of support requests.

Storage: Services data is stored on Twingate infrastructure, which is located on servers in the United States (some of which are provided by vendors such as Google Cloud). This data is mirrored in multiple locations for resiliency and backup purposes.

Use: We only use this data to provide, maintain, support, and improve our service. For example, we may need to access this data to troubleshoot a support request, and in addressing that request we may make changes to the service that improves its accuracy, reliability, or performance.

2. Content Data

Description: This data consists of the end user activity occurring on agent servers. Twingate infrastructure does not come into contact with this data except in one potential case.

The video and audio stream of what is occurring on the agent server (“stream data”) may be proxied through Twingate’s control plane before being sent through to the end user. This is done for technical reasons and Twingate does not do anything with stream data other than to pass it on to the end user’s device. This proxying function can be bypassed by enabling “Direct to Agent” functionality (contact Twingate Support to learn how). In the future, Twingate is planning to release “peer to peer” connectivity that will provide another option for allowing agent servers to send stream data directly to end user devices without transiting Twingate infrastructure.

Note that if session recording is explicitly enabled by a customer administrator (this feature is not currently available but is coming soon), those recordings are sent to a customer-designated storage location and are not stored by Twingate infrastructure.

Storage: Content data is not stored by Twingate.

Use: We do not use content data for any purpose, other than as described above.

3. Usage Data

Refer to the “Usage Data” section of the Twingate Private Access section above for more information about Usage Data.

Where is Twingate’s workforce located?

Twingate is based in the United States with a subsidiary in Israel that focuses on development. Like virtually all technology companies, we work with a variety of vendors and contractors in different locations who help us to provide our services. To help ensure that all customer data handled by them is handled appropriately and in accordance with our obligations to customers, we conduct due diligence and impose relevant contractual requirements on them.