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

In the section entitled “Encrypted Cardholder Data and Impact to PCI DSS Scope for Third-Party Service Providers” of PCI DSS v4.0.1 (page 15), the standard states that:

“a TPSP [third-party service provider] 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 TPSP 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 TPSP’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”.

In the section entitled “Using TPSPs and the Impact on Customers Meeting PCI DSS Requirement 12.8” of PCI DSS v4.0.1 (page 16), the standard states that:

“Requirement 12.8 does not specify that the customer’s TPSPs [third-party service providers] must be PCI DSS compliant, only that the customer monitors their compliance status as specified in the requirement. Therefore, a TPSP does not need to be PCI DSS compliant for its customer to meet Requirement 12.8.” (emphasis added)

The FAQ entitled ”How is an entity’s PCI DSS compliance impacted by using third-party service providers (TPSPs)? ”, 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:

”Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that the customer monitors their compliance status as specified in the requirement. Therefore, TPSPs do not need to be validated as PCI DSS compliant for the customer to meet Requirement 12.8. However, if a TPSP provides a service that meets a PCI DSS requirement(s) on behalf of the customer, then those requirements are in scope for the customer’s assessment and the TPSP’s compliance of that service will impact the customer’s compliance. For example, if a customer engages a TPSP to manage their network security controls, and the TPSP does not provide evidence that it meets the applicable PCI DSS requirements in PCI DSS Requirement 1, then those requirements are not in place for the customer’s assessment. As another example, TPSPs that store cardholder data on behalf of customers need to meet the applicable requirements related to access controls, physical security etc., for their customers to consider those requirements in place for their assessments.” (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.