Compliance
Which NIST 800-171 controls GossipSeal implements, which it helps with, which are yours, and how far the FIPS build goes. Nothing here is a certification: CMMC certifies the contractor, not the software. What a vendor can honestly give you is a product that makes the controls easier and an exact statement of which ones it touches.
The one structural fact
GossipSeal runs on your server. Files are sealed on the user's machine before upload; the server stores ciphertext and locked key envelopes; Gossip Apps never receives or can read your data. So the data boundary is your boundary: no cloud provider holds your CUI, ITAR technical data, or PHI, there is no FedRAMP question because there is no vendor cloud in the path, and a stolen disk or backup is ciphertext.
NIST SP 800-171 Rev 2 (CMMC 2.0 Level 2)
| Family | Control | Status | How |
|---|---|---|---|
| 3.1 Access Control | 3.1.1 Limit access to authorized users | Supports | Unique accounts; invite, disable, remove; SCIM 2.0 deprovisioning from your identity provider. |
| 3.1 Access Control | 3.1.2 Limit access to permitted functions | Supports | Admin and member roles; a user can only open files sealed to their own identity. |
| 3.1 Access Control | 3.1.3 Control the flow of CUI | Supports | Sharing is to named identities. Public links can be forbidden by policy or capped by expiry. |
| 3.1 Access Control | 3.1.11 Terminate sessions | Supports | Hashed bearer tokens with a server-enforced lifetime. |
| 3.1 Access Control | 3.1.22 Control publicly posted CUI | Supports | Nothing is public unless policy allows a link, and links expire. |
| 3.3 Audit | 3.3.1 / 3.3.2 Audit records traceable to users | Supports | Server-side audit log of sign-ins, uploads, shares, admin changes, license and recovery events, each with the acting user. |
| 3.3 Audit | 3.3.5 Audit review and reporting | Partial | Filterable log with CSV and JSON export for your SIEM. |
| 3.3 Audit | 3.3.8 / 3.3.9 Protect audit data | Supports | Audit log, export, and prune are admin-only. |
| 3.4 Configuration | 3.4.1 / 3.4.2 Baseline configuration | Partial | One binary, documented environment variables, offline signed license. Your CM process owns the host. |
| 3.5 Authentication | 3.5.1 / 3.5.2 Identify and authenticate | Supports | Unique accounts with a password-derived sign-in key (password never leaves the device), or OIDC SSO. |
| 3.5 Authentication | 3.5.3 Multifactor authentication | Partial | Enforce MFA in your OIDC provider; GossipSeal honours it. No built-in second factor for local accounts. |
| 3.5 Authentication | 3.5.10 Cryptographically protected passwords | Supports | Server receives a one-way derived key, never the password; keystores use PBKDF2-HMAC-SHA256 at 600,000 iterations (SP 800-132), inside the validated module in the FIPS build (desktop app). The admin console derives that key in the browser (RustCrypto PBKDF2 in WebAssembly, outside the module); the server-side hash and verification are the module's, and FIPS deployments use SSO for admin accounts. |
| 3.8 Media Protection | 3.8.1 / 3.8.2 / 3.8.9 Protect media and backups | Supports | Everything on disk, and every backup, is ciphertext with no server-side key. |
| 3.13 Comms Protection | 3.13.8 Encrypt CUI in transit | Supports | Sealed end to end on the client before transmission: AES-256-GCM, keys wrapped with ML-KEM-768 + X25519. Your TLS on top. |
| 3.13 Comms Protection | 3.13.10 Manage cryptographic keys | Partial | Per-file keys, per-user keystores, 2-of-3 recovery shares held by your people. Custody procedure is yours. |
| 3.13 Comms Protection | 3.13.11 FIPS-validated cryptography | Supports (FIPS build) | In the FIPS build, every cryptographic operation protecting your files runs as an approved service of the AWS-LC FIPS 140-3 validated module: AES-256-GCM encryption with module-generated IVs and decryption, HKDF, PBKDF2-HMAC-SHA256 password stretching, SHA-256 (with HMAC-SHA256 inside PBKDF2/HKDF), ML-KEM-768 key establishment (the approved service) combined with X25519 as an auxiliary classical shared secret that is not itself an approved algorithm, Ed25519 signing, and all key and nonce generation. Three things sit outside it on that path and we name them: the optional browser vault (disabled by default in this build, because no validated module runs as WebAssembly), the ML-DSA-65 half of every hybrid signature (its Ed25519 half is the module's, and both must verify), and the GF(2^8) arithmetic of Shamir recovery-share splitting (its randomness and integrity hash are the module's). Three carve-outs off the CUI path are named too: the admin console's browser-side sign-in derivation (admin password sign-in is off by default in the FIPS build; admins sign in through SSO), the OIDC library's login-flow RNG, and the uuid row identifiers. The module is validated; the product itself carries no FIPS validation, and that distinction is the whole claim. |
| 3.13 Comms Protection | 3.13.16 Encrypt CUI at rest | Supports | Ciphertext at rest, always. |
| 3.2, 3.6, 3.7, 3.9-3.12, 3.14 | Awareness, incident response, maintenance, personnel, physical, risk, assessment, integrity | Yours | Organizational controls. No file product covers them. |
Bottom line for an assessor: GossipSeal directly implements or materially supports the technical controls in 3.1, 3.3, 3.5, 3.8, and 3.13. 3.13.11 is supported in the FIPS build, with the three things outside the validated module's boundary named above rather than hidden.
ITAR
Technical data stays on a server you run, in the country you run it in, accessed by accounts you control. No foreign-owned cloud is in the path. The 2020 encryption carve-out (22 CFR 120.54) treats end-to-end encrypted data as not exported in transit if it uses FIPS-validated or equivalent cryptography and the provider cannot access the keys. GossipSeal meets the "provider cannot access the keys" half by design, and in the FIPS build the encryption, decryption, key derivation, key establishment (ML-KEM-768 approved, X25519 as its classical partner), Ed25519 signing (the approved half of each hybrid signature) and hashing that protect the data all run as approved services of the AWS-LC FIPS 140-3 validated module. The items outside that boundary are named under 3.13.11 above and in our FIPS statement; none of them is the confidentiality mechanism for data in transit. Note that the carve-out names FIPS 140-2 and this module is validated to FIPS 140-3, which supersedes it — that call belongs to your export counsel, not to us.
HIPAA
GossipSeal never receives PHI, so Gossip Apps is not a business associate and no BAA with us is needed. Encryption at rest and in transit are satisfied structurally; audit controls by the audit log; unique user identification by per-user accounts and SSO. Your covered entity still owns the server and the policies.
What we say and do not say
We say "designed to support NIST 800-171 / CMMC 2.0 Level 2 deployments", "ITAR-friendly by architecture", and "no BAA needed because we never hold PHI". We do not say "CMMC certified", "ITAR certified", "HIPAA certified", or "FIPS validated" until each is literally true.
Questions: admin@gossipapps.com.