What to Actually Look for in a Secure File Transfer Service

Every 18 months, another managed file transfer platform ships a critical vulnerability, hundreds of organizations get breached, and the cycle restarts. If you're evaluating a secure file transfer service right now, you're probably doing it because something broke, or because your compliance team finally escalated the risk. Either way, the question isn't which vendor has the longest feature list. It's which architecture doesn't repeat the pattern.

Key Takeaways

• Four separate MFT platforms shipped critical-severity vulnerabilities in an 18-month span. The breach pattern is architectural, not vendor-specific.
• Only 8% of government agencies and 11% of healthcare organizations encrypt MFT data at rest. The baseline is worse than most buyers assume.
• AI agents are becoming a new file-security attack surface: roughly 7.2% of organizations have anyone formally accountable for AI agent behavior.
• Regulation (NIS2, DORA, GDPR, 140+ national privacy laws) now demands provable control, not just encryption in transit. Audit logs and data-residency proof are table stakes.
• Zero-knowledge, end-to-end encrypted transfer (where the service provider cannot read file contents) eliminates the honeypot problem that legacy MFT creates.

Why Do MFT Platforms Keep Getting Breached?

Because they centralize sensitive files in a single, internet-facing system with broad access. That's the architecture. Everything else is detail.

The sequence is worth stating plainly. Cleo was exploited by the Cl0p group in December 2024, hitting hundreds of victims. CrushFTP followed in March 2025. Wing FTP in July 2025. Then MOVEit again in April 2026, with CVE-2026-4670 (CVSS 9.8 authentication bypass) and a chained privilege-escalation flaw, CVE-2026-5174. That latest MOVEit pair has no workaround: you need a full offline reinstall to patch. Four platforms, 18 months, all critical severity.

This isn't a string of bad luck. When you put a large volume of sensitive files behind a single authentication boundary, you create a target worth hitting. Every integration you bolt on (SFTP connectors, API endpoints, web portals, and now AI processing features) expands the code surface. The attacker needs one flaw. You need zero flaws. That math doesn't work over time.

How Bad Is the Encryption Baseline, Really?

Worse than you'd guess. According to Astute Analytica's 2026 report, only 8% of government agencies and 11% of healthcare organizations encrypt MFT data at rest. 63% of MFT systems still aren't integrated with SIEM tools, which means no real-time threat detection on the very systems housing your most sensitive files.

Think about what that means in practice. You have a centralized file repository, on the internet, with broad credentials, likely unencrypted at rest, and invisible to your security operations center. This is the status quo for most organizations. The breach headlines are not surprising once you know this number.

On the buyer side, priorities have shifted. 90% of businesses said they prioritized stronger security features over transfer speed in 2024 procurement decisions. The market knows the problem. The products haven't caught up.

What Architecture Actually Prevents the Honeypot Problem?

Zero-knowledge, end-to-end encryption. Not encryption in transit. Not encryption at rest on the server. End-to-end, meaning the service operator cannot decrypt the file contents at any point.

The distinction matters because it changes the breach calculus entirely. If an attacker compromises a zero-knowledge transfer service, they get ciphertext. Useless ciphertext. There's no key on the server to steal because the server never had the key. Compare that to a traditional MFT platform where a single authentication bypass gives you administrative control and plaintext access to every file in the system.

This is not a new idea. It's the same principle behind end-to-end encrypted messaging. But in the file transfer space, most vendors still hold the keys. They encrypt at rest, sure. They encrypt in transit, sure. But they can decrypt your files on their infrastructure, which means an attacker can too, given enough access.

The tradeoff is real: if the vendor can't see your files, the vendor can't scan them for malware, can't index them for search, can't process them with AI. You lose convenience features. For many use cases (regulated data, healthcare records, legal documents, financial filings), that tradeoff is correct. You don't want the vendor processing those files. You want them moved from point A to point B without anyone in the middle being able to read them.

How Does Regulation Change What "Secure" Means?

It moves the bar from "we encrypted it" to "prove you controlled it."

The regulatory landscape has gotten denser fast. NIS2 and DORA in the EU now impose stricter logging, encryption, and proof-of-control requirements on how organizations share sensitive data. GDPR's data-residency requirements interact with the EU AI Act's new constraints on how AI systems handle personal data. Germany in particular has become a concentration point for compliant transfer demand, driven by strict federal data-protection standards and the density of its banking sector.

