Managed file transfer is one of those product categories that quietly carries an enormous amount of enterprise data. Payroll files. Financial reconciliations. Medical claims. Intelligence reports. Engineering drawings. For a long time, the security conversation around MFT was about TLS configurations and access tokens,which are necessary, but which protect the connection, not the data. A string of high-profile MFT exploits over the past few years has made it obvious that protecting the connection is not enough when the product itself is the attack surface. Zero Trust applied to file transfer requires the file to carry its own security, not depend on the transfer system's.
What MFT Was Originally Designed to Solve
Automated, scheduled, auditable movement of large files between systems and organizations. The original value proposition explains why so much of the critical data flow in large enterprises still routes through MFT. When MFT emerged in the early 2000s, it solved a real problem: moving sensitive files from system A to system B with proof of delivery, without exposing the content to intermediate networks. The category became infrastructure, embedded in countless enterprise data pipelines. That structural importance is precisely why compromising an MFT vendor has become such a high-value attack objective.
The Breach Pattern That Repeats
Between 2021 and 2024, the pattern became unmistakable. In 2021, threat actors exploited Accellion FTA,older file transfer appliances sitting on perimeter networks for years. In 2023, MOVEit Transfer (CVE-2023-34362) from Progress Software exposed 2,700 organizations and 95 million individuals when the Cl0p ransomware group weaponized a SQL injection flaw. The same year, GoAnywhere MFT fell to a similar playbook. In December 2024, Cleo file transfer (CVE-2024-50623) followed suit, and CrushFTP (CVE-2024-4040) confirmed the momentum. Each incident shared a common architecture: a single high-value target exposed on the internet, files decrypted and held at rest on the platform, and centralized credentials that unlock organization-wide data egress.
The root cause was not poor cryptography or weak passwords. It was an architectural assumption that has finally broken: if a file is inside the MFT platform, it is under the platform's access controls. Compromise the platform, and every file in transit is exposed.
Transport Encryption Is Not Data Encryption
This distinction is critical and often blurred. TLS protects the tunnel,the connection between client and server. A file moving from Producer to MFT to Consumer over HTTPS is encrypted in transit. But the moment that file arrives on the MFT server, TLS terminates. The platform decrypts the file to validate it, route it, or apply policy. The file now sits decrypted at rest on disk, waiting for the recipient's SFTP client to retrieve it. If an attacker gains access to the server,through SQL injection, credential theft, or any of the zero-days above,the file is exposed in plaintext.
Data-centric encryption inverts this model. The file is wrapped before it ever enters the MFT platform. Only the encrypted ciphertext passes through the transfer system. The platform becomes a dumb pipe, incapable of decrypting the payload, incapable of exfiltrating the original data. The recipient unwraps the file only when they retrieve it,and only if their current context still satisfies the cryptographic policy bound to the file itself.
Policy Follows the File
In a zero-trust architecture, access policy is not a server-side decision made at the moment of request. The policy is bound to the file itself using cryptographic techniques such as ABAC (attribute-based access control) and Merkle-tree lineage. When the recipient's client attempts to decrypt the file, it evaluates the policy in-situ. If the recipient's device posture has degraded,antivirus disabled, firewall rule removed, device stolen,the decryption operation fails. If the recipient's role has changed since the file was sent, decryption fails. If the time window for access has expired, decryption fails. No separate policy enforcement point (PEP) on a server somewhere. No dependency on real-time policy lookup.
This is data-centric zero trust in practice: the file carries its own PDP (policy decision point). The enforcer and the data are the same object.
Integration with Existing Pipelines
Nobody rips out their MFT overnight. Enterprises have built thousands of workflows around MFT platforms: SFTP credentials provisioned in ServiceNow, S3 event-driven transfers, EDI settlement files on schedules measured in decades. The realistic modernization path is not replacement,it is wrapping data at the producer and unwrapping only at the authorized consumer, with the legacy MFT platform reduced to a dumb pipe, ignorant of payload contents.
This topology has immediate security benefits: the MFT vendor's breach cannot compromise data already encrypted at the application layer. It also has operational benefits: producers apply encryption once and the encrypted artifact moves through multiple transfer systems,MFT, cloud storage, temporary caches,without re-encryption overhead. The NIST SP 800-207 Zero Trust Architecture guidance on data-in-use encryption specifically addresses this pattern.
The Path Forward
The MFT category will not disappear. But the security assumptions that MFT vendors have depended on for two decades have become untenable. The next generation of file transfer,whether through evolved MFT products or through data-centric middleware,will embed cryptographic enforcement at the file object level, not at the platform level. Recent breaches in third-party risk and classified data sharing between coalition partners show the same pressure. Organizations that continue to depend on perimeter-level security for sensitive file movement are accepting the risk profile of the 2023 MOVEit incident. Those that embed the security policy inside the file itself are moving toward a trust model that survives vendor breach.
References
- NIST SP 800-207: Zero Trust Architecture (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)
- CISA Known Exploited Vulnerabilities (KEV) Catalog – MOVEit Transfer (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- Progress Software CVE-2023-34362 Advisory (https://www.progress.com/security/vulnerabilities)
- Accellion FTA End-of-Life and Security Updates (https://www.accellion.com/security)
- CrushFTP Security Vulnerability CVE-2024-4040 (https://www.crushftp.com/v9)
- Cleo Secure Data Exchange December 2024 Vulnerability (https://www.cleo.com/security)
- Cl0p Ransomware Group MITRE ATT&CK Profile (https://attack.mitre.org/)
- Cryptographic Enforcement in Zero Trust Architectures (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)
- Data-Centric Security and CAS-X (https://lattix.io/cas-x)
- Merkle-Tree Based Data Lineage and Audit (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)