If you are an organization that is required to comply with the PCI DSS (Payment Card Industry Data Security Standards), you may be interested in the PCI DSS compliance status of Twingate.

Organizations that need to validate compliance with the full set of PCI DSS requirements often ask if Twingate is “PCI certified” or “PCI compliant”. This question is usually premised on the assumption that if the Twingate system is part of an organization’s cardholder data environment (CDE) and is thus “in scope” for PCI DSS compliance purposes, Twingate itself needs to fully comply with PCI DSS and be validated. We do not believe this is the case.

While the Twingate product is not itself validated as PCI DSS compliant, it does not need to be in order to be usable by an organization that itself needs to comply with PCI DSS. Additionally, Twingate can be used to help an organization meet some of its PCI DSS compliance obligations, particularly in relation to securing aspects of its cardholder data environment.

To explain further, we examine two relevant areas.

1. Twingate and Cardholder Data

When Twingate is used by a user to access a resource secured by Twingate, the communications between that user’s device and the destination resource are transmitted over an end-to-end encrypted connection. In many circumstances, this connection is established on a peer-to-peer basis without the involvement of any Twingate infrastructure. However, under certain technical network conditions, Twingate Relays are required to facilitate the connection between the device and destination resource. In such cases, Relays assist in the routing of network traffic, which transits those Relays. However, due to the end-to-end encryption in place between the user device and destination resource, Relays cannot decrypt that traffic, do not store that traffic, and are not involved in processing the content of that traffic.

If an organization does not exchange any cardholder data between a user’s device and a resource secured by Twingate, Twingate will not come into contact with any cardholder data and Twingate’s relays are out of the scope of PCI DSS.

However, even if an organization expects to exchange cardholder data between a user’s device and a resource, Twingate’s role is limited to routing encrypted data that may contain cardholder data, without any ability to decrypt such data. (Note that Twingate has no way of knowing if data transiting its relays contains cardholder data because of the end-to-end encryption in place.)

This FAQ published by the PCI Security Standards Council notes that:

“a third party that receives only encrypted cardholder data for the purposes of routing to other entities, and that does not have access to the cardholder data or cryptographic keys, may not have any PCI DSS responsibility for that encrypted data. In this scenario, where the third party is not [also] providing any security services or access controls, they may be considered the same as a public or untrusted network, and it would be the responsibility of the entity(s) sending/receiving cardholder data through the third party’s network to ensure PCI DSS controls are applied to protect the data being transmitted.” (emphasis added)

The issue of Twingate acting as a third party that is providing access controls is addressed in the next section.

2. Twingate and Cardholder Data Environment Security

PCI DSS regards that any systems that are connected to an organization’s CDE or that impact the security of the CDE may be in scope for PCI DSS. If Twingate is used to provide access controls to system components that are part of an organization’s CDE, Twingate may be “in scope” for PCI DSS.

However, it is important to note that a system being “in scope” for PCI DSS compliance purposes does not necessarily mean the system itself needs to be fully “PCI DSS compliant”.

The FAQ entitled ”If an entity uses a service provider that is not PCI DSS compliant, how does this impact the entity’s compliance?”, published by the PCI Security Standards Council, explains that entities may share cardholder data or outsource elements of their CDE to a third party service provider (TPSP) and that entities must manage their TPSPs in accordance with Requirement 12.8 of the PCI DSS. The PCI Security Standard Council goes on to note that:

“Service providers do not need to be validated as PCI DSS compliant in order for the entity to meet Requirement 12.8. If, however, a service provider provides a service that is in scope for the entity’s PCI DSS requirements, then the compliance of that service will impact the entity’s compliance. For example; if an entity engages a service provider to manage their firewalls, and the service provider is not meeting the applicable requirements in PCI DSS Requirement 1, then those requirements are not in place for the merchant’s compliance.” (emphasis added)

As such, an organization’s focus should be on the scope of the TPSP’s service, what PCI DSS requirements are tied to that, and whether the service is capable of meeting those requirements. Such TPSP services may only be relevant to a limited number of PCI DSS requirements.

Twingate can act as a TPSP if Twingate is used to secure access to components of the CDE. Consequently, organizations should identify what PCI requirements they are intending to fulfill by using Twingate, and understand how Twingate accomplishes those. For example, Twingate can help customers to meet Requirement 7.3, which relates to managing access to in scope system components via an access control system.

For more information, refer to the “Use of Third-Party Service Providers” section in the PCI DSS Requirements and Testing Procedures document published by the PCI Security Standards Council.

Questions?

Please contact us for more information about Twingate and PCI DSS compliance.