More than 140 countries now have privacy laws. Cross-border data flows have become genuinely complex to do legally. A file transfer that routes through the wrong jurisdiction, even transiently, can create a compliance violation.

What this means for your evaluation: you need audit logs that prove where data went, when, and who accessed it. You need data-residency controls, not just promises. You need encryption that's verifiable, not just claimed. And you need all of this to be built in, not bolted on, because "we'll add compliance features later" is how you end up with 63% of MFT systems invisible to SIEM.

Why Are AI Agents the Next File-Security Crisis?

Because they're being given broad file access with almost no oversight, and the pattern looks exactly like the early days of MFT.

The Gravitee State of AI Agent Security report found that only about 7.2% of organizations have a named individual formally accountable for AI agent behavior. AI agents are frequently granted broader access than their task requires, often through shared service accounts or inherited credentials. They read files, process data, call APIs, and operate with the combined permissions of whatever service account they were wired up to.

This is the MFT pattern again, but faster. Centralized access, broad permissions, minimal logging, no clear ownership. The difference is that AI agents can be manipulated through their inputs (prompt injection, data poisoning) in ways that traditional software can't. An AI agent with file access and compromised instructions can exfiltrate data through its normal workflow, making the exfiltration look like legitimate operation.

Arete has observed the gap between vulnerability disclosure and active exploitation shrinking, partly because attackers are using AI-enabled tooling themselves. The offense is accelerating. The defense, for most organizations, is still "we gave the AI agent a service account and hoped for the best."

What Does This Mean for File Transfer Specifically?

If your AI agents have access to your file transfer system, and your file transfer system holds decryptable files, you've created a compound vulnerability. The AI agent becomes a new path to the same honeypot. The fix is the same architectural principle: don't give any system (human or AI) access to file contents it doesn't need. Zero-knowledge transfer means even if the AI agent is compromised, the files passing through the transfer layer are ciphertext the agent can't read.

There's a genuine tension here, and some privacy-focused storage products are running into it directly: if the storage provider can't see your files (client-side encryption), then standard AI agents can't process them either without extra decryption logic on the client side. You have to choose. Either the AI can read your files (and so can anyone who compromises the AI), or the AI can't read your files (and you handle processing locally). There's no architecture that gives you both simultaneously.

What Should a Secure File Transfer Evaluation Actually Cover?

Most vendor comparison pages focus on protocol support, throughput, and UI. Those matter, but they're not where the risk lives. Here's what to actually evaluate:

Encryption architecture. Who holds the keys? Can the vendor decrypt your files? If the answer is "yes, but we promise not to," that's not a security architecture, that's a policy. Policies fail. Math doesn't. Look for zero-knowledge designs where the key material never leaves your control.

Breach history and patch discipline. After Cleo, CrushFTP, Wing FTP, and MOVEit, this is non-negotiable. How fast does the vendor ship patches? Do they require offline reinstalls for critical CVEs (like the latest MOVEit pair), or can they push fixes without downtime? What's their disclosure track record?

Audit logging. Not "we have logs." What do the logs contain? Are they tamper-evident? Can they be forwarded to your SIEM in real time? Can you prove chain of custody for a specific file, to a specific regulator, six months after the transfer?

Data residency controls. Not "our servers are in the EU." Can you specify, per transfer, which jurisdiction the data transits through? Can you prove it after the fact? With 140+ national privacy laws, "it went through our CDN" is not an acceptable answer.

Metadata handling. Even if file contents are encrypted, metadata (who sent what, to whom, when, file names, sizes) can be sensitive. What metadata does the service retain? For how long? Is there a documented retention policy, or just a vague privacy page?

Integration surface area. Every integration is an attack vector. How many protocols does the platform expose? How many API endpoints? Each one is code that can contain vulnerabilities. A smaller, tighter surface area is, all else equal, more secure than a sprawling one.

Where Does the Market Go from Here?

The secure file transfer market is projected to grow from USD 5.69 billion in 2026 to USD 8.34 billion by 2031, at an 8.0% CAGR. Healthcare is the fastest-growing vertical at 10.3% CAGR, driven by sensitive patient data and tightening compliance rules. Cloud deployment is the fastest-growing mode at 9.8%, because organizations don't want to maintain the infrastructure themselves (understandable, given the patching burden the last 18 months have demonstrated).

