# SFTP vs FTPS
SFTP (SSH File Transfer Protocol) and FTPS (FTP Secure) are two distinct protocols for encrypted file transfer that solve the same fundamental problem: moving files securely across networks. Despite similar names and overlapping use cases, they represent fundamentally different approaches to encryption and network communication.
SFTP operates as a subsystem of SSH (Secure Shell), inheriting SSH's encryption, authentication mechanisms, and single-channel design. When you connect via SFTP, you are establishing an SSH connection that happens to carry file transfer commands rather than terminal commands. This architectural decision makes SFTP inherently simpler from a networking perspective: one port, one encrypted tunnel, one set of authentication credentials.
FTPS takes the opposite approach: it extends the existing File Transfer Protocol (FTP) with Transport Layer Security (TLS) encryption. This preserves FTP's multi-connection architecture while adding modern cryptographic protection. FTPS exists in two variants: Explicit FTPS, which begins as a plain FTP connection before upgrading to TLS (similar to STARTTLS in email), and Implicit FTPS, which encrypts from the moment of connection.
The protocols exist because different organizations approached the same problem from different starting points. SSH was developed in the mid-1990s as a secure replacement for Telnet and other plaintext protocols. File transfer capabilities were added to SSH because secure shell access often requires secure file transfer. FTPS emerged from the opposite direction: organizations with existing FTP infrastructure needed encryption without abandoning their investment in FTP-based processes and tooling.
This historical difference explains why SFTP and FTPS remain relevant today despite functional overlap. Organizations with heavy SSH usage naturally gravitate toward SFTP. Organizations with established FTP workflows, especially in mainframe or legacy environments, often choose FTPS to minimize operational disruption.
SFTP establishes a single encrypted connection over port 22, the same port used for SSH terminal access. Authentication can use SSH public/private key pairs, passwords, certificates, or multi-factor authentication systems that integrate with SSH. Once authenticated, the client and server communicate through the SSH channel using the SSH File Transfer Protocol, which defines commands for file upload, download, directory listing, permission changes, file deletion, and symbolic link creation.
The SFTP session begins with protocol negotiation. The client and server agree on an SFTP protocol version (currently version 3 through 6, with version 3 being most widely supported). The client can then issue commands like SSH_FXP_OPEN to open files, SSH_FXP_READ and SSH_FXP_WRITE for data transfer, and SSH_FXP_STAT for file information. All commands and responses travel through the same encrypted SSH tunnel, making network monitoring and firewall configuration straightforward.
SFTP supports advanced features including partial file transfers (useful for resuming interrupted downloads), file locking, and atomic operations that ensure file integrity during transfer. The protocol handles large files efficiently through windowing: the client can issue multiple read or write requests before receiving responses, improving throughput over high-latency connections.
FTPS operates differently because it inherits FTP's separation between control and data connections. The control connection handles commands and responses, while separate data connections carry actual file content. In Explicit FTPS, the client connects to port 21 and issues an AUTH TLS command to upgrade the control connection to TLS encryption. In Implicit FTPS, the client connects directly to port 990 (or another designated port) with TLS encryption active from connection start.
Data connection establishment in FTPS follows FTP's active and passive modes, but with encryption added. In active mode, the client tells the server which port to connect to for data transfer using the PORT command. The server then initiates a data connection back to the client. This requires the client to accept inbound connections, which often conflicts with firewall policies. In passive mode, the client issues a PASV command, and the server responds with an IP address and port for the client to connect to for data transfer.
FTPS must negotiate TLS parameters separately for control and data connections. The client and server can use different cipher suites for each connection type, and data connections may reuse TLS session parameters from the control connection for performance. Some FTPS implementations support data connection reuse, where a single encrypted data connection handles multiple file transfers rather than establishing new connections for each transfer.
Certificate verification in FTPS follows standard TLS practices, but presents operational challenges in automated environments. FTPS clients must validate server certificates, handle certificate chain verification, and often deal with certificate pinning or custom certificate authorities. This adds complexity compared to SFTP's integration with SSH key management.
Both protocols support bandwidth limiting, transfer logging, and access controls, but implement these features differently. SFTP access controls integrate with SSH authorization mechanisms, including forced commands that restrict users to specific operations. FTPS access controls typically integrate with the underlying FTP server's user management system.
Network address translation (NAT) significantly impacts FTPS because the protocol communicates IP addresses and ports in the application layer. FTPS clients and servers behind NAT often require additional configuration or ALG (Application Layer Gateway) support in network devices. SFTP's single-connection design eliminates these complications.
File transfer security directly impacts data protection obligations, operational efficiency, and incident response capabilities. Organizations transferring sensitive data face regulatory requirements that mandate encryption in transit, access logging, and data handling controls. Both SFTP and FTPS can meet these requirements, but implementation complexity affects security outcomes.
SFTP's architectural simplicity reduces configuration errors and security gaps. Network administrators can secure SFTP by hardening SSH configuration: disabling weak ciphers, enforcing key-based authentication, implementing connection limits, and configuring proper logging. The same SSH hardening that protects terminal access automatically protects file transfer. This convergence reduces administrative overhead and eliminates the security gaps that emerge when different services require separate hardening procedures.
FTPS introduces additional complexity that can undermine security objectives. Dynamic port allocation for data connections requires firewall configurations that either open broad port ranges or implement deep packet inspection to dynamically open required ports. Broad port ranges expand attack surface. Deep packet inspection adds latency and introduces a potential failure point. Certificate management for FTPS requires separate processes from SSH key management, increasing operational burden and the likelihood of expired or misconfigured certificates.
The multi-connection nature of FTPS creates opportunities for partial connection failures that can leak information or create inconsistent security states. If the control connection remains encrypted but data connection encryption fails, file content may transmit in plaintext while commands remain protected. SFTP's single-channel design eliminates this class of failure.
Performance characteristics differ significantly between protocols. SFTP performance is limited by SSH's encryption overhead and single-connection design. Large file transfers or high-concurrency scenarios may favor FTPS, which can parallelize data transfers across multiple connections. However, SFTP performance is predictable and scales linearly with connection resources, while FTPS performance depends on network infrastructure support for dynamic connections and may degrade unexpectedly when NAT or firewall resources become constrained.
Legacy system integration drives many FTPS implementations. Mainframe systems, industrial control networks, and established business-to-business file exchange relationships often require FTPS compatibility. These scenarios prioritize operational continuity over security optimization. Organizations should evaluate whether FTPS requirements reflect genuine technical constraints or institutional inertia that can be addressed through migration planning.
File transfer security spans the Data Protection and Sovereignty (DPS) and Security Posture and Hygiene (SPH) domains within the Planetary Defense Model. DPS addresses the fundamental question of where data lives and how it moves between authorized locations. SPH focuses on maintaining consistent security controls across infrastructure components.
CDA applies the Sovereign Data Protocol (SDP) principle that "Your data lives where you decide. Period." to file transfer protocol selection. Organizations must evaluate whether SFTP or FTPS better supports their data sovereignty requirements. SFTP's integration with SSH infrastructure typically provides stronger sovereignty controls because SSH key management and access controls are well-understood and widely implemented. FTPS certificate management introduces external dependencies on certificate authorities and certificate distribution mechanisms that may compromise data sovereignty in regulated environments.
During C-BUILD (Cybersecurity Build) missions, CDA operators frequently encounter FTPS implementations that persist solely due to legacy inertia rather than genuine technical requirements. These situations present opportunities for protocol migration that can simultaneously improve security posture and reduce operational complexity. CDA recommends SFTP migration assessments that evaluate existing FTPS usage patterns, identify genuine compatibility constraints, and develop transition plans that preserve operational capabilities while improving security outcomes.
The SPH domain encompasses file transfer protocol hardening as a standard deliverable in security posture assessments. CDA evaluates cipher suite selection, authentication mechanisms, access controls, and logging configurations for both SFTP and FTPS implementations. Common findings include weak cipher suites maintained for legacy compatibility, certificate verification bypassed in automated systems, and insufficient logging that impedes incident response.
CDA differs from conventional cybersecurity thinking by treating protocol selection as a data sovereignty decision rather than a purely technical choice. Most security frameworks evaluate SFTP and FTPS based on encryption strength, authentication options, and compliance checkbox requirements. CDA additionally considers how protocol selection affects an organization's ability to maintain autonomous control over data movement, respond to security incidents without external dependencies, and scale security controls as business requirements evolve.
The CDA methodology emphasizes that security posture improvements must align with operational reality. Organizations with strong SSH expertise and infrastructure should standardize on SFTP. Organizations with significant FTPS investments should focus on proper FTPS hardening while evaluating long-term migration strategies. Mixed environments require clear protocol selection criteria based on data classification, business process requirements, and risk tolerance.
• SFTP operates as an SSH subsystem using a single encrypted connection on port 22, while FTPS adds TLS encryption to FTP's multi-connection architecture, creating different network security and operational complexity profiles.
• SFTP simplifies firewall configuration and eliminates data channel exposure risks inherent in FTPS dynamic port allocation, making it the preferred choice for new implementations without legacy constraints.
• FTPS certificate management adds operational overhead compared to SFTP's integration with SSH key management, but may be required for mainframe integration or established business-to-business file exchange relationships.
• Both protocols require proper hardening including strong cipher suite enforcement, robust authentication mechanisms, access controls, and comprehensive logging, but SFTP hardening aligns with standard SSH security practices.
• Protocol selection should prioritize data sovereignty and operational sustainability over feature checklists, with SFTP generally providing better sovereignty controls and lower long-term operational complexity.
• SSH Security Fundamentals • Legacy System Security Integration • Certificate Management Best Practices • Data Protection and Sovereignty Implementation • Network Protocol Hardening Standards
• National Institute of Standards and Technology. "Guidelines for the Secure Deployment of IPv6." NIST Special Publication 800-119. 2010.
• Internet Engineering Task Force. "SSH File Transfer Protocol." RFC 4251-4254. 2006.
• Center for Internet Security. "CIS Controls Version 8." 2021.
• SANS Institute. "Securing File Transfer Protocol." SANS Reading Room. 2019.
• Internet Engineering Task Force. "FTP Security Extensions." RFC 4217. 2005.