Secure File Sharing vs Encrypted Email: Which Is Safer?

Table of Contents

1. Two problems that are often confused
2. What TLS actually protects
3. S/MIME: certificate-based end-to-end email
4. OpenPGP: key-based end-to-end email
5. Link-based sharing platforms
6. Threat model comparison
7. Comparison table
8. Metadata, subjects and what stays visible
9. Key management and operational cost
10. Decision framework: when to use which
11. Implementation checklist
12. Frequently Asked Questions
13. Related Reading
14. Sources

Two problems that are often confused

When a business says it needs "secure email", it can mean several different things. It might want to stop an eavesdropper on the network from reading messages. It might want to ensure that a mail provider cannot read the content of a contract. It might want the recipient to prove the message came from the sender. It might want to make a file unusable after a certain date, or to know who opened it. These are distinct requirements, and different technologies meet them to different degrees.

It helps to separate the problems into three groups:

• Protecting data in transit between two systems, such as a laptop and a web server, or two mail servers.
• Protecting content end to end, so that only the intended recipient's device can decrypt it, regardless of the intermediaries.
• Controlling access after delivery, including who may open a file, for how long, from where, and whether access can be withdrawn.

TLS is primarily a transit protection. S/MIME and OpenPGP are end-to-end content protections applied to messages. Link-based sharing platforms are primarily access-control systems that also encrypt data in transit and at rest. Comparing them as if they were interchangeable leads to bad decisions, so the rest of this article treats them separately.

What TLS actually protects

Transport Layer Security, defined in RFC 8446 for TLS 1.3, provides confidentiality, integrity and server authentication for a connection between two endpoints. When you load a web page or upload a file to a sharing platform over HTTPS, TLS protects the data on the wire between your browser and the server. It prevents a passive observer on the network from reading the traffic and an active attacker from modifying it undetected, provided the certificates are validated correctly.

Email has a more complicated transit story. Messages typically travel through several servers: the sender's mail submission server, one or more relays, and the recipient's server. SMTP servers can negotiate TLS using the STARTTLS extension described in RFC 3207, but that negotiation is historically opportunistic. If the receiving server does not offer TLS, or if an attacker strips the offer, the message may travel in cleartext. Two standards help enforce transport encryption for email. MTA-STS, described in RFC 8461, lets a domain publish a policy requiring TLS and valid certificates. DANE for SMTP, described in RFC 7672, uses DNSSEC-signed records to pin certificates. Adoption varies, so you cannot assume that the path an email takes is encrypted in every case.

The key limitation is that TLS protects the connection, not the message. Once the message reaches a server, the server processes it in cleartext. The mail provider can read it, store it and scan it. If the provider is compromised, its stored messages may be exposed. TLS on the wire does not help with any of that. Be precise about this when you describe encryption to your organisation: "our email is encrypted" frequently means "the connection was encrypted at some hops", which is a much weaker statement.

S/MIME: certificate-based end-to-end email

S/MIME, specified in RFC 8551 as S/MIME version 4.0, provides cryptographic signing and encryption of MIME messages. It relies on X.509 certificates issued by a certification authority or an internal PKI. A user holds a private key and a certificate. To send an encrypted message, the sender encrypts the content with a symmetric session key, then encrypts that session key with each recipient's public key. Only a recipient holding the matching private key can recover the session key and decrypt the content. Signing uses the sender's private key so that recipients can verify authorship and detect tampering.

The strengths of S/MIME are that it is built into many mainstream mail clients, it integrates with enterprise PKI and directory services, and it provides end-to-end protection of body content and attachments against the mail provider and against intermediate servers. It also gives non-repudiation properties through signatures, subject to how the signing key and certificates are managed.

Its weaknesses are operational. Both sender and recipient need valid certificates, and the sender needs the recipient's certificate before encrypting to them. Certificate discovery and trust relationships are the hard parts. Lost keys cannot be recovered without a key escrow or recovery design. Certificate revocation and expiry require discipline. Most importantly, S/MIME does not protect email headers in the normal way: sender and recipient addresses are visible to mail infrastructure, and the subject line is commonly left unencrypted unless it is placed in protected headers, which not every client supports. S/MIME also does nothing to stop a recipient from forwarding the decrypted message to anyone else.

