# Secure file sharing: what "secure" really means

Source: https://help.strongfolder.com/en/guides/secure-file-sharing/
Updated: 2026-11-05

> Secure file sharing means protecting a file on four fronts: encryption in transit, protection of any stored copy, control over who can open the link, and how long copies exist. No method wins on all four. Direct P2P transfer encrypts in transit and stores nothing; end-to-end encrypted cloud protects a stored copy; SFTP and managed transfer add audit trails.

"Secure file sharing" is printed on almost every file transfer service, yet it can mean
very different things. A link can be encrypted in transit and still leave a copy on a server
for a year; a stored copy can be unreadable to the provider and still be opened by anyone
who has the link. This guide breaks down what secure file transfer actually means, compares
the common methods, and gives a checklist you can apply to any tool — including ours.

**Key facts**

- **Secure file sharing** covers four things: **encryption in transit**, **protection at rest**, **access control** and **retention**. Metadata and the devices themselves matter too.
- **Direct P2P** (StrongFolder): encrypted in transit with DTLS, **no stored copy**, but no password on the link and the sender must stay online.
- **End-to-end encrypted cloud** (Tresorit, Proton Drive, Sync.com): stored copy the provider is designed not to read.
- **SFTP / managed file transfer**: system-to-system exchange with accounts and audit logs.
- For highly sensitive files, **encrypt the file yourself** and send the password separately — it works with any channel.

## What does "secure file sharing" actually mean?

A file is exposed at several points on its way from you to the recipient. A secure file
transfer method protects each of them — or tells you honestly which ones it doesn't.

1. **In transit.** Is the data encrypted while it travels across networks? Today almost
   every service uses TLS (HTTPS) or, for WebRTC, DTLS.
2. **At rest.** Is a copy stored anywhere other than your and the recipient's devices? If
   yes, who can read it — the provider, or only people with the key?
3. **Access.** Who can open the file? Anyone with the link, only people with a password,
   only signed-in accounts on a list?
4. **Retention.** How long do copies exist — minutes, seven days, until someone deletes
   them?
5. **Metadata.** What does the service learn even if it can't read the content — file
   names, sizes, IP addresses, who sent what to whom?
6. **Endpoints.** Once the file lands, it is only as safe as the recipient's computer.
   No transfer method protects against a compromised device.

## How do common file sharing methods compare on security?

| Method | In transit | Stored copy | Who can open it | Retention | Best for |
|---|---|---|---|---|---|
| Email attachment | Usually TLS between servers | Yes, in both mailboxes | Mailbox owners | Often years | Small, non-sensitive files |
| Cloud drive link (Drive, OneDrive, Dropbox) | TLS | Yes, provider can access | Link or named accounts | Until you delete | Collaboration |
| Transfer service (WeTransfer-type) | TLS | Yes, for a set period | Anyone with the link; password on some paid plans | Days | Quick sends when you can't stay online |
| E2EE cloud (Tresorit, Proton Drive, Sync.com) | TLS + client-side encryption | Yes, encrypted with keys the provider doesn't hold | Link, often with password | Until you delete | Sensitive files that must stay available |
| SFTP / managed file transfer | SSH or TLS | On the server, per policy | Accounts, keys, audit log | Per policy | Business and system-to-system |
| **StrongFolder (P2P)** | **DTLS** | **None** | **Anyone with the link while you share** | **Only during the transfer** | Large files and folders, no copy left |
| Encrypted archive (e.g. 7-Zip AES-256) | Depends on channel | Depends on channel | Only those with the password | Depends on channel | Adds a layer to any method |

Features vary by plan; check each vendor's current documentation for passwords, expiry and
audit options.

## How secure is P2P file sharing?

