Email Encryption vs. Secure Link for Documents

Someone asks you to send a passport scan, a salary statement, a signed contract. You know plain email is wrong. So you reach for encrypted email — S/MIME or PGP — and then spend ten minutes discovering the recipient has no key, an expired certificate, or a client that mangles the message. The real decision isn't "encrypted email vs. plain email." It's email encryption vs. secure link, and once you frame it that way, the gaps in the encrypted-email model become hard to unsee.

Both approaches protect data in transit. The difference is everything that happens after delivery — and for sensitive identity documents, after delivery is where the risk lives.

What encrypted email actually solves

Give S/MIME and PGP their due. When they work, they do real things:

• Confidentiality in transit and at rest in the mailbox — only the holder of the private key can read the message.
• Integrity and authenticity — signatures prove the message wasn't altered and came from the claimed sender.
• No third-party service — it rides existing mail infrastructure with no new vendor in the path.

For sender-to-known-recipient correspondence between two people who both run keys correctly, encrypted email is genuinely strong. The trouble is the conditions in that sentence.

The friction and the gaps

The friction is well known to anyone who's tried. The recipient needs a key, you need their public key, certificates expire, mobile clients are inconsistent, and a single misconfiguration silently downgrades to plaintext. In practice, the moment one side isn't set up, the whole exchange collapses back to a plain attachment — which is the outcome you were trying to avoid.

But friction is the smaller problem. The deeper issue is structural, and it survives even when the cryptography works perfectly:

• No expiry. A decrypted attachment lives forever in the recipient's mailbox, backups, and any folder they drag it to.
• No access limit. Nothing stops the message being forwarded, opened on five devices, or sitting in a shared inbox.
• No revocation. Send to the wrong address or change your mind, and there is no undo. The copy is gone.
• No audit log. You have no idea whether, when, or how often the file was opened.
• No scope. You send the whole file. There's no field-level or document-level narrowing.

Encrypted email secures the envelope. It does nothing about the copy the moment the envelope is opened. For a one-off message, fine. For an ID document that becomes a permanent artefact in someone else's storage, that's the entire risk.

The secure-link model

A controlled share link inverts the model. Instead of pushing a permanent copy to the recipient, you keep the file in a vault — encrypted at rest, served over TLS — and grant scoped, revocable access to it.

That single architectural change is what unlocks the controls encrypted email structurally cannot offer. The file never becomes the recipient's permanent property; it stays an object you govern. Expiry, access limits, download control, revocation, and an audit log aren't add-ons — they fall out naturally from "the file stays in one place I control." This is the same access-not-artefact principle behind sharing your ID without losing control.

Head to head

Dimension	Encrypted email (S/MIME / PGP)	Secure share link
Encryption in transit	Yes	Yes (TLS)
Encryption at rest	In the mailbox	In the vault
Recipient setup needed	Key + correct config	None (just the link)
Expiry	No	Yes
Access / open limit	No	Yes
Revocation after sending	No	Yes, instant
Audit log of opens	No	Yes
Download on/off	No	Yes
Field / document scope	No (whole file)	Yes
Forensic watermark	No	Yes
Fails safe when recipient unprepared	No (downgrades to plaintext)	Yes (link just works)

The pattern is stark. Encrypted email wins on "no new service in the path" and loses on every control that matters once the file lands. The secure link assumes nothing of the recipient and keeps the levers in your hands.

When encrypted email still makes sense

This isn't a blanket dismissal. S/MIME and PGP are the right tool when:

• both parties already run keys reliably (common in some legal, security, and government contexts);
• the content is correspondence, not a reusable artefact — a message whose value expires when it's read;
• you specifically want no third party in the chain for policy or jurisdictional reasons;
• you need a verifiable signature binding a statement to your identity.

If you're a security team emailing another security team, keep using PGP. The model breaks down precisely when the recipient is a bank's onboarding desk, a broker, or a notary's assistant — people who will not set up a key for you and who, once they have your unredacted file, can keep and forward it freely. That's also where you'll most often need to push back on the request itself, covered in countering insecure KYC requests.

The threat each model actually defends against

It helps to name the threat each approach is built for, because they're not the same threat. Encrypted email is designed against an interception adversary: someone reading mail in transit or sitting on the mail server. Against that adversary, S/MIME and PGP are genuinely effective.

The secure link defends against a different and, for identity documents, more common adversary: the recipient-side problem. The risk isn't usually a wiretap on the wire. It's the file living forever in the recipient's mailbox, being forwarded to a colleague, sitting in a backup for years, or surfacing in a breach of their systems. None of that is an interception attack, and encryption in transit does nothing about any of it.

This reframes the comparison cleanly:

• If your honest threat is "someone snooping the connection," encrypted email addresses it — and so does TLS on a link.
• If your honest threat is "this file outliving its purpose in someone else's storage," only the link model touches it, because only the link keeps the file as access you can withdraw rather than an artefact you've surrendered.

For an ID copy going to a counterparty, the second threat is almost always the real one. The wire is rarely where these documents leak; the recipient's storage is. Matching the tool to the actual threat, rather than to the comforting word "encrypted," is the whole decision.

The recommendation

For sensitive identity documents shared with counterparties you don't control, the secure link wins on the dimensions that matter:

1. Default to a scoped share link for any ID, KYC, or financial document going to a third party. You keep expiry, access limits, download control, instant revocation, an audit log, and a forensic watermark — none of which encrypted email provides. The ability to revoke alone justifies the choice; see revoking access after sharing.
2. Reserve encrypted email for genuine correspondence between parties who already run keys, or where a signed, self-contained message is the actual requirement.
3. Never let "encrypted" lull you. Encryption protects the message; it does not protect you from what the recipient does with the decrypted copy. Control over the artefact is a separate problem, and only the link model solves it.

This is the architecture ShareKYC implements: verify your identity data once, hold it AES-256 encrypted in an EU-hosted vault, and share it through links carrying expiry, access limits, download control, instant revocation, a full audit log, an invisible forensic watermark, and field-level scope. The recipient needs no key and no setup — and you keep every lever.

Conclusion

Encrypted email and secure links both protect data in transit, but only one keeps protecting it after delivery. S/MIME and PGP secure the envelope and then hand over a permanent copy you can't expire, limit, or revoke. A controlled share link keeps the file in a vault you govern, with the levers in your hands and nothing required of the recipient. For sensitive documents going to counterparties you don't control, default to the link. ShareKYC is built to make that default effortless.