How to Share Large Files Securely With External Clients

Table of Contents

1. Why large files create security problems
2. Option 1: Email attachments
3. Option 2: Transfer services
4. Option 3: Cloud storage links
5. Option 4: SFTP and managed file transfer
6. Comparison table
7. Encryption in transit, at rest and end to end
8. Access controls, expiry and verification
9. Practical workflow for external client delivery
10. Handling archives and compressed files
11. Choosing a method by scenario
12. Limitations
13. Checklist
14. Frequently Asked Questions
15. Related Reading
16. Sources

Why large files create security problems

A large file is anything that will not travel comfortably through the tools people normally use. For an agency, that may be a video master or a set of high-resolution design assets. For a consultant, it may be a data extract or a model with its supporting data. For legal and finance teams, it may be a document bundle, a disclosure set or a reconciliation file. In each case, the file is too big for a standard attachment, and the pressure to deliver it quickly creates shortcuts.

The shortcuts are where the risk lies. A common pattern is to upload a file to a free consumer transfer site with no access controls, email the link to a general address, and send the password in the next message. Another is to zip a folder with weak encryption and attach it to several emails. A third is to share a folder with "anyone with the link" because the client could not sign in. Each of these works in the narrow sense that the client receives the file, and each creates exposure that persists after the job is finished.

Good practice starts with asking three questions. What is the sensitivity of the content? Who exactly needs it? How long do they need it? The answers determine which method is proportionate, and they also identify the controls you need: encryption, authentication, expiry, logging and revocation.

Option 1: Email attachments

Email is the default for most people, and it is acceptable for small, non-sensitive files. Its problems with large files are practical and security-related. Mail providers impose attachment size limits, which vary by provider and change over time. Gmail's help documentation, for example, describes an attachment size limit and suggests Drive links for larger files, so check the current limits for your own provider rather than relying on memory. When a file exceeds the limit, the workaround is usually to split it, compress it or convert it, each of which can introduce new risks.

From a security standpoint, an attachment creates a full copy in every mailbox it reaches. The sender's Sent folder keeps a copy. The recipient's mailbox keeps a copy, and often so do backups and any devices that sync that mailbox. Encryption in transit between mail servers may protect the message on the wire, but only if both servers negotiate TLS, and it does not limit what the recipient does after delivery. Once an attachment is sent, you cannot revoke it through normal means.

Email is therefore suitable for small files with low sensitivity, and for short messages that point to a controlled link. It is not a good primary method for large confidential client files.

Option 2: Transfer services

Transfer services are web platforms designed to move files from sender to recipient, usually by uploading to the service and sending the recipient a download link. They are the most common alternative to email for large files and they range from simple tools to enterprise platforms.

Their security depends on the specific service. Consider these factors when evaluating one:

• Encryption in transit. The connection between your browser and the service, and between the service and the recipient, should use TLS. Confirm this in the vendor's documentation.
• Encryption at rest. Most services encrypt stored files on their servers. Ask whether the provider holds the keys and whether it can access plaintext content.
• Access controls. Look for passcodes, recipient verification, expiry dates, download limits and the ability to revoke a link.
• Logging. Check whether you receive records of uploads, downloads and link changes, and how long they are kept.
• Retention. Find out how long the service keeps files after expiry, and whether deleted files are recoverable from backups.
• Jurisdiction and contracts. For regulated data, check where the service stores data and what contractual terms apply, such as a data processing agreement.

Be cautious with free anonymous transfer tools for client data. They often lack authentication, expiry controls and logs, and they may keep files for uncertain periods. A transfer service is only as protective as its settings and its contract.

Option 3: Cloud storage links

Cloud storage services, such as Google Drive, Microsoft OneDrive and SharePoint, and Dropbox, are widely used for sharing large files. Upload the file to a folder your organisation controls, then share with named external users or create a link. The advantage is that the file is stored once, access can be changed centrally and the service is familiar to many clients.

