What Is SFTP? How Secure File Transfer Protocol Works

SFTP is one of the most widely used protocols for transferring files securely between systems.

SFTP (SSH File Transfer Protocol) is a network protocol that provides secure file access, transfer, and management over an encrypted SSH connection. Unlike traditional FTP, SFTP encrypts both commands and data in transit, preventing passwords, file contents, and metadata from being intercepted. It is the standard protocol for automated file transfers in enterprise environments, cloud infrastructure, and regulated industries.

Whether you are receiving client data files on a recurring schedule, syncing datasets between internal systems, or delivering reports to external partners, there is a good chance SFTP is involved somewhere in the workflow. Despite the rise of APIs and cloud-native integrations, SFTP remains the backbone of B2B file exchange — and for good reason.

This guide explains what SFTP is, how it works under the hood, where it fits in modern data infrastructure, and what its limitations are at scale.

What is SFTP

SFTP is a secure file transfer protocol that runs over an SSH (Secure Shell) connection. It allows users and automated systems to upload, download, rename, delete, and manage files on a remote server — all within an encrypted session. Every byte of data, every command, and every authentication credential is protected in transit.

SFTP is not an extension of FTP. Despite the similar name, SFTP is a completely different protocol built from the ground up on SSH. FTP was designed in the 1970s without encryption. SFTP was designed in the 1990s with security as a core requirement. The two protocols are not compatible with each other.

What does SFTP stand for

SFTP stands for SSH File Transfer Protocol (sometimes called Secure File Transfer Protocol). The SSH prefix refers to Secure Shell, the cryptographic protocol that SFTP uses for authentication and encryption. Some documentation refers to SFTP as the SSH File Transfer Protocol to distinguish it clearly from FTPS (FTP over SSL/TLS), which is a different protocol entirely.

SFTP vs secure FTP: clearing up the confusion

The term "secure FTP" is ambiguous and causes frequent confusion. It can refer to SFTP (SSH-based), FTPS (FTP over TLS), or even FTP with a VPN wrapper. When someone says "we use secure FTP," you should always clarify which protocol they mean — the authentication methods, ports, and client configurations are completely different. In this guide, SFTP always refers to the SSH File Transfer Protocol.

How SFTP works

Understanding the mechanics of SFTP helps you configure it correctly, troubleshoot connection issues, and make informed decisions about security and performance.

The SSH connection layer

Every SFTP session starts with an SSH handshake. The client connects to the server on port 22 (the default SSH port), and the two systems negotiate encryption algorithms, exchange keys, and establish a secure channel. Only after this encrypted tunnel is established does the file transfer subsystem begin. This means SFTP requires only a single port — unlike FTP, which requires separate ports for commands and data.

Authentication methods

SFTP supports multiple authentication methods through SSH. Password authentication is the simplest: the client sends a username and password over the encrypted connection. SSH key authentication is more secure and widely used in automated workflows: the client holds a private key, and the server verifies it against a stored public key. Multi-factor authentication combines both methods. For production file transfers, SSH key authentication is strongly recommended over passwords.

Encryption and data integrity

SFTP encrypts all data in transit using the encryption algorithms negotiated during the SSH handshake — typically AES-256 or ChaCha20. Beyond encryption, SSH also provides data integrity verification using message authentication codes (MACs), which detect any tampering or corruption of data during transfer. This combination of encryption and integrity checking means that data cannot be read or modified by anyone intercepting the network traffic.

SFTP commands and operations

Once connected, SFTP supports a full set of file operations: uploading (put), downloading (get), listing directories (ls), creating directories (mkdir), renaming files (rename), deleting files (rm), and changing permissions (chmod). These operations are sent as binary packets over the encrypted channel, making SFTP more efficient than text-based protocols like FTP. Most SFTP clients and libraries abstract these commands behind a familiar file-system interface.

Why SFTP is widely used

Despite being decades old, SFTP remains the default choice for secure file transfers across industries. Several characteristics explain its persistence.

