TL;DR. “Encrypted file sharing” describes three different things - encryption at rest (data encrypted on disk), encryption in transit (data encrypted while moving), and end-to-end encryption (data encrypted so the service provider cannot read it). For UK business use under UK GDPR, the first two combined are the standard requirement. End-to-end is overkill for most cases. This guide explains the real distinctions and how to evaluate vendor claims.
What are the three types of encryption?
1. Encryption at rest
Data is encrypted on the storage media (hard drive, SSD, S3 bucket) so that anyone who physically obtains the disk cannot read the data without the encryption key.
The standard in 2026 is AES-256. Most reputable file-sharing tools (Beamprobe, Microsoft 365, Google Drive, Dropbox Business) use AES-256 at rest by default. Beamprobe goes one step further and applies AES-256-CBC envelope encryption with a unique key per file before the ciphertext is handed to Cloudflare R2 - the storage provider sees only opaque bytes.
What it protects against: physical theft of disks, storage-provider region compromise, backup media loss.
What it does not protect against: an attacker with valid credentials to the service. If they can log in, they can decrypt and read.
2. Encryption in transit
Data is encrypted while moving over the network between sender and recipient (or between client and server).
The standard in 2026 is TLS 1.2 minimum, TLS 1.3 preferred. Modern browsers and APIs negotiate this automatically. HTTPS is the visible indicator.
What it protects against: network sniffing, ISP interception, man-in-the-middle on public Wi-Fi.
What it does not protect against: anything happening at the endpoints. Your computer, the server, the recipient’s computer all see the data unencrypted.
3. End-to-end encryption
Data is encrypted on the sender’s device with a key that only the recipient can decrypt with. The service provider transports ciphertext only - they have no ability to read the data.
Examples: Signal, ProtonMail, certain Tresorit / Sync.com tiers.
What it protects against: the service provider being legally compelled to hand over data, the service provider being compromised by attackers, insider threats at the service provider.
What it does not protect against: endpoint compromise (if your laptop is hacked, end-to-end doesn’t save you), key loss (lose the key, lose the data forever).
What does UK GDPR actually require for encryption?
Article 32 of UK GDPR requires “appropriate technical and organisational measures” - appropriate to the risk.
For typical UK business data (commercial documents, employment records, financial accounts):
- Encryption at rest with AES-256: expected
- Encryption in transit with TLS 1.2+: expected
- End-to-end encryption: not expected for ordinary business use
For high-risk data (Article 9 special categories: health, biometric, criminal records):
- The above plus tighter access controls
- End-to-end encryption: sometimes expected depending on the specific risk profile
The ICO has not mandated end-to-end encryption for ordinary business workflows. They have made clear that encryption (in some form) is a required measure for personal data.
What encryption should you look for in a vendor?
When evaluating “encrypted file sharing” claims, three questions:
1. Where is the encryption performed?
- Server-side envelope encryption: the service generates a unique key per file, encrypts the file with AES-256, then wraps the per-file key with a server-held master key. Standard pattern for Beamprobe, AWS S3, Google Cloud Storage, most enterprise tools. Acceptable for ordinary business.
- Client-side encryption (CSE): files are encrypted on your device before upload. The service stores ciphertext only. Required for end-to-end claims.
- Hybrid: files encrypted client-side, then re-encrypted server-side. Strongest model but rare.
2. Who holds the encryption keys?
- Service-managed keys: the service holds and rotates keys. Standard model, simpler for users, the default for most tools including Beamprobe.
- Customer-managed keys (CMK / BYOK): you provide the encryption key. The service uses it but cannot decrypt without your involvement. Available on enterprise tiers of major vendors. Required for some compliance frameworks.
- End-to-end with user-only keys: the service has no access to keys at all. Required for true end-to-end claims.
For UK SMB business use, service-managed keys are the appropriate default. For regulated industries (finance, health) or high-sensitivity data, BYOK is sometimes required.
3. Is the encryption documented in the DPA?
The vendor’s Data Processing Agreement should specify:
- Which encryption algorithms are used (e.g. AES-256-GCM, TLS 1.3)
- Where encryption is performed (in transit, at rest)
- Key management approach
- Key rotation policy
If the DPA is silent on encryption, that’s a red flag.
What do “encrypted” claims often hide?
Vendor marketing pages claiming “bank-grade encryption” or “military-grade encryption” usually mean AES-256 at rest plus TLS in transit. That’s fine - it’s the right standard - but the marketing language obscures specifics.
Things to ignore:
- “256-bit encryption” - describes key length, not what’s encrypted
- “Bank-grade” - banks use AES-256 like everyone else
- “Military-grade” - same as above
- “Zero-trust encryption” - vague; ask for specifics
Things to ask about:
- AES-256 at rest: yes/no
- TLS 1.2 or 1.3 in transit: yes/no
- Server-side or client-side encryption: which
- Customer-managed keys available: yes/no, on which tier
- Key rotation policy: documented or not
- DPA mentions encryption: yes/no
How does Beamprobe handle encryption?
Documented for transparency:
- At rest: every document AES-256-CBC encrypted with a unique 2048-byte random password before it is written to Cloudflare R2 storage. The password itself is encrypted with S/MIME (AES-256, 4096-bit RSA). Storage sees only ciphertext.
- In transit: TLS 1.2 minimum, TLS 1.3 preferred. HTTP redirects to HTTPS. HSTS preload.
-
Key management: the S/MIME private key is held only by the Beamprobe application; per-file random keys are generated server-side using
:crypto.strong_rand_bytes/1. Customer-held keys (BYOK) are on the Enterprise roadmap. - Backups: encrypted at rest with AES-256.
- Application-level encryption: sensitive database fields (OAuth tokens, password reset tokens) hashed or encrypted at the application layer.
This is encryption at rest with app-managed keys, not end-to-end encryption - Beamprobe servers can decrypt your documents in order to render them in the viewer. For 99% of UK business use cases, this is the correct trade-off.
When should you demand more than standard encryption?
Three situations where standard encryption is insufficient and you should require end-to-end or BYOK:
- Journalist-source workflows. End-to-end is appropriate. Use Signal or specialist tools.
- Lawyer-client privileged communications in adversarial scenarios. Some firms now require end-to-end for high-stakes matters.
- Health data subject to specific regulatory frameworks. UK NHS data, certain medical research data. End-to-end is sometimes mandated.
For ordinary UK business use - fundraising, M&A, accounting, professional services - standard encryption is the right answer. Demanding end-to-end for ordinary use creates operational friction without proportionate risk reduction.
What does “encrypted” really mean for file sharing?
“Encrypted file sharing” is a vendor claim that hides as much as it reveals. The right questions are:
- AES-256 at rest? Yes/no.
- TLS 1.2+ in transit? Yes/no.
- DPA documents the encryption? Yes/no.
- Key management approach? Service-managed or BYOK.
For UK GDPR ordinary business use, the answers should be yes-yes-yes-service-managed. That is what Beamprobe and other competently-built modern file-sharing tools provide.
Try Beamprobe free for 14 days → - AES-256 at rest, TLS 1.2+ in transit, UK data residency.