The main risks are configuration risks. A link set to "anyone with the link" is shared with anyone who obtains the link. A folder shared with an external user may expose more files than intended. Files left in shared folders accumulate over time. Some organisations do not realise that external sharing is enabled by default, or that administrators can see and manage external shares.

Use the following settings where your plan supports them: restrict links to specific people, set an expiry date, disable download when it is not required, require sign-in or verification for external users, and review sharing permissions at the end of each engagement. Check the current official documentation for your service, because menu locations and available options change over time.

Option 4: SFTP and managed file transfer

SFTP, the SSH File Transfer Protocol, transfers files over an encrypted SSH connection. SSH is specified in RFC 4253 for its transport layer, and SFTP runs on top of it. OpenSSH, the widely used implementation, is documented on its project site. SFTP is well suited to bulk transfers, automated processes and clients with technical teams who can connect with a client application.

SFTP protects data in transit through SSH encryption, and it authenticates users through passwords or, preferably, public-key credentials. It does not, by itself, provide link expiry, a simple recipient experience or a built-in audit log of who viewed content, though server logging can record connections and transfers if configured. Files remain on the server until someone removes them, so retention and cleanup must be managed deliberately.

Managed file transfer platforms build on protocols like SFTP with web interfaces, approval workflows, logs and administrative controls. They can be a good fit for organisations that exchange files frequently with many clients. They also require ongoing administration, and the security of the deployment depends heavily on how it is configured.

Be careful with client access. Create separate accounts or directories for each client, avoid shared credentials, rotate keys when staff change, and remove access when a project ends.

Comparison table

Features change. Confirm current capabilities against vendor documentation before committing to a method.

Encryption in transit, at rest and end to end

Three kinds of encryption are often discussed together, and they protect against different threats.

Encryption in transit protects data as it moves between two points. TLS does this for web uploads and downloads and for many mail connections. SSH does it for SFTP. Transit encryption prevents a network observer from reading the data as it moves, but the endpoints, and any server that receives the data, see it in plaintext.

Encryption at rest protects stored data on disks and backups. Most cloud providers encrypt stored data by default. This protects against physical theft of storage media and some storage-level breaches, but the provider typically holds the keys and can decrypt data for normal operation, support and legal requests.

End-to-end or client-side encryption means the file is encrypted by the sender before it leaves their device, and only the intended recipient holds the decryption key. In this model the transfer service or storage provider stores ciphertext it cannot read. This is the strongest protection against the intermediary, but it shifts responsibility to key management. If the key is lost, the file may be unrecoverable. If the key is shared insecurely, the protection is gone.

A common practical approach for large files is to use transport encryption and access controls as the baseline, and to add client-side encryption for particularly sensitive content. Encrypting an archive with a strong tool is one way to do this, which the archives section covers in detail.

Access controls, expiry and verification

Encryption protects content from interception. Access controls decide who may open the file. For client work these matter as much as the transfer method.

• Named access. Allow the specific people who need the file, using their verified addresses.
• Expiry. Set an end date that matches the project. A file needed for a two-week review should not remain available for a year.
• Download limits. Restrict downloads where the client needs only to review the material.
• Passcode, sent separately. Where the platform supports it, add a passcode and send it through a separate channel, such as a phone call or text message to a known number.
• Recipient verification. Before sending, confirm the client contact through a channel other than the one that requested the file. This matters because impersonation of clients and suppliers is a common method of fraud.
• Audit logging. Keep records of what was sent, to whom, when and with what settings.

Verification deserves special emphasis for finance and legal teams. Requests to change bank details or to send files to a new address should never be accepted on the strength of an email alone. The FBI's Internet Crime Complaint Center publishes guidance on business email compromise and payment fraud, and its reporting channel is useful background for staff training.

Practical workflow for external client delivery

The following workflow suits agencies, consultants and professional services firms. Adapt the details to your size and risk profile.

