mirror of
https://github.com/fosrl/docs-v2.git
synced 2026-09-19 20:39:07 +02:00
41 lines
3.8 KiB
Plaintext
41 lines
3.8 KiB
Plaintext
---
|
|
title: "FIPS 140 and FedRAMP Considerations"
|
|
description: "How Pangolin's WireGuard-based tunnels fit into FIPS 140 and FedRAMP-governed environments."
|
|
---
|
|
|
|
<Note>
|
|
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.
|
|
</Note>
|
|
|
|
Every Pangolin tunnel - between a site connector and a node, or a client and a site - is a [WireGuard](/development/system-architecture#site-connectors) 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](/development/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](/self-host/quick-install) 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](/self-host/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](mailto:sales@pangolin.net) to discuss your requirements directly.
|
|
|
|
<CardGroup cols={2}>
|
|
<Card title="System Architecture" icon="server" href="/development/system-architecture">
|
|
Map Pangolin's components onto your system boundary.
|
|
</Card>
|
|
|
|
<Card title="Self-Host Pangolin" icon="lock" href="/self-host/quick-install">
|
|
Keep the control plane and nodes on infrastructure you already operate.
|
|
</Card>
|
|
|
|
<Card title="Enterprise Edition" icon="building" href="/self-host/enterprise-edition">
|
|
Clustering, additional identity providers, and centralized logging.
|
|
</Card>
|
|
|
|
<Card title="Zero Trust Networking" icon="shield-halved" href="/about/security/zero-trust-networking">
|
|
How Pangolin's encryption and authorization model is structured.
|
|
</Card>
|
|
</CardGroup>
|