What Does Encrypted File Transfer Mean

Most products that claim to offer encrypted file transfer are telling you something true and something incomplete at the same time. The phrase gets used to describe everything from a basic TLS connection to a fully zero-knowledge pipeline where the server never sees plaintext. If you care about what actually happens to your data, the distinction matters. Here is what "encrypted file transfer" means precisely, where the term gets abused, and which tools meet the bar when you look past the marketing.

Key Takeaways

• Encrypted file transfer describes a spectrum: TLS in transit is the floor, AES-256 at rest is table stakes, and client-side (zero-knowledge) encryption before the file ever leaves your device is the ceiling.
• Encryption strength alone does not prevent breaches. MOVEit, GoAnywhere, and Cleo all used AES-256 and TLS, and all were compromised through application-layer flaws like SQL injection and authentication bypass.
• "Data in use" is the least protected state. Any system that decrypts your file server-side for processing (search, AI summarization, indexing) has a window where plaintext exists, regardless of how strong the at-rest and in-transit encryption is.
• Not every tool marketed as encrypted file transfer software actually provides end-to-end encryption. Some major platforms can technically view your files on standard plans because they hold the decryption keys.
• Metadata leakage (who sent what, when, file sizes, access patterns) remains a real exposure even in systems with genuine content encryption.

What Are the Three States of Data Encryption?

Data exists in three states, and each requires a different kind of protection. Conflating them is how vendors get away with calling something "encrypted" when only one leg of the trip is covered.

Encryption at Rest

Encryption at rest protects files sitting on a disk, in a database, or in cloud storage. The standard cipher is AES-256. If someone steals the physical drive or gets unauthorized access to the storage backend, they get ciphertext. This addresses physical theft, unauthorized access, and insider threats at the storage layer. It does nothing about what happens while the file is moving across a network.

Encryption in Transit

Encryption in transit protects data as it travels between two points. TLS 1.3 is the current standard. It prevents network interception, eavesdropping, and man-in-the-middle attacks. But encryption in transit and encryption at rest address fundamentally different threat models, and neither substitutes for the other. A file encrypted with TLS during upload can land on a server in plaintext if the server decrypts on arrival and stores it unencrypted.

What About Data "In Use"?

This is the gap most vendors quietly skip over. Data in use is the least protected state. Protecting it requires specialized technologies: trusted execution environments (TEEs), fully homomorphic encryption, or secure multi-party computation. None of these are mainstream in file transfer products today. The practical consequence: any system that needs to read, index, or process your file server-side will decrypt it into memory. That window of plaintext exposure is real, even if it's brief.

A hospital that encrypts patient records at rest and transfers them over TLS still hands plaintext to the ML pipeline at the destination. The encryption provided no protection for the actual use case. This pattern repeats across industries.

What Makes a File Transfer Genuinely "Encrypted"?

A secure encrypted file transfer means the file is mathematically scrambled on the sender's device before it ever leaves, and only the intended recipient holding the correct keys can decrypt it. This is a much stricter bar than "encryption somewhere in the pipeline."

The baseline that most products ship today combines AES-256 for data at rest with TLS 1.3 for data in transit. That combination is necessary. It is not sufficient for the strongest privacy claims. The stronger implementations add client-side encryption on top, so the server never possesses the plaintext or the decryption key. Some vendors call this "zero-knowledge." Some cryptographers object to that term (more on that below).

The hierarchy, from weakest to strongest, looks like this:

1. TLS in transit only (email attachments, basic HTTP uploads)
2. TLS in transit plus AES-256 at rest (most cloud storage, most managed file transfer platforms)
3. Client-side encryption before upload, with keys held only by sender and recipient (the actual end-to-end bar)

If a product does not specify where in this stack it falls, assume it's option two. Option three requires explicit architectural choices that vendors tend to advertise loudly when they've made them.

Why Is Email Not Encrypted File Sharing?

Ordinary email attachments do not qualify. TLS protects the hop-by-hop transmission between mail servers, but once delivered, no controls remain on the file. The recipient's mail server stores it in plaintext (or with server-managed encryption, which the provider controls). There is no access revocation. There is no expiry. There is no audit trail. Calling an email attachment "encrypted" because SMTP used TLS is like calling a postcard "secure" because the mail truck had a lock on its doors.

Does "Encrypted" Actually Mean "Secure"?