1. Classify the file. Decide whether it is public, internal, confidential or restricted, using the same scheme your organisation uses for other documents.
2. Reduce the file. Remove unnecessary content, hidden data, metadata and old versions. For media files, export the approved version only. For data files, include only the required columns and rows.
3. Choose the method. Use the scenario table below. For most confidential client files, a controlled transfer service or a restricted cloud storage link is appropriate. Use SFTP for recurring technical exchanges.
4. Create the transfer. Upload to the chosen platform in a dedicated folder or transfer for this client and project, rather than a general shared folder.
5. Set controls. Add named recipients, a short expiry, download settings and a passcode if applicable.
6. Verify the recipient. Confirm the address through a trusted second channel.
7. Send the link, not the file. Keep the message short, state the expiry and name the file.
8. Send the passcode separately, if one is used.
9. Record the transfer. Log the file name, classification, recipient, method, settings, date and sender.
10. Confirm receipt. Ask the client to confirm they have downloaded the file and that it opens correctly. This also helps detect misdirected transfers.
11. Close the transfer. When the engagement ends, revoke access, delete temporary copies you no longer need and update your records.

This workflow adds only a few minutes per transfer, and it turns a risky ad hoc process into a repeatable one that your team can follow under pressure.

Handling archives and compressed files

Compressing a folder into an archive is a common way to reduce size and keep files together. It can also be a source of weakness if the archive is protected badly. Two points matter.

First, traditional ZIP encryption, sometimes called ZipCrypto, is considered weak and should not be relied on for sensitive content. Modern archive tools offer AES-256 encryption, which is much stronger. 7-Zip, for example, supports AES-256 for its archive format, documented on the project's site. Choose a tool and setting that uses a modern cipher, and verify with the recipient that their software can open it.

Second, the password is the weak point in practice. An AES-256 archive protected by a password that is emailed in the same message as the archive gives little protection. Send the password through a separate channel, use a strong randomly generated passphrase, and avoid reusing passwords across clients. Consider whether the archive is needed at all, or whether a controlled transfer with access controls is more appropriate.

Also remember that an archive is one large copy. If the recipient needs only part of the material, send only that part. Splitting a large archive into many small encrypted archives, each with its own password, usually creates more confusion and more opportunities for error than it solves.

Choosing a method by scenario

Use this as a starting point rather than a fixed rule.

• Small, low-sensitivity files, such as a proposal under a few megabytes. Email is acceptable, but a link is still preferable for confidential content.
• Large creative assets for a campaign, shared with a client who reviews them. A transfer service or cloud storage link with expiry and named access, and download permitted only where needed.
• Financial or legal documents for a specific counterparty. A controlled link with verification and a passcode, with an audit trail. Consider client-side encryption where the content is highly sensitive and the recipient can manage keys.
• Regular data exchange with a technical client. SFTP or a managed file transfer platform, with individual accounts, key-based authentication, retention rules and logging.
• Restricted personal data, such as employee records or health information. Apply the strictest controls available, consult your data protection function, and consider whether the data can be minimised or pseudonymised before transfer.

Limitations

Be clear about what these methods cannot do. A recipient who is authorised to view the file can copy, forward, print or photograph it. Encryption in transit does not control the recipient's device. Client-side encryption does not stop a recipient from decrypting and sharing the content. Expiry controls the hosted copy, not downloads. Access logs record activity but do not reveal intent. Transfer services and storage providers are third parties, and their security and contractual terms need to be assessed as part of your risk decision.

Large-file transfer is about proportionate control, not perfect protection. The aim is to make the right thing easy, the wrong thing hard, and every transfer visible enough to investigate if something goes wrong.

Checklist

• Classify the file and remove unnecessary content and metadata.
• Select a method based on sensitivity, recipient and frequency.
• Avoid anonymous, unmanaged transfer tools for client data.
• Restrict access to named recipients and set an expiry date.
• Disable download where the client needs only to view.
• Verify the recipient through a second channel.
• Send any passcode or archive password separately, with a strong, unique value.
• Use AES-256 or equivalent for encrypted archives, and avoid legacy ZIP encryption for sensitive content.
• Log every transfer, including recipient, settings and date.
• Confirm receipt and check the access log.
• Revoke access and remove temporary copies at the end of the engagement.
• Review external sharing settings quarterly.