Secure File Transfer
Secure file transfer refers to the protocols, tools, and architectural patterns organizations use to exchange files containing sensitive data without exposing that data to interception, tampering, or unauthorized access.
Continue your mission
Secure file transfer refers to the protocols, tools, and architectural patterns organizations use to exchange files containing sensitive data without exposing that data to interception, tampering, or unauthorized access.
# Secure File Transfer
Secure file transfer refers to the protocols, tools, and architectural patterns organizations use to exchange files containing sensitive data without exposing that data to interception, tampering, or unauthorized access. It is a foundational data protection control because files are one of the most common vectors for both data sharing and data loss.
The problem is straightforward: files containing sensitive data move constantly. Contracts go to legal counsel. Financial reports go to auditors. Medical records go to specialists. Configuration exports go to vendors. Patient lists go to billing processors. In every case, the organization that originates the file bears responsibility for how it is transmitted, where it lands, and who can access it.
Email, the tool most users reach for first, fails this requirement in multiple ways. Messages and attachments transit multiple servers before delivery, and most of those hops are not encrypted in a way that prevents server-level inspection. Attachments land in recipient inboxes indefinitely, accessible to anyone who compromises that inbox. Recipients can forward files without the sender's knowledge or consent. There is no audit trail. There is no revocation. And there is no guarantee that the attachment reaches only the intended recipient, one forwarding mistake or autocomplete error can route a sensitive file to the wrong person instantly.
Secure file transfer replaces that trust-and-hope model with verifiable, audited, encrypted exchange.
SFTP is not FTP over SSH in name only. It is a completely redesigned protocol that runs over the SSH (Secure Shell) transport layer and provides file transfer, file access, and file management capabilities over an encrypted channel. SFTP is the most widely deployed secure transfer protocol in enterprise environments.
The SSH transport encrypts the entire session. Authentication can use passwords (weak, not recommended) or public-key cryptography (preferred), where the client presents a private key and the server validates it against a stored public key. No password traverses the network. All data in transit is encrypted using the negotiated cipher, typically AES-256.
SFTP servers are widely available as both standalone products and integrated features of operating systems. OpenSSH provides a production-grade SFTP server on Linux. Most enterprise NAS systems, cloud storage platforms, and MFT products expose SFTP endpoints. Clients include command-line tools (sftp, WinSCP, FileZilla) and programmatic libraries in every major language.
SFTP's primary limitation is operational: it is a point-to-point transfer protocol. It does not provide workflow automation, scheduling, retry logic, alerting, or audit dashboards out of the box. Organizations that need to manage dozens of trading partner connections or regulatory submission workflows typically graduate from SFTP to Managed File Transfer.
FTPS adds TLS encryption to the older FTP protocol. It exists primarily because of legacy system compatibility: FTP is deeply embedded in certain industries (healthcare EDI, financial batch processing), and FTPS allows those systems to add encryption without replacing the underlying protocol.
FTPS has meaningful operational complexity. It uses separate control and data connections, which creates complications with firewalls and NAT. Configuring FTPS correctly requires understanding the difference between explicit TLS (the client negotiates TLS after connecting on port 21) and implicit TLS (the client connects directly on port 990, which requires TLS). Misconfigured FTPS deployments sometimes fall back to unencrypted FTP without the operator noticing.
For new deployments, prefer SFTP. FTPS is a compatibility choice, not a security-optimized one.
Managed File Transfer platforms are purpose-built systems for high-volume, multi-partner, auditable file exchange. The major platforms include MOVEit (Progress Software), GoAnywhere (Fortra), and Globalscape EFT. These systems provide:
MFT is the appropriate choice for organizations with regulatory reporting requirements (HIPAA, SOX, PCI), complex trading partner relationships, or any environment where transfer audit trails are required for compliance.
The MOVEit lesson is worth understanding directly. In May 2023, the Cl0p ransomware gang exploited CVE-2023-34362, a SQL injection vulnerability in MOVEit Transfer, and exfiltrated data from hundreds of organizations. The incident exposed a structural risk: MFT platforms aggregate the most sensitive files an organization exchanges with the outside world. They are high-value targets precisely because they are designed to centralize that exchange. A single vulnerability in a widely deployed MFT platform becomes a mass exploitation event.
The response to MOVEit is not to avoid MFT. It is to operate MFT correctly: keep it patched, segment it from internal networks, enforce MFA for administrative access, disable unnecessary features, and monitor it aggressively.
When the use case genuinely requires email as the transport, secure email gateways add encryption at the message layer. Solutions like Zix, Virtru, and Proofpoint Encryption can intercept outbound messages containing sensitive data (detected by DLP policies or user-triggered classification), encrypt the message body and attachments, and deliver the recipient a link to a secure reader or a decryption key.
The limitation is recipient experience. Recipients outside the organization often must create an account or install a plugin to read encrypted messages. This creates friction that drives users toward workarounds, sending via personal email or using unencrypted consumer file sharing instead.
Secure email is a compensating control for organizations that cannot replace email-based file exchange. It is not a primary file transfer architecture.
Enterprise platforms like Microsoft SharePoint and OneDrive (with DLP policies), Box, and Dropbox Business provide a controlled alternative to email attachments for sharing files with external parties. The sender uploads the file to the platform and shares a link. Access can be time-limited, password-protected, and scoped to specific recipients. The platform logs all access.
The key requirement is that EFSS deployments include DLP policies that prevent sensitive data from being uploaded to personal or unapproved cloud storage. An organization that sanctions Box but allows employees to use personal Google Drive for the same purpose has not reduced risk: it has displaced it.
For one-off transfers between technical users, command-line encryption tools provide a lightweight alternative to full MFT infrastructure. Age (a modern encryption tool by Filippo Valsorda) encrypts files to recipient public keys with a clean, simple interface. GPG (GNU Privacy Guard) provides the same capability with more complexity and a longer track record. Both produce encrypted files that can be transmitted over any channel, including email, because the encrypted payload is the protected artifact.
These tools require recipients to manage key pairs, which limits their applicability to technical audiences. For general organizational use, they are impractical without tooling to manage the key distribution problem.
Every unencrypted file transfer is a data exposure event waiting to be discovered. Files transmitted in plaintext over FTP or unencrypted email can be intercepted by anyone with network access between sender and receiver. On shared networks, coffee shop Wi-Fi, or network segments with misconfigured switching, this is not a sophisticated attack. It is passive interception.
Beyond interception risk, the operational failures matter. Files sent to wrong recipients. Attachments retained in email archives indefinitely after their sensitivity expires. Vendor mailboxes compromised, exposing months of file exchange. Audit requirements that cannot be met because no one logged the transfer.
The regulatory picture is unambiguous. HIPAA requires covered entities to protect electronic protected health information (ePHI) in transit using encryption or equivalent protections. PCI DSS requires encryption of cardholder data transmitted over open, public networks. GDPR requires appropriate technical measures to protect personal data. In each case, unencrypted email transmission is a compliance failure, not a gray area.
The MOVEit breach affected over 2,000 organizations and exposed data belonging to more than 62 million individuals, based on public reporting through late 2023. The breach was not caused by a failure to use MFT. It was caused by a failure to patch and monitor it. The distinction matters: the tool is not the problem. The operational discipline is.
The Sovereign Data Protocol (SDP) governs how CDA approaches data in transit: "Your data lives where you decide. Period." File transfer security is the enforcement point for that decision at the boundary of the organization. Every file that leaves or enters the organization passes through a transfer mechanism. If that mechanism is not secure, the sovereignty claim is hollow.
Mission DPS-B03 (DLP Program Deployment) is the Theater Operations mission that directly addresses file transfer controls. DLP programs are not only about detecting sensitive data at rest: they include controls over which transfer mechanisms are approved, DLP inspection of file uploads and downloads, and enforcement of classification policies at the egress point.
Mission DPS-R01 (Data Inventory and Mapping) is the prerequisite. You cannot define secure transfer requirements for data you have not inventoried. The data inventory identifies which data types require encrypted transfer, which trading partners exchange which types of files, and which legacy systems still rely on unencrypted protocols like plain FTP.
CDA's approach differs from conventional guidance in emphasis: most security frameworks treat file transfer as a technical control to configure and forget. The SDP methodology treats it as a continuous sovereignty enforcement point. File transfer logs feed into the TID (Threat Intelligence and Defense) domain for anomaly detection. Unusual transfer volumes, transfers at unusual hours, or transfers to new external endpoints are signals worth investigating, not background noise.
For Shield customers, CDA monitors file transfer behavior as part of the DPS ring assessment. A score that flags poor file transfer hygiene is typically driven by three findings: active use of plain FTP, no DLP inspection of file uploads to external systems, and no audit logging of file transfer activity.
CDA Theater missions that address topics covered in this article.
Data masking and tokenization are two distinct techniques for protecting sensitive data while preserving its operational utility.
Data retention is the formal policy governing how long an organization keeps specific categories of data.
Building and operating a DLP program that detects and prevents unauthorized data exfiltration across endpoints, networks, and cloud services.
Written by Evan Morgan
Found an issue? Help improve this article.