Beamprobe Beamprobe v1.0
← All articles
compliance 13 Apr 2026 · 10 min read

Encrypted File Sharing: What "Encrypted" Actually Means in 2026

Most "encrypted file sharing" claims describe one of three different things. This guide explains the real distinctions — at-rest, in-transit, end-to-end — and what UK GDPR actually requires.

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.

The three encryptions

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. AWS S3’s SSE-S3 default is AES-256.

What it protects against: physical theft of disks, AWS 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 UK GDPR actually requires

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 to look for in a vendor

When evaluating “encrypted file sharing” claims, three questions:

1. Where is the encryption performed?

  • Server-side encryption (SSE): the service decrypts files when you upload, then re-encrypts on disk. Standard for AWS S3, Beamprobe, 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 “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 Beamprobe handles encryption

Documented for transparency:

  • At rest: AES-256 (S3 SSE-S3) on all document storage. Database encryption at rest enabled.
  • In transit: TLS 1.2 minimum, TLS 1.3 preferred. HTTP redirects to HTTPS. HSTS preload.
  • Key management: AWS-managed keys with automatic rotation. Customer-managed keys (BYOK) available on Enterprise tier.
  • Backups: encrypted at rest with AES-256.
  • Application-level encryption: sensitive fields (encryption keys, OAuth tokens) encrypted at the application layer with a separate key.

This is what UK GDPR expects. It is not end-to-end. For 99% of UK business use cases, this is the correct choice.

When to demand more

Three situations where standard encryption is insufficient and you should require end-to-end or BYOK:

  1. Journalist-source workflows. End-to-end is appropriate. Use Signal or specialist tools.
  2. Lawyer-client privileged communications in adversarial scenarios. Some firms now require end-to-end for high-stakes matters.
  3. 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.

Conclusion

“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.


Related reading

Try Beamprobe

Need to share documents securely?

UK virtual data room from £29/month. NDA gate, per-page analytics, UK/EU residency included.

Start free