Common use cases for SFTP

SFTP appears in virtually every industry where files need to move between systems securely. Here are the most common scenarios.

Automated file transfers between systems

The most common use of SFTP in production environments is scheduled, automated file transfers. A system generates a file — a daily transaction report, an employee census, an inventory update — and drops it on an SFTP server. Another system picks it up, processes it, and loads the data into a database or application. This pattern runs millions of times daily across enterprises worldwide.

B2B data exchange with external partners

When two companies need to exchange data regularly but do not share an API, SFTP is the standard solution. One company provides SFTP credentials to the other, and files are uploaded or downloaded on an agreed schedule. This is particularly common in HR tech (payroll files from HRIS systems), financial services (transaction reconciliation), healthcare (claims and eligibility files), and supply chain (purchase orders and invoices).

Regulatory compliance and audit trails

Industries subject to data protection regulations — finance, healthcare, insurance, government — often mandate encrypted file transfers. SFTP satisfies this requirement inherently. Many organizations also configure SFTP servers to log all file operations (uploads, downloads, deletions) with timestamps and user identities, providing an audit trail for compliance reporting.

Cloud infrastructure and DevOps

DevOps teams use SFTP (or SCP, which is SSH-based) to transfer configuration files, deployment artifacts, database backups, and log files between servers. Cloud-managed SFTP services like AWS Transfer Family allow teams to expose S3 buckets or EFS file systems behind an SFTP endpoint, combining the familiarity of SFTP with cloud-native storage.

Data pipeline ingestion

Many data pipelines begin with an SFTP drop. External clients or partner systems upload CSV, Excel, or fixed-width files to an SFTP server. The pipeline detects new files, validates their structure, maps and transforms the data, and loads it into a target system. This is the core workflow that automated file feed platforms are built to handle.

SFTP vs other file transfer protocols

SFTP is not the only option for moving files between systems. Understanding the alternatives helps you choose the right protocol for each situation.

SFTP vs FTP

FTP (File Transfer Protocol) is the original file transfer protocol, designed in 1971. It transmits everything in plain text — including usernames, passwords, and file contents. FTP also requires two separate connections: a command channel (port 21) and a data channel (a dynamically assigned port), which creates firewall and NAT traversal complications. SFTP solves all of these problems: single port, full encryption, built-in authentication. There is no practical reason to use plain FTP in modern infrastructure.

SFTP vs FTPS

FTPS (FTP Secure) is FTP with a TLS/SSL encryption layer added on top. It encrypts the connection but retains FTP's dual-port architecture and all its associated complexity. FTPS requires managing TLS certificates (separate from SSH keys) and typically needs firewall rules for both the command port and a range of data ports. SFTP is generally simpler to deploy and manage. The main reason to use FTPS is when a legacy partner system supports only FTPS and cannot switch.

SFTP vs SCP

SCP (Secure Copy Protocol) also runs over SSH and provides encrypted file transfers. However, SCP only supports copying files — it does not support directory listing, file deletion, renaming, or resuming interrupted transfers. SCP is faster for simple one-off file copies but lacks the file management capabilities that make SFTP suitable for production workflows. Modern OpenSSH documentation recommends SFTP over SCP for most use cases.

SFTP vs HTTPS

HTTPS-based file transfer (REST APIs, pre-signed URLs, webhook-triggered uploads) is the modern alternative to SFTP for many integration scenarios. HTTPS is better suited for real-time, event-driven transfers and integrates naturally with web applications and microservices. SFTP is better suited for batch file transfers, scheduled workflows, and scenarios where the sending system expects to drop a file on a remote server. Many production environments use both: SFTP for incoming partner files, HTTPS APIs for real-time data delivery.

SFTP authentication in depth

Authentication is the most critical configuration decision in any SFTP deployment. The method you choose determines both security posture and operational complexity.

Password authentication