OpenPGP: key-based end-to-end email

OpenPGP provides a similar end-to-end model using keys rather than a certificate hierarchy by default. The current specification is RFC 9580, which supersedes the older RFC 4880. Users generate key pairs, publish or exchange public keys, and encrypt messages to the public keys of their recipients. Signing works in the same way. Implementations include GnuPG and various mail plugins. The "web of trust" model, in which users sign each other's keys, is one trust approach, though many organisations instead use key directories or verify fingerprints out of band.

OpenPGP's strengths include a mature, well-studied format, the ability to work without a central certificate authority, and wide availability of open-source tooling. For individuals and small teams who value control over their keys, it is attractive.

Its drawbacks are similar to S/MIME in kind and sometimes greater in practice for ordinary staff. Key generation, backup, rotation and revocation require user education. Many common email clients do not integrate OpenPGP seamlessly, which means extra steps and mistakes. Metadata exposure follows the same pattern: envelope data and headers are not hidden, and the subject line often remains readable. Like S/MIME, PGP cannot prevent a legitimate recipient from copying what they read.

Link-based sharing platforms

Link-based sharing platforms take a different approach. Instead of sending the file inside a message, they store the file on their servers and send the recipient a link. Access to the link is then governed by the platform's rules: identity verification, passcode, expiry, view-only mode, download restrictions, watermarks and audit logs. The message contains the link, not the document.

Security properties depend heavily on implementation. Typically, data is protected in transit with TLS and at rest by provider-managed encryption. This matters, but it has to be described accurately. Provider-managed encryption at rest protects stored data against theft of physical media and some categories of storage breach, but the provider holds the keys and the service can decrypt content to render previews, index text or run scans. Only when the client encrypts the file before upload, and the platform never holds the decryption key, does the platform become unable to read the content. Some vendors offer client-side or zero-knowledge designs, but these often carry trade-offs, such as reduced preview features or the need to manage keys carefully. Verify any such claim against the vendor's technical documentation rather than the marketing page.

The strengths of link-based sharing are operational. It allows revocation of the hosted copy without re-sending anything. It enforces expiry centrally. It produces access logs that show who opened the file, when and from where, subject to the viewer's consent and applicable law. It avoids cluttering inboxes with large attachments and it avoids giving the recipient a copy that persists beyond the platform's control.

The weaknesses are that the platform becomes a dependency and a high-value target, the provider can technically access content unless it is client-side encrypted, and the recipient's access is only as strong as the verification method. A link forwarded to someone else works unless the platform enforces named identity. And none of these platforms can stop a recipient from photographing the screen.

Threat model comparison

A threat model asks: who might want this information, what can they do, and what would the consequences be? Different adversaries call for different controls. The table below is a simplified way to think about the main categories.

• Passive network eavesdropper. TLS on the connection protects against this. Unencrypted SMTP hops are the main gap for email.
• Mail provider or platform operator reading content. S/MIME or OpenPGP protects content from the provider, but not headers. Link-based platforms protect content from outsiders but usually not from the provider, unless client-side encrypted.
• Compromised recipient or forwarded copy. Nothing in either model fully protects against this. Access logs, watermarks and revocation of the hosted copy help you respond, but do not prevent disclosure.
• Account takeover of the sender or recipient mailbox. Encryption helps only if the attacker lacks the decryption key or the platform's identity controls. An attacker who controls the mailbox can often read incoming encrypted messages if the private key is accessible from the mailbox, or can request access as the victim.
• Phishing and impersonation. Neither approach stops a fake request. Verification of the recipient, through a second channel, remains essential.
• Regulatory scrutiny. Some regulations require specific safeguards and audit trails. Whether a method satisfies them depends on the regulation and the specific implementation, so involve compliance staff early.