The growth is real, but the interesting signal is where it's coming from. It's not enterprises adding features to existing MFT deployments. It's mid-market companies (and their compliance teams) concluding that consumer file-sharing tools don't meet regulatory requirements, and legacy MFT platforms are breach-prone honeypots. They need something in between: encrypted by default, audit-log-included, no server-side file access, and priced for organizations that don't have a dedicated MFT security team.

What We Built, and What We Learned Building It

SelinaSEND, the file transfer layer inside Selina, uses zero-knowledge, end-to-end encryption. We cannot read your files. Not "we promise not to." We architecturally cannot. The key material stays with you.

Building this taught us things that don't show up in vendor datasheets. One example: debugging an encrypted-at-rest system is fundamentally different from debugging a conventional one. A content column in the database can read as empty and still decrypt to valid data. The first time you encounter this, it looks like data loss. It isn't. But you can't diagnose it by querying the database directly. You have to debug through the application's own decrypt path on the specific rows under investigation. The database is not the source of truth. The decrypt path is. This seems obvious in retrospect, but it cost us a weekend the first time it happened, and it's the kind of operational detail that separates "we encrypt data" from "we actually run encrypted systems in production."

Non-content operational metadata (things like transfer timestamps, not file contents) is retained for a short retention window, then purged. Files themselves are deleted when you delete them. Actually deleted, not soft-deleted and retained for 90 days in case someone changes their mind.

Selina as a broader product is a privacy-focused AI assistant that remembers you across conversations, running on a stack of frontier models routed per task. The memory is adaptive and encrypted at rest. It is not end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. We state this clearly because overstating your encryption posture is worse than understating it. SelinaSEND (file transfers) is zero-knowledge. Memory is not. Different components, different threat models, different architectures.

How Do You Actually Compare Services Without Getting Fooled by Marketing?

Ask three questions. Every other question is a refinement of these.

First: "If your infrastructure is fully compromised, what does the attacker get?" If the answer involves plaintext file contents, the encryption architecture isn't protecting you from the threat that matters. The whole point of the MFT breach pattern is that the attacker gains full infrastructure access. Your security model needs to assume that happens.

Second: "Show me the audit log for a transfer I made last month." Not a screenshot. Not a demo environment. Your actual transfer, your actual log, with timestamps and recipient hashes and retention metadata. If they can't produce it, they can't help you with a regulatory inquiry either.

Third: "What access do your AI features have to my file contents?" This is the question most vendors don't want to answer clearly. If they offer AI-powered file analysis, classification, or search, those features require decrypted access to your files on their infrastructure. That's a design choice, and it might be the right one for your use case. But you should know you're making it.

The Mid-Market Gap Is Where the Real Risk Lives

Enterprise coverage dominates the MFT market conversation, but mid-market companies (roughly 1,000 to 10,000 employees) face a disproportionate share of the risk. They handle the same regulated data types as large enterprises. They face the same compliance requirements. They usually don't have dedicated file-transfer security teams, dedicated MFT infrastructure, or the budget to maintain either.

So they end up in one of two places: consumer-grade file sharing tools that lack audit logs, data-residency controls, and regulatory compliance features, or enterprise MFT platforms that are overscoped, expensive, and (as we've established) architecturally vulnerable. Neither option is good.

The right product for this segment is narrower than traditional MFT. It doesn't need to support every legacy protocol. It doesn't need an on-premises deployment option. It needs to be encrypted by default, auditable by default, compliant by default, and simple enough that you don't need a dedicated team to operate it. Cloud-deployed, zero-knowledge, with built-in logging that satisfies NIS2/DORA/GDPR without custom configuration.

This is where the market is moving. The 9.8% growth rate for cloud-deployed SFT isn't about convenience. It's about organizations concluding that maintaining their own MFT infrastructure is a liability, not an asset.

What Happens If You Do Nothing?

The threat actors get faster. The window between vulnerability disclosure and exploitation is shrinking. The regulatory penalties get larger. The next MFT platform CVE is coming (there have been four in 18 months; the cadence is not slowing). And AI agents, granted broad file access with minimal oversight, are creating new exfiltration paths that most organizations haven't even started to audit.

The status quo is not neutral. It's a position, and it has a cost. The cost just hasn't arrived yet for your specific organization. When it does, it arrives all at once.

If your current file transfer setup is a legacy MFT platform, an unencrypted FTP server, or a consumer cloud drive with a shared password, the evaluation you're doing right now is the right one. Just make sure you're evaluating the architecture, not the feature list.

Start a free 7-day trial, no card required, and send yourself a file to see what zero-knowledge transfer actually looks like from both ends.

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