Skip to main content
This page explains where Pangolin’s encryption stands relative to FIPS 140 and FedRAMP requirements. It is not compliance or legal advice - work with your ISSO or compliance team to determine what applies to your specific system boundary.
Every Pangolin tunnel - between a site connector and a node, or a client and a site - is a WireGuard connection. WireGuard uses a fixed, modern cryptographic suite: Curve25519 for key exchange, ChaCha20-Poly1305 for encryption, and BLAKE2s for hashing. This cryptography is well-reviewed and considered strong, but “strong” and “FIPS 140-validated” are different things - validation refers specifically to a cryptographic module having gone through NIST’s Cryptographic Module Validation Program (CMVP), and WireGuard’s implementation has not gone through that process. As of this writing, Pangolin does not use a FIPS-validated module for its tunnel encryption.

​
Where Pangolin can fit in a FedRAMP boundary

Not using a FIPS-validated module for the tunnel itself doesn’t automatically disqualify Pangolin from a FedRAMP-authorized environment but it changes how you scope it:
  • Layer it, don’t rely on it alone. If your system already terminates FIPS-validated TLS or IPsec at its authorization boundary, a Pangolin tunnel can run as an additional encrypted layer inside or alongside that connection rather than being the control that has to satisfy FIPS validation on its own. FedRAMP guidance generally permits non-validated encryption in an inner layer when an outer layer already satisfies the relevant controls (commonly referenced as SC-8(1) and SC-28(1) for transmission and data-at-rest confidentiality).
  • Decide where the boundary sits. Work with your ISSO to determine, per NIST SP 800-18 and the impact categorization in FIPS 199, whether Pangolin operates inside your system’s authorization boundary as a component, or outside it as a supporting service that carries traffic but isn’t part of the accredited system itself.
  • Treat it as a component, not the system of record. Pangolin’s system architecture - control plane, nodes, connectors, and clients - is documented specifically so it can be mapped cleanly onto a system boundary diagram during this evaluation.

​
Reducing what’s outside your control

If keeping infrastructure inside an already-accredited boundary matters more than convenience, self-hosting is the relevant lever: the control plane and every node can run entirely on infrastructure you already operate and have assessed, rather than depending on Pangolin Cloud’s shared infrastructure. Enterprise Edition extends this with clustering, additional identity providers, and centralized logging for environments that need tighter operational control. If your organization needs a compliance package beyond what’s documented here, contact sales to discuss your requirements directly.

System Architecture

Map Pangolin’s components onto your system boundary.

Self-Host Pangolin

Keep the control plane and nodes on infrastructure you already operate.

Enterprise Edition

Clustering, additional identity providers, and centralized logging.

Zero Trust Networking

How Pangolin’s encryption and authorization model is structured.