References in this document to FIPS 140 are to both FIPS 140-2 and FIPS 140-3.

Although Twingate is not FIPS 140 validated, nor does it currently have the ability to exclusively use cryptographic modules that are FIPS 140 validated, from a FIPS 140 compliance perspective, using Twingate does not compromise the integrity of a customer’s end-to-end communications, including where the endpoints are using FIPS-validated cryptography modules to encrypt those communications.

This means that using Twingate does not impact the ability of customer devices to continue communicating with each other using FIPS-validated cryptography modules.

For example, if a customer end user’s device uses an application that is FIPS 140 compliant (i.e. it uses cryptographic modules that are FIPS 140 validated) to communicate with a customer resource that is also FIPS compliant (e.g. they may communicate over an end-to-end TLS connection that is established using a FIPS 140-validated OpenSSL library), then the presence of Twingate in facilitating the authorization and routing of that connection does not disturb the FIPS compliance status of the customer’s underlying end-to-end communication.

Twingate encapsulates those underlying communications at the transport layer using an implementation which does not currently use FIPS-validated cryptographic modules, but Twingate does not and cannot decrypt any payloads (in the example above, this is the underlying TLS-encrypted data), thereby preserving the security and any FIPS 140 compliance status of those communications.

Therefore, if encrypted communications between devices without the involvement of Twingate are conducted with FIPS 140-validated cryptography, the addition of Twingate into the equation does not impact that arrangement, such that Twingate is considered compatible with those communications from a FIPS 140 perspective.

Note that one reason Twingate does not, by default, use FIPS-validated cryptography modules is because the FIPS validation process is lengthy. This means that more recent versions of cryptographic modules that incorporate security and bug fixes may be available that haven’t had time to complete validation. While these more recent versions are not validated, this does not necessarily mean they are less secure (in fact, the converse is arguably true).

FedRAMP & FIPS 140

Cloud services providers (CSPs) who need to obtain or maintain FedRAMP authorization do not necessarily need to use vendors that are themselves FedRAMP authorized, or use vendors that exclusively implement FIPS 140 validated cryptographic modules. This is true even though FIPS 140 compliance is a component of FedRAMP compliance.

FedRAMP-authorized CSPs should evaluate how they will use a vendor’s technology in connection with the FedRAMP-authorized cloud service they provide in order to determine the exact nature of any FedRAMP and FIPS 140 requirements they may need to pass on to that vendor.

With respect to Twingate, we are happy to provide more information about how our services work in order to help FedRAMP CSPs evaluate what FedRAMP requirements, if any, it needs Twingate to help implement.