Security

This page is the deep-dive companion to the Security overview on the marketing site. It covers how encryption, integrity checking, and network isolation actually work, and it's explicit about what's shipped versus what's still on the roadmap.

Running a formal vendor security review? See Security Architecture - the threat model, a who-can-decrypt matrix across the managed and E2E tiers, key-custody specifics, and the honest limits, written to hand to a security team.

Encryption#

Every project's block contents are encrypted at rest with AES-256-GCM by default. Each project gets its own key, wrapped by a hub-held key-encryption-key (KEK). Desktop writes are encrypted on your machine before upload; small files uploaded from the web are sent over TLS and encrypted by the hub the moment they arrive - so stored blocks are always ciphertext. Because the hub holds the KEK for a managed project, Swarmfile can decrypt when it needs to (for example, to generate a preview or thumbnail). So managed encryption protects your data at rest from the storage layer, not from Swarmfile itself - for that stronger guarantee, use the end-to-end tier below.

Opt-in end-to-end (customer-managed) encryption#

For projects that need a stronger guarantee than a hub-held key, you can opt into end-to-end encryption. Instead of wrapping the project key with a hub-held KEK, each member's copy of the key is wrapped to their own device keypair (X25519). The key never reaches Swarmfile's servers in plaintext at all, and grants happen client-side.

This is a content-only guarantee:

• File and folder contents become unreadable to the server.
• Filenames, folder structure, and file sizes stay server-visible - search, ACLs, browsing, and quota accounting keep working normally.

The trade-offs are real and worth knowing before you turn it on:

• Server-side preview and thumbnail generation don't work for E2E content, because the server can't decrypt it.
• SSO-based automatic key provisioning is less frictionless than the default tier.

Losing every device with a wrapped copy of a project key would mean losing the data permanently, so E2E projects should be created under an org recovery key. That key is split using Shamir secret-sharing escrow (2-of-3 by default), so no single lost device or credential is catastrophic.

For the step-by-step - setting up the recovery key, creating an E2E project, enrollment, and the recovery ceremony - see End-to-End Encryption Setup.

Content integrity#

Every block is BLAKE3-verified on arrival. Corrupt data - from a misbehaving peer, a bad transport, or disk corruption in transit - never reaches the application layer.

Erasure coding#

Blocks are protected with adaptive Reed-Solomon 10+4 erasure coding: any 10 of the 14 shards reconstruct the full data, so up to 4 slow or offline peers never block your read. This page keeps that summary brief - for the admin-facing detail on deliberate shard placement across your seed nodes, see Self-Hosted Seed Nodes.

Private P2P swarm#

The peer-to-peer transport runs in a private swarm. Joining it requires a pre-shared key and a custom protocol identifier - a random host on the public internet can't dial into your blocks even if it somehow learned a peer's network address.

Hub-only data-plane mode#

Some enterprises need to block UDP/QUIC entirely, or eliminate peer-IP exposure between employees' machines outright. An org-level policy - or an engine-local SWARMFILE_HUB_ONLY toggle - disables peer-to-peer entirely at startup: QUIC never binds, there's no peer discovery, no gossip, and swarmfile doctor reports clean. All reads fall through to HTTPS against our cloud storage instead.

This is admin-gated (owner or admin), and toggling it is itself an audited event. See Operations for where that shows up in your activity log.

Ransomware detection#

The system watches for a suspicious pattern inline, at high frequency: many content-hash (CID) overwrites in a short window from a single user. When it fires, that user is auto-quarantined. Lock acquire and lock renew both check quarantine state, so a quarantined user can't keep working even in the middle of holding a lock.

No kernel extension on macOS#

The default macOS installer (as of 2026-07-02) ships a kext-free build using FUSE-T, which mounts entirely in user space. There's no kernel extension, no dropping into Recovery Mode to lower security settings, and no system-extension approval prompt on Apple Silicon. A legacy macFUSE build path still exists in the codebase as a fallback, but it isn't what the public installer ships.

Not yet built#

We don't claim certifications or features we don't have. Here's what's still ahead:

• SOC 2 Type I - not started. Today, the team answers security questionnaires directly and walks customers through the architecture on request.
• SIEM forwarding - Splunk, Datadog, or S3 export of audit, access, and quarantine event streams. Today these events are stored internally only; there's no export path yet.
• Legal hold & retention immutability - a per-entry legal-hold flag that overrides retention and trash purge isn't built yet.
• DLP & egress controls - watermarking, share-link domain allowlists, and export policy gating are not built.

If any of these are a hard requirement for you today, talk to us directly - for details on the permission model that is live today, see Permissions.