The simplest method: users authenticate with a username and password sent over the encrypted SSH channel. While the password is protected in transit, password-based auth is vulnerable to brute-force attacks and credential reuse. It also requires manual password distribution and rotation. Password authentication is acceptable for interactive use but should be avoided for automated production workflows.

SSH key authentication

SSH key authentication uses a public-private key pair. The client generates a key pair and shares the public key with the server administrator, who installs it in the appropriate authorized_keys file. During connection, the server challenges the client to prove it holds the corresponding private key — without the private key ever being transmitted. This is the recommended method for automated file transfers. Keys are stronger than passwords, cannot be brute-forced, and do not need to be shared between parties.

A typical key generation command looks like this:

ssh-keygen -t ed25519 -C "filefeed-production"

This generates an Ed25519 key pair — the current recommended algorithm, faster and more secure than RSA for new deployments.

Certificate-based authentication

For organizations managing hundreds of SFTP connections, SSH certificates offer a scalable alternative to individual key pairs. A certificate authority (CA) signs short-lived certificates that the server trusts automatically. This eliminates the need to distribute and manage individual public keys across servers. Certificate-based auth is common in large enterprises and cloud-native infrastructure.

Setting up an SFTP server

There are several approaches to running an SFTP server, depending on your infrastructure and operational requirements.

Self-hosted SFTP with OpenSSH

The most common SFTP server implementation is OpenSSH's built-in sftp-server subsystem, which is included in virtually every Linux distribution. Configuration is handled through the sshd_config file, where you can restrict users to specific directories (chroot), limit available commands, and control authentication methods. Self-hosted SFTP gives you full control but requires you to manage patching, monitoring, high availability, and storage capacity.

A basic chroot configuration looks like this:

Match Group sftpusers
  ChrootDirectory /data/sftp/%u
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

This restricts users in the sftpusers group to their own directory, disables shell access, and limits them to file transfer operations only.

Cloud-managed SFTP services

Cloud providers offer managed SFTP services that eliminate server management entirely. AWS Transfer Family provides an SFTP endpoint backed by S3 or EFS. Azure provides SFTP support directly on Azure Blob Storage. These services handle infrastructure, scaling, and availability — you configure users, authentication, and storage mapping. The tradeoff is cost: managed SFTP services charge per protocol, per hour, and per gigabyte transferred, which can add up at scale.

SFTP as a service platforms

Purpose-built SFTP platforms go beyond basic file transfer to add workflow automation, monitoring, and integration capabilities. These platforms handle the SFTP server infrastructure while also providing features like file validation, schema mapping, transformation, and delivery to downstream systems. This is the approach that SFTP file automation platforms take — combining the protocol layer with the data processing layer into a single managed service.

SFTP security best practices

SFTP is secure by design, but a misconfigured SFTP server can still expose your organization to risk. These best practices apply to any production SFTP deployment.

Use SSH keys over passwords

Disable password authentication for all automated and service accounts. SSH keys are not susceptible to brute-force attacks and do not need to be rotated as frequently. When key rotation is required, you can distribute new public keys without downtime by adding the new key before removing the old one.

Restrict user access with chroot

Chroot jailing confines SFTP users to a specific directory tree, preventing them from browsing or accessing any other part of the file system. This is essential when providing SFTP access to external parties. Each client should have their own chrooted directory with permissions that prevent them from seeing other clients' files.

Disable unnecessary SSH features

SFTP users should not have shell access, TCP forwarding, or X11 forwarding capabilities. Use the ForceCommand internal-sftp directive and disable forwarding options in your SSH configuration. This limits the attack surface to file operations only.

Monitor and log all file operations

Configure your SFTP server to log all authentication attempts, file uploads, downloads, and deletions. These logs are critical for security incident investigation, compliance auditing, and operational troubleshooting. In cloud environments, route SFTP logs to a centralized logging service like CloudWatch, Datadog, or Splunk.

Keep SSH software updated

SSH vulnerabilities are discovered periodically, and patches are released promptly. Running an outdated version of OpenSSH can expose your server to known exploits. Automate patching where possible and subscribe to security advisories for your SSH implementation.

