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.

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 managing 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.“

What types of customer data does Twingate DNS Filtering process?

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.

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.

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.