[P2P file transfer](https://help.strongfolder.com/en/guides/p2p-file-transfer/) removes the biggest long-term risk of
file sharing: the **stored copy**. With StrongFolder:

- **In transit:** WebRTC encrypts every data channel with DTLS, so the file stream is encrypted in transit on every connection.
- **At rest:** Files are never uploaded to or stored on a StrongFolder server.
- **Relay:** If a direct connection is impossible (strict corporate firewall, some mobile networks), the encrypted stream passes through a StrongFolder relay (TURN) server. The relay forwards the data and does not store it.
- **Metadata:** To create the link, the service keeps transfer metadata: file and folder names, sizes and the number of files.
- **Retention:** The link works while the sender keeps sharing. When the sender clicks Stop Sharing or closes the tab, the files are no longer available.

There is no "breach of the file archive" later, because there is no archive. Nothing
expires on a server because nothing was put there. How the encryption is set up is
explained in [How WebRTC file transfer works](https://help.strongfolder.com/en/guides/how-webrtc-file-transfer-works/).

## What are the honest limits of StrongFolder's security?

We'd rather you pick the right tool than over-trust ours:

- **No password-protected links.** Anyone who has the link can connect while you are
  sharing. Send the link through a channel you trust, and click **Stop Sharing** when the
  recipient is done.
- **Encryption in transit, not end-to-end with your own keys.** DTLS keys are negotiated by
  the two browsers, but their fingerprints travel through our signaling server. We don't
  claim "zero-knowledge" or end-to-end encryption with user-held keys.
- **IP addresses are visible to the other peer** in a direct connection, as in any video call.
- **Metadata is kept** to create the link: names, sizes and the number of files.
- **No audit trail or compliance certification.** If your organisation needs logged access,
  retention policies or certified processing, use a managed file transfer platform.

For files that are both large *and* highly sensitive, combine methods: encrypt the folder
into an archive with a strong password, send it with StrongFolder, and share the password by
phone. The archive protects the content; P2P avoids a stored copy.

## Secure file sharing checklist

Run through this before sending anything confidential, whatever tool you use:

1. **Classify the file.** Is it personal data, a contract, source code, health data? The
   more sensitive, the fewer copies you want.
2. **Choose by retention.** Can it be gone in an hour (P2P), or must it be available for
   weeks (cloud, ideally E2EE)?
3. **Check the recipient.** Confirm the address or chat before sending the link —
   misdirected links are the most common leak.
4. **Limit access.** Use a password or named accounts where available; with P2P, stop
   sharing when the recipient is done.
5. **Encrypt sensitive content yourself** if the channel doesn't encrypt at rest, and send
   the password separately.
6. **Avoid public Wi-Fi** for the sender if you can; use a trusted network or VPN.
7. **Remove copies afterwards** — from downloads folders, chat histories and cloud trash.
8. **Follow your organisation's policy.** Regulated data may require specific tools.

[Send files now](https://strongfolder.com)
## When should I use SFTP or managed file transfer instead?

"Secure file transfer" in a company context often means **SFTP** (file transfer over SSH),
**FTPS** or a **managed file transfer (MFT)** platform. These shine when:

- systems exchange files automatically on a schedule;
- you need per-user accounts, permissions and an **audit log** of who downloaded what;
- regulators or contracts require documented retention and access control.

They need setup and accounts on both sides, so they are overkill for sending one video to a
client — and that is where browser tools fit.

## When is end-to-end encrypted cloud the better choice?

When the file must remain **available after you go offline** and you don't want the
provider to read it. Tresorit, Proton Drive and Sync.com encrypt on your device before
upload. The trade-off: you upload first, a copy exists (encrypted), and storage is limited
by your plan. P2P and E2EE cloud solve different problems — see
[P2P vs cloud file transfer](https://help.strongfolder.com/en/guides/p2p-vs-cloud-file-transfer/).

## Summary

Secure file sharing is not a single feature but a set of answers: encrypted in transit,
protected or absent at rest, limited access and short retention. StrongFolder's answer is
DTLS encryption in transit and **no stored copy**, with honest limits — no link passwords
and no end-to-end encryption claim. For more, read [Security & privacy](https://help.strongfolder.com/en/security/) and
[How to send large documents](https://help.strongfolder.com/en/guides/send-large-documents/).

## FAQ

### What is the most secure way to share files?

It depends on the threat. To leave no copy on any server, send directly (P2P) and encrypt the file yourself if it is highly sensitive. To keep a copy available that the provider can't read, use end-to-end encrypted cloud. For audited business exchange, use SFTP or a managed file transfer platform.

### Is StrongFolder end-to-end encrypted?

WebRTC encrypts every data channel with DTLS, so the file stream is encrypted in transit on every connection. We describe this as encryption in transit between the two browsers. We do not claim end-to-end encryption with keys you hold, and the link has no password: anyone with the link can connect while you are sharing.

### Does StrongFolder store my files?

Files are never uploaded to or stored on a StrongFolder server. To create the link, the service keeps transfer metadata: file and folder names, sizes and the number of files. If a direct connection is impossible (strict corporate firewall, some mobile networks), the encrypted stream passes through a StrongFolder relay (TURN) server. The relay forwards the data and does not store it.

### Is email secure for sending confidential files?

Not by default. Mail servers usually encrypt connections between them, but copies stay in the sender's and recipient's mailboxes, often for years, and attachments are capped at about 20–25 MB. For confidential files, send a link to a protected copy or encrypt the attachment.

### What is the difference between secure file sharing and secure file transfer?

The terms overlap. 'Secure file transfer' often refers to protocols and platforms that move files between systems — SFTP, FTPS, HTTPS, managed file transfer — while 'secure file sharing' usually means giving a person access to a file through a link or folder. Both rely on encryption, access control and retention.

### How can I add a password to a file I send?

Pack it into an encrypted archive — for example with 7-Zip using AES-256 — and send the password through a different channel, such as a phone call or a separate messenger. This works with any transfer method, including P2P.

### Can the recipient see my IP address in a P2P transfer?

In a direct connection, yes — each browser connects to the other's address, as in a video call. If that matters, share through a channel that hides addresses, or connect via a VPN.