SFTP in data pipelines

In many real-world data architectures, SFTP serves as the entry point for external data. Files arrive on an SFTP server and then flow through a series of processing steps before reaching their final destination.

A typical SFTP-based data pipeline follows this pattern: a client or partner uploads a CSV file to an SFTP server. A scheduled job detects the new file, validates its structure and content, maps the fields to the target schema, transforms the data as needed, and loads it into the destination system — whether that is a PostgreSQL database, a Snowflake warehouse, a S3 bucket, or an application API.

• File detection: Monitoring the SFTP directory for new files, typically via polling on a schedule (every 5 minutes, hourly, daily) or event-driven triggers in cloud environments.
• Validation: Checking that the file matches expected structure — correct columns, valid delimiters, expected row count, no corruption. Malformed files are quarantined and flagged for review.
• Mapping and transformation: Converting the file's column structure to match the target system's schema. This often involves renaming fields, converting data types, normalizing formats, and applying business rules.
• Loading: Inserting the processed data into the target system via bulk insert, API call, or file delivery to another SFTP endpoint.
• Audit and notification: Logging the processing result, notifying stakeholders of success or failure, and archiving the original file for compliance.

Building this pipeline from scratch requires significant engineering effort. Each step introduces error handling, retry logic, and monitoring requirements. Many teams invest weeks or months building SFTP ingestion infrastructure before processing their first production file.

Automating SFTP workflows

Manual SFTP operations — connecting with a client, uploading or downloading files by hand — work for occasional, ad-hoc transfers. But production data workflows require automation.

Script-based automation

The simplest automation approach is a shell script or Python script that connects to an SFTP server, transfers files, and handles basic error checking. Libraries like paramiko (Python), ssh2-sftp-client (Node.js), or phpseclib (PHP) provide programmatic SFTP access. Scripts are scheduled via cron, systemd timers, or task schedulers. This works for simple, single-source workflows but becomes difficult to manage as the number of sources, file formats, and error scenarios grows.

Orchestration tools

Workflow orchestrators like Apache Airflow, Prefect, or Dagster can manage SFTP transfer tasks as part of larger data pipelines. They provide scheduling, dependency management, retry logic, and monitoring dashboards. The SFTP transfer becomes one step in a multi-step DAG (directed acyclic graph) that includes validation, transformation, and loading. This is a good fit for teams that already use an orchestrator and have the engineering resources to maintain it.

Managed SFTP automation platforms

Purpose-built platforms combine SFTP hosting, file detection, validation, mapping, transformation, and delivery into a single managed service. Instead of building and maintaining each pipeline component separately, teams configure the entire workflow through a dashboard. This is the approach FileFeed takes with Automated FileFeeds — providing the SFTP endpoint, monitoring incoming files, validating and transforming the data, and delivering clean, normalized output to the target system.

SFTP limitations and challenges

SFTP is reliable and secure, but it has real limitations that affect how it can be used in modern data architecture.

No built-in file processing

SFTP handles file transfer only. It has no concept of file validation, schema mapping, data transformation, or delivery to downstream systems. Everything that happens after a file lands on the SFTP server must be built separately. This is the single biggest source of engineering overhead in SFTP-based workflows.

Polling-based file detection

SFTP does not natively support push notifications or webhooks. To detect new files, systems must poll the SFTP directory at intervals. This introduces latency (files are not processed until the next poll), wasted resources (polling when no files are present), and complexity (handling partial uploads, duplicate detection, and file locking).

Performance at scale

SSH encryption adds CPU overhead to every byte transferred. For very large files (multi-gigabyte) or very high transfer volumes, SFTP can become a bottleneck compared to unencrypted or optimized transfer protocols. In practice, this is rarely a problem for typical B2B file exchanges (megabytes to low gigabytes), but it can matter for large-scale data migration or media file transfers.

Credential management at scale

