How to send a sensitive file securely

To send a sensitive file securely, first check it needs sending at all: a private key can usually be generated where it will be used, and a certificate on its own is public. If it does need to travel, either encrypt it before it leaves your machine or send it through a link that expires after one download. Then send the passphrase, if there is one, by a different route from the file. A file and its password in the same email are one secret in one place.

This page covers the files that cause the most trouble: private keys, .pfx and .p12 bundles and their passwords, lists of recovery codes, and scanned passports and driving licences. For .env files and API keys, which have their own better answers, see sharing API keys and .env files.

Some files shouldn’t travel at all

Before choosing a method, check what you’re actually holding.

• A certificate (.crt, .cer, .pem containing only BEGIN CERTIFICATE) is public. Every web server hands it to every visitor. Email it.
• A certificate signing request (.csr) is public too. It contains the public key, not the private one.
• A private key should be created where it’s used. If someone needs a TLS certificate on their server, they generate the key and CSR there and send you the CSR. If a contractor needs SSH access, they send you their public key (id_ed25519.pub) and you add it. The private half never moves, so there’s nothing to intercept.
• Recovery codes for an account you’re handing over can often be regenerated by the new owner once they’re in, which invalidates the old list. Do that instead of sending the list where you can.

What’s left is the genuinely awkward case: a key that already exists and must be installed somewhere else, a .pfx exported for a Windows server or a firewall, an identity document someone needs to see.

Compare the methods

On file-share links: OneDrive and SharePoint can require external recipients to verify their address with a one-time code (“Specific people” links) and can put an expiry date on links, depending on what your admin allows. Google Workspace can give specific people access that expires on a date. Dropbox offers expiry dates and link passwords on its paid plans. All of them leave the file sitting in your drive until you remove it, so delete it once it’s been collected.

Encrypt it before it leaves your machine

Encrypting first makes the channel matter much less. A file encrypted on your laptop can go by email, file share or USB stick, and an intercepted copy is useless without the passphrase.

7-Zip is the most widely understood option, and the recipient only needs 7-Zip (Windows) or a compatible tool such as Keka (macOS). Use the .7z format, which encrypts with AES-256, and encrypt the file names too, so the archive doesn’t advertise prod-root-ca.key:

# -p with no value prompts for the passphrase; -mhe=on hides file names
7z a -t7z -p -mhe=on handover.7z server.key server.crt

In the 7-Zip window, the same options are Encryption method: AES-256 and Encrypt file names. Avoid the zip format’s legacy “ZipCrypto” encryption, which is weak enough to break.

age is better when the recipient is technical, because it can encrypt to their public key, so there’s no passphrase to send at all. It accepts SSH public keys, which most developers already publish on GitHub:

# Encrypt to the SSH keys on someone's GitHub account
curl -s https://github.com/their-username.keys | age -R - -o server.key.age server.key

# They decrypt with their private key
age -d -i ~/.ssh/id_ed25519 -o server.key server.key.age

Check the fingerprint of the key you’re encrypting to with the person, through a channel you trust, before you rely on it. GPG does the same job if your team already uses it.

Use a one-time file link for small, high-value files

For a single key or a .pfx file, a one-time link is often the simplest route: the file is downloaded once and deleted, and if the recipient finds the link already used, you know someone else got there first.

In ShareShield, file secrets are encrypted like text secrets and always downloaded as an attachment, never shown in the browser. They’re available on paid plans, with these size limits:

Keys, certificates and recovery-code lists are a few kilobytes, so any plan covers them. A scanned passport or a large archive can exceed 25 MB; for those, put an encrypted archive on a file share and send its passphrase as a one-time link. That combination gives you the large-file convenience of the share and the single-use passphrase of the link.

Always separate the file from its passphrase

This is the rule that matters most, and the one most often broken. An encrypted archive with the passphrase in the same email is not encrypted in any useful sense.

• The file goes one way, the passphrase another. File by share link or email; passphrase as a one-time link, or read out on a call.
• Generate a fresh passphrase for each transfer. Not the team’s usual one, and not one you’ve used before. A password manager’s generator with four or five random words is easy to read aloud and plenty strong.
• Don’t follow up with the passphrase “in the next email”. The two messages end up in the same thread, in the same mailbox, in the same backup.

Give each .pfx its own export password

A .pfx or .p12 bundle holds a certificate and its private key, protected by an export password. People routinely email the file and put the password in the body. Set a random export password when you create it:

openssl pkcs12 -export -out site.pfx -inkey site.key -in site.crt -certfile chain.crt

OpenSSL 3 prompts for the password and encrypts the bundle with AES-256 by default. Some older Windows versions and appliances can’t import that; if the import fails, re-export with -legacy, and treat the result as weaker protection that leans more heavily on keeping the file itself private.

Recovery codes and identity documents

Recovery codes are a password to the account, in bulk. Hand them over in person or sealed in a safe where you can, as how to send a password securely recommends for credentials that control other access. If they must travel, send them as a one-time file or text link, and have the new owner regenerate them as soon as they’re in.

Scanned passports, driving licences and bank letters are personal data under UK GDPR, and in the wrong hands they’re enough to open accounts in someone’s name. Before sending one, ask whether the recipient needs a copy or only needs to see it once; a video call where the person holds it up is often enough. If they need a copy, send it once, say how long it will be kept, and delete your own copies afterwards. If you’re the one collecting ID, a secret request saves the other person emailing their passport to you.

After it’s sent

• Confirm it arrived and opened. An archive that won’t decrypt usually means a mistyped passphrase, not an attack, but check before you resend.
• Delete the extracted copies. The decrypted key in someone’s Downloads folder is now the weakest point. Ask the recipient to move it where it belongs and delete the rest.
• Remove the file from the share. Expired links leave files behind in your drive.
• Remember that deletion is unreliable on synced folders and SSDs. Encrypting before the file touches OneDrive or Dropbox is what protects you, not deleting afterwards.