No. This is the most common and most costly conflation in the category. The mistake most organizations make is assuming "encrypted" means "secure." Encryption is a necessary component of security. It is not the whole thing.

The MOVEit breach is the clearest proof. MOVEit is a managed file transfer platform with AES-256 encryption and broad compliance features. In mid-2023, attackers exploited a zero-day SQL injection vulnerability to steal data from hundreds of organizations. The cryptography was never attacked. The application layer was.

This is not a one-off. Similar breaches hit Accellion in 2020, GoAnywhere in January 2023, and Cleo in late 2024. Every one of these platforms advertised strong encryption. Every one was breached through application vulnerabilities: SQL injection, remote code execution, authentication bypass. The pattern is consistent enough to be a lesson rather than an anomaly.

The lesson is not that these vendors are careless. It is that attack surface and deployment architecture matter as much as encryption strength. Key management, access control, audit logging, and a reduced number of internet-facing components determine whether encryption actually protects data in a real attack. A compliance checklist that says "AES-256: check" tells you almost nothing about breach resistance.

What Does "Zero-Knowledge" Mean in File Transfer?

"Zero-knowledge" has a precise meaning in cryptography: it describes a proof system where one party can prove knowledge of a value without revealing the value itself. The file-sharing industry has borrowed the term to mean something looser: "the server has zero knowledge of your file contents because it never possesses the decryption key."

This is not technically wrong, but it is imprecise. Cryptographers have pushed back on this usage for years, preferring terms like "client-side encrypted" or "zero-access." The debate is mostly terminological, not architectural. If a product encrypts your file on your device, transmits only ciphertext, and stores only ciphertext with no server-side key, the privacy property is real regardless of what you call it.

But the term gets abused. Some products claim "zero-knowledge" while retaining server-side key escrow, or while decrypting files for server-side processing like search indexing or thumbnail generation. If the server can generate a thumbnail of your image, it had access to the plaintext. That is not zero-knowledge by any definition.

When evaluating any encrypted file transfer service, ask a specific question: does the server ever possess a key capable of decrypting the file? If yes, the zero-knowledge claim does not hold, regardless of what the landing page says.

What About Metadata Leakage?

Even in genuinely client-side-encrypted systems, metadata remains a real exposure. Research from UC Berkeley has shown that file-sharing systems with compromised servers can still observe user identities, file access patterns, timestamps, and file sizes, even though file contents remain hidden. This metadata alone can be deeply revealing. Who accessed a legal document, how often, and for how long tells a story even when the document content is encrypted.

No widely available file-transfer product fully solves metadata leakage today. Some minimize it (onion routing for network-layer metadata, padding for file sizes), but those are edge-case architectures. If metadata exposure matters to your threat model, you need to evaluate it separately from content encryption.

Which Encrypted File Transfer Software Actually Meets the Bar?

Most "top 10" lists of encrypted file transfer software rank products by feature count or price. That is not useful if your question is about the actual encryption architecture. Here is a more honest breakdown of the categories.

Products That Provide Client-Side (End-to-End) Encryption

These products encrypt on your device before upload and never hold your key server-side. The server stores ciphertext only. Examples include tools like Tresorit and certain configurations of Cryptomator (which is a client-side encryption layer you add on top of any cloud storage). Stronger implementations also add per-session viewer watermarks for additional leak tracing.

Some newer entrants are beginning to layer post-quantum key exchange on top of classical encryption. At least one 2026 comparison frames quantum-resistant end-to-end encryption (ML-KEM/Kyber-1024 combined with ECC-256) as the new top tier beyond standard AES-256 plus TLS 1.3. Whether post-quantum readiness matters to you today depends on your threat model and your data's shelf life. If your files need to remain confidential for 10+ years, it might.

Products That Encrypt at Rest and in Transit but Hold Your Keys

This is the majority of mainstream cloud storage and file-sharing platforms. They use AES-256 at rest and TLS in transit, but the provider manages the encryption keys. This means the provider can, technically, decrypt and view your files. At least one widely used consumer service does not offer end-to-end encryption on its standard plan, meaning the platform can technically access uploaded files. This is fine for many use cases. It is not fine if your threat model includes the provider itself, or a government subpoena served to the provider, or a breach of the provider's key management infrastructure.

Managed File Transfer (MFT) Platforms