The uncomfortable conclusion is that for many business threats, the biggest risks are impersonation and over-sharing, which no encryption method addresses. Encryption solves the problem of interception and unauthorised reading in specific circumstances. It is one control among several.

Comparison table

Capabilities differ between products and implementations. The table reflects the general design of each category.

Metadata, subjects and what stays visible

Metadata is often underestimated. Even when message content is encrypted, the surrounding data may reveal a great deal. Mail routing requires the sender and recipient addresses. Timestamps, message sizes and the sending infrastructure are visible to intermediaries. The subject line is frequently left in clear text, which means a subject such as "Termination Agreement, Confidential" tells an observer more than the body is supposed to. Some clients offer ways to protect the subject, but support is inconsistent.

Link-based platforms also expose metadata to the platform: who created the link, the file name, size, when it was accessed and by whom. Depending on the platform, the file name itself may be sensitive. Name files neutrally when the name would reveal confidential information on its own.

When your threat model includes an observer who is interested in who is talking to whom, neither method hides the relationship. This is a fundamental limit of these designs and is worth stating clearly to decision-makers.

Key management and operational cost

Cryptography is rarely the weak point. Key management is. For S/MIME and OpenPGP, each user needs a private key that must be generated securely, stored safely, backed up, rotated and revoked when compromised or when the user leaves. Loss of a private key can make archived encrypted mail permanently unreadable, which may be unacceptable for records retention. Compromise of a private key can expose past messages if the key was used for decryption and is not protected by forward secrecy at the message level, which these email designs generally do not provide.

For link-based platforms, key management is largely the provider's responsibility, which is an advantage for most businesses and a dependency for others. The organisation must manage accounts, single sign-on, multi-factor authentication, role assignment and offboarding. Those controls are often where real protection is won or lost.

Operational cost includes training. Staff who must manage keys or verify fingerprints need time and support. Staff who only need to click a link need a clear message about verification and expiry. Choose the method your staff will use correctly, not only the one with the strongest theoretical properties.

Decision framework: when to use which

Use the following questions to narrow the choice.

1. Who are the recipients? If they are a small set of known partners who already use compatible S/MIME or PGP tooling, end-to-end email may be practical. If they are occasional external contacts with no tooling, a link-based platform is usually easier to use correctly.
2. Do you need to revoke or expire access after sending? If yes, end-to-end email cannot do this once delivered. Use a link-based approach or a controlled repository.
3. Do you need an access log? Link-based platforms typically provide one. Email encryption does not.
4. Does the platform operator itself represent a threat? If yes, you need client-side encryption with keys held only by you, or a design that does not place the content on a third party's servers. Be prepared for the operational cost.
5. Is metadata sensitive? If the existence and timing of communications are sensitive, neither approach is sufficient, and you should consider whether the content should be shared at all, or through a process with more restricted channels.
6. What do your regulators or clients require? Some contracts specify an acceptable method. Check before choosing.
7. Can your staff use it correctly every time? The best method is the one that is used consistently.

In practice, many organisations use both. Email carries short messages and secure links, while sensitive files go through a controlled sharing platform. Some use S/MIME internally for signed messages and rely on link-based sharing for external documents.

Implementation checklist

• Write down your threat model in one page: adversaries, assets and consequences.
• Verify that TLS is enforced where your mail system supports it, and evaluate MTA-STS for your domain.
• If using S/MIME or OpenPGP, define key generation, backup, rotation and revocation procedures before rollout.
• Confirm which headers and subjects remain visible in your chosen method and train staff accordingly.
• For link-based platforms, enable multi-factor authentication for all accounts and review sharing defaults.
• Set expiry and named access for confidential links, and log every external share.
• Ask each vendor, in writing, whether it can access plaintext content, and where keys are held.
• Test recovery: can you still read archived encrypted messages if a key is lost?
• Verify recipients through a second channel before sending sensitive material.
• Review the approach annually, or when regulations or threats change.