Managing SFTP credentials for dozens or hundreds of external partners is operationally complex. Each partner needs unique credentials, their own chrooted directory, appropriate permissions, and key rotation schedules. Without automation, credential management becomes a significant administrative burden and a potential security risk if keys are not rotated or revoked promptly.

SFTP port, connection, and configuration reference

Here is a quick reference for the most commonly needed SFTP configuration details:

• Default port: 22 (same as SSH). Can be changed in sshd_config but 22 is the universal default.
• Protocol: Binary protocol over SSH. Not compatible with FTP clients.
• Authentication: Password, SSH key (RSA, Ed25519, ECDSA), or certificate-based.
• Encryption: AES-256-CTR, AES-256-GCM, ChaCha20-Poly1305 (negotiated during handshake).
• Key exchange: Curve25519, ECDH, Diffie-Hellman (negotiated during handshake).
• Configuration file: /etc/ssh/sshd_config on Linux/macOS servers.
• Client tools: sftp (CLI), FileZilla, WinSCP, Cyberduck, Transmit.
• Programming libraries: paramiko (Python), ssh2-sftp-client (Node.js), JSch (Java), phpseclib (PHP).

Frequently asked questions about SFTP

Is SFTP the same as FTP?

No. SFTP and FTP are completely different protocols. FTP (File Transfer Protocol) transmits data in plain text and uses two separate connections (command and data channels). SFTP (SSH File Transfer Protocol) encrypts all data and commands over a single SSH connection. They are not compatible — an FTP client cannot connect to an SFTP server, and vice versa. The similar names cause widespread confusion, but the protocols share no underlying technology.

What port does SFTP use?

SFTP uses port 22 by default — the same port as SSH. This is one of SFTP's advantages over FTP, which requires port 21 for commands plus a range of additional ports for data transfer. Because SFTP uses a single port, firewall configuration is straightforward. The port can be changed in the server's SSH configuration if needed, though non-standard ports should be documented clearly for all connecting clients.

Is SFTP secure enough for sensitive data?

Yes. SFTP encrypts all data in transit using strong cryptographic algorithms (AES-256 or equivalent). It is approved for use in regulated industries and recognized by compliance frameworks including SOC 2, HIPAA, PCI DSS, and GDPR. For data at rest, you should additionally encrypt the storage where files are kept on the server side. SFTP protects data during transfer; disk encryption protects data at rest.

Can SFTP handle large files?

Yes. SFTP supports files of any size and can resume interrupted transfers. For very large files (multiple gigabytes), transfer speed may be affected by SSH encryption overhead and network conditions. Increasing the SSH buffer size and using high-performance cipher algorithms can improve throughput. In practice, SFTP handles typical B2B file transfers (CSV exports, report files, data feeds in the megabyte-to-low-gigabyte range) without performance issues.

How is SFTP different from FTPS?

SFTP runs over SSH and uses a single port (22). FTPS runs FTP over TLS/SSL and inherits FTP's dual-port architecture (command port + data port range). SFTP uses SSH keys for authentication; FTPS uses TLS certificates. SFTP is generally simpler to deploy and manage. FTPS is typically used only when a partner system requires it for legacy compatibility reasons.

The role of SFTP in modern data infrastructure

SFTP occupies a unique position in the data infrastructure landscape. It is not the newest protocol, nor the most feature-rich, nor the most performant. But it is understood by virtually every system that needs to exchange files securely, which makes it indispensable for B2B data exchange.

APIs are better for real-time, event-driven data transfer. Cloud-native object storage is better for internal data workflows. But when an enterprise client says "we will send you a file every day" — and they have been doing it this way for a decade — SFTP is the protocol that makes it work. It is the universal adapter for secure file exchange.

Where SFTP falls short is not in the transfer itself, but in everything that happens after the file arrives: validation, mapping, transformation, error handling, and delivery. These post-transfer operations are where most engineering time is spent, and where automation delivers the most value.

Understanding SFTP — its strengths, limitations, and role in the broader data pipeline — is essential for any engineer, architect, or data team working with file-based integrations.