Enterprise MFT products like MOVEit, GoAnywhere, and Cleo Harmony provide strong encryption, compliance logging, and workflow automation. They are designed for high-volume B2B file exchange with audit trails. Their encryption is real. Their breach history is also real. A strong secure file transfer architecture pairs encryption with unified key control and granular access policies, but architecture and patch discipline matter more than the cipher strength printed on the spec sheet.

DIY / Open-Source Tools

Tools like age (a modern replacement for PGP), Magic Wormhole, and croc handle the encryption correctly at the protocol level. They tend to lack the UI polish and workflow integration of commercial products. For a technical user sending a single file to another technical user, they're excellent. For a team of 50 people who need access controls, audit logs, and expiry policies, they are a starting point, not a solution.

How Should You Evaluate an Encrypted File Transfer Service?

Skip the feature matrix. Ask five questions instead.

1. Where does encryption happen? On your device before upload (client-side) or on the server after upload (server-side)? Client-side is the stronger claim.
2. Who holds the keys? If the provider holds the decryption key, they can read your files. Full stop. "We would never do that" is a policy, not a cryptographic guarantee.
3. What happens to the file after delivery? Is it deleted automatically? Can you revoke access? Is there a verifiable deletion mechanism, or is "delete" just a database flag?
4. What is the attack surface? How many internet-facing components does the product expose? The MOVEit/GoAnywhere pattern teaches that fewer components and simpler architectures are harder to breach, independent of encryption strength.
5. What metadata does the server see? Even if content is encrypted, does the provider log sender/recipient identities, file sizes, access times, IP addresses? What is their retention policy on that metadata?

Any encrypted file transfer service that cannot answer these questions clearly is asking you to trust marketing copy over architecture. That is not a trade you should make.

Does Encryption Matter if the Application Layer Is Broken?

Bluntly: no. The breach pattern across MFT platforms over the past several years makes the case without qualification. MOVEit's exposure and architecture allowed a single flaw to cascade into one of the largest data-theft campaigns in recent memory. The encryption was never the weak link. The web application sitting in front of it was.

This has direct implications for how you choose tools. A product with AES-128 and a minimal, well-audited codebase may be more secure in practice than a product with AES-256 and a sprawling attack surface full of legacy features. Encryption is a necessary condition for secure transfer. It is not a sufficient one.

For AI-native products that process files (summarization, extraction, search), the risk compounds further. The file must be decrypted for model inference. That means plaintext exists in memory during processing. The question becomes: where does that processing happen, who controls that environment, and how quickly is the plaintext discarded? These are architectural questions, not cryptographic ones.

How Does SelinaSEND Handle This?

We built SelinaSEND around a specific architectural choice: files uploaded fresh into SelinaSEND are zero-knowledge, end-to-end encrypted. The server never holds the decryption key. We cannot read your files. By design.

Standalone notes written outside the AI follow the same path. Zero-knowledge, end-to-end.

Chat messages and conversations are different. Those are encrypted in transit and at rest, but the content was processed by a frontier model during creation, so they were never zero-knowledge. We state the honest limit rather than papering over it with a blanket claim.

Files sent from SelinaVault are encrypted at rest, under a key you control, and cryptographically erasable. Delete means gone. Actually gone.

Non-content operational metadata is kept for a short retention window. Not zero retention.

We think this kind of per-path honesty is what the category needs. A single unqualified "everything is encrypted" claim should make you suspicious, not reassured.

Where Is the Category Headed?

Three trends are converging.

First, post-quantum encryption is moving from academic to commercial. Quantum-resistant key exchange is showing up in product comparisons, not just NIST drafts. If your data has a long secrecy horizon, "harvest now, decrypt later" attacks mean AES-256 plus TLS 1.3 may not be the ceiling of the category for much longer.

Second, the "data in use" problem is getting more attention as more products feed files into AI pipelines. The gap between "encrypted at rest and in transit" and "actually private during processing" is becoming harder to ignore.

Third, breach patterns are forcing a shift from "is it encrypted?" to "what is the total attack surface?" Compliance checklists built around cipher strength are not preventing breaches. Architecture is. The question is whether buyers will start evaluating products on architecture rather than feature tables.

The answer to "what does encrypted file transfer mean" is not a single thing. It is a spectrum. Where a product falls on that spectrum depends on where encryption happens, who holds the keys, what the server sees, and how much attack surface sits between the attacker and your data. The cipher is the easy part. Everything around it is where products actually diverge.

If you want to see what per-path encryption honesty looks like in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io