What is SFTP?

SFTP is also called Secure File Transfer Protocol. This name can be misleading because it suggests an encrypted version of FTP. That is FTPS, which adds TLS encryption to FTP. ^[3] SFTP is a separate protocol based on SSH. When configured correctly, it provides secure file transfers and protects credentials and file contents against eavesdropping and tampering. ^[1]

SFTP at a glance

The distinction between the file-transfer protocol, its encrypted connection and the storage behind the server matters throughout this guide. ^{[1] [3]}

What is SFTP used for?

SFTP can be used to exchange files between people, applications and devices. You can access it through a graphical program, from the command line in a terminal, or automatically through a script. WinSCP, for example, is a graphical SFTP client for Windows. You can browse folders on the server, upload and download files, and rename or delete them.

Consider a few possible workflows:

Important to know: SFTP only handles file transport here and contains no business logic. The receiving application must validate and process the data. ^[4]

Backup programs can also use SFTP to store backups on a remote server. One option is restic.

How does SFTP work?

SFTP uses an encrypted SSH connection to transfer files. The client starts the connection, and the server checks which files and folders the user is allowed to access.

A connection has several stages

1. The client reaches the server. It opens a TCP connection to the configured hostname and port. Network rules must allow that connection.

2. SSH protects the connection. The client and server establish an encrypted SSH connection. The client must verify the server’s host key to ensure it is connecting to the right server. ^[1]

3. The user signs in. The server verifies the user’s identity using a password, an SSH key, both or another configured SSH method. ^[2]

4. The SFTP session begins. The client can now transfer files and browse folders. The server checks permissions for each action. ^[4]

OpenSSH can restrict a user to SFTP without shell access. SSH forwarding must be restricted separately. ^[2]

Which port does SFTP use?

SFTP normally uses TCP port 22. If the server uses another port, the client must use it too. Selecting port 22 does not make an FTP-only client support SFTP. ^[4]

File operations and data use one SSH connection, so no separate data ports are needed. Firewall rules should allow only the required connections from client to server and their replies. The client does not need to accept incoming SFTP connections.

SFTP vs. FTP vs. FTPS

FTP, FTPS and SFTP all transfer files, but work differently. FTP sends data without encryption, while FTPS adds TLS encryption to FTP. SFTP is a separate protocol that transfers files over an encrypted SSH connection.

FTPS must encrypt both control and data connections. The client’s mode—explicit or implicit—must match the server. ^[3]

SFTP and FTPS are incompatible. ^{[3] [4]} A service such as the Sync FTP/FTPS to SFTP Bridge connects local FTP/FTPS systems to Sync Motion storage over SFTP.

Both SFTP and FTPS provide secure transfers when configured correctly. The choice depends on which protocols the systems support.

SFTP vs. SSH

SSH provides secure connections for remote commands and other services. SFTP uses SSH for file access and transfers. SSH access does not automatically include SFTP. ^[2]

SFTP vs. SCP

Since version 9.0, OpenSSH’s scp command has used SFTP by default. The -O option selects the older SCP protocol; other implementations and older versions may differ.

What are an SFTP client and an SFTP server?

An SFTP client uploads and downloads files, manually or automatically. The server provides files and folders and checks the user’s access permissions. ^[4]

OpenSSH provides the sftp command for terminal use. FileZilla Client and Cyberduck offer graphical interfaces. Check SFTP support in the application and edition you choose.

Servers can also use object storage, which may affect permissions, timestamps, renaming and the ability to resume interrupted transfers. ^[5]

How SFTP authentication works

The client verifies the server; the server verifies the user.

Verify the server’s host key

Compare the host-key fingerprint with a trusted source, such as an authenticated provider dashboard or a verified administrator. Confirm any later key change independently before accepting it.

Authenticate the user

SSH encrypts passwords in transit, but stolen or reused passwords remain a risk.

With SSH-key authentication, the server stores the public key. The client proves it holds the private key without sending it. These keys are separate from the server’s host key and the connection’s encryption keys. The server can require both an SSH key and a password. ^[2]

Protect private keys with restrictive file permissions and, where suitable, a passphrase. For automation, use a managed SSH agent or secret store. Keep secrets out of source code and give each integration its own user so access can be revoked separately.

How to connect to an SFTP server

Get the hostname, port, username, authentication details, permitted directory and host-key fingerprint from your provider. Check that your client supports the required authentication. Replace the example values with your own.

Connect from a terminal

With OpenSSH installed, use the commands below. -P sets the port; -i selects the private key. Verify the host key before accepting the connection. ^[6]

sftp integration@sftp.example.com

For a different port and private key:

sftp -P 2222 -i ~/.ssh/sftp_partner integration@sftp.example.com

After login:

Connect with a graphical client

Select SFTP and enter the host, port, username and required password, SSH key or both. Verify the host-key fingerprint before trusting the server.

For either method, use existing directories with the required permissions. Start with a non-sensitive test file and check uploads and downloads. ^[6]

How to automate SFTP reliably

An automated transfer can stop before the file is complete. Even a successful upload does not mean the receiving application has processed it. The workflow must therefore prevent incomplete imports, handle failed transfers and check processing separately.

The example below uploads files under a temporary name and renames them when complete. The server must support this renaming, and the receiving application must ignore temporary files.

Keep incomplete files out of the import process

/incoming must exist and be writable. The export must be complete and remain unchanged during upload. The receiving application must ignore .part files. Save the transfer commands as upload.sftp.

put /srv/exports/orders-20260912-001.csv /incoming/orders-20260912-001.csv.part
rename /incoming/orders-20260912-001.csv.part /incoming/orders-20260912-001.csv
bye

Run it with:

sftp -b upload.sftp \
  -oBatchMode=yes \
  -oStrictHostKeyChecking=yes \
  -i ~/.ssh/sftp_partner \
  integration@sftp.example.com

-b reads the command file and stops the batch if put or rename fails. BatchMode=yes prevents authentication prompts; StrictHostKeyChecking=yes rejects unknown or changed host keys. ^[6]

Before running the batch, store the verified host key in known_hosts and make the private key available without prompting, for example through an SSH agent.

Check rename behavior on the actual backend

Renaming is only a reliable completion signal if the file appears under its final name in one step. Check whether the server and storage support this, especially with object storage.

Otherwise, use a completion signal supported by the provider, such as a separate ready file. Create it only after the upload succeeds, and configure the receiving application to wait for it. ^[5]

Make retries and processing outcomes explicit

For the example integration, give every export a unique identifier. The filename above is illustrative, not a name to reuse for every run. Decide what happens when a completed identifier already exists; blindly overwriting it is not a retry policy.

A sensible job design would record the filename, transfer result and attempt count; use timeouts and bounded retries; alert when expected files fail to arrive; and keep failed exports available for investigation. The receiver should record processed identifiers so a repeated delivery does not create duplicate orders. These are application-level design recommendations, not SFTP guarantees.

Keep two outcomes separate: the file arrived and the application accepted it. In this example, an acknowledgment record or a processed/rejected folder can make that distinction visible. Define a retention policy rather than immediately deleting the only source copy after upload.

Resume only the same file version

Some clients can continue interrupted transfers. Resume is safe only when the partial destination corresponds to the same source version. Continuing a changed export can combine old and new contents. For batch integrations, create an immutable export first; use end-to-end checksum verification where the participating tools support it.

Is SFTP secure?

SFTP's security depends on the SSH implementation, configuration, credentials and endpoints. Using a security protocol does not remove the need to maintain the software that implements it. OpenSSH's published security advisories are a reminder to use supported versions and apply relevant fixes.

Encryption in transit is not encryption at rest

The encrypted connection protects the journey between client and server. It does not, by itself, promise encrypted disks, protected backups or files that the server operator cannot read. Those protections must be designed separately.

When files must remain encrypted even on the receiving server, use appropriate file-level encryption in addition to transport security. OpenPGP is one example of a format providing encryption and signatures for the payload itself. That introduces separate key-management and recipient-access responsibilities.

Limit the damage a credential can cause

Use separate identities for separate integrations and restrict each to the data and operations it needs. Protect and rotate secrets, revoke abandoned access and retain useful audit records without logging credentials. An account that only needs to deliver reports should not automatically receive access to every customer's files.

For self-hosted OpenSSH, explicitly configure file-only access and any required directory isolation. Restrict forwarding and other unnecessary capabilities separately. A writable upload directory may need to sit below a protected chroot directory rather than making the chroot root writable. These are server-administration controls, not automatic SFTP properties. ^[2]

An IP allowlist can be an additional access restriction where available, but it is not a replacement for authentication. Likewise, virus scanning, storage retention and backup recovery are separate features to evaluate rather than assumptions to attach to the word “SFTP.” Sync Motion's own hosting page distinguishes plan-level controls such as IP allowlisting and audit logs from the basic service.

Does SFTP make a system GDPR- or HIPAA-compliant?

No protocol makes an entire organization or workflow compliant. GDPR Article 32 addresses a wider set of risk-appropriate safeguards, including availability, restoration and evaluation. The HIPAA Security Rule also includes administrative, physical and technical safeguards. SFTP may form part of a protected transfer workflow, but access policies, contracts, retention, hosting and operating procedures still need their own assessment. ^{[7] [8]}

SFTP limitations and compatibility

Performance depends on the workload

There is no universal answer to whether SFTP is faster or slower than another transfer method. Throughput depends on network latency and bandwidth, CPU capacity, storage performance and the client's request behavior. Transferring many small files is a different workload from transferring one large archive.

Benchmark representative files over the actual connection. Do not disable security checks or choose obsolete cryptography merely to improve a synthetic transfer result.

File operations are not identical everywhere

An endpoint that accepts uploads may not support every permission change, timestamp update or filesystem operation your client attempts. With AWS's S3-backed service, for example, a SETSTAT operation can fail because the requested metadata behavior is unsupported. An apparent error after upload therefore needs investigation: did the file transfer fail, or did a subsequent metadata operation fail? ^[5]

SFTP version numbers are separate from SSH versions

A server reporting SFTP version 3 is not saying that it uses “SSH version 3” or obsolete encryption. OpenSSH documents SFTP version 3 with additional extensions. SSH handles the choice of encryption method separately.

The SFTP specification developed through Internet-Drafts; do not describe an expired SFTP draft as a finalized IETF standard. For compatibility, the implemented operations and negotiated extensions matter more than assuming a larger version number is always better.

When should you use SFTP instead of an API or MQTT?

Choose according to the exchange you need, rather than treating one protocol as a universal upgrade.

For a file handoff, SFTP can be a suitable interface when both sides already support file-based exports and imports. The file format and processing contract still need agreement.

For request-and-response application behavior, consider an HTTPS API. An API can return structured validation results or expose application-specific operations. APIs can transfer files too; the distinction is the interface you need, not “files versus no files.” HTTP defines the request/response semantics on which such interfaces can be built.

For event and telemetry distribution, consider MQTT's publish/subscribe model. In an industrial design, that might mean MQTT for status changes and measurements, while SFTP carries completed reports or diagnostic bundles. The protocols can serve different parts of the same system.

A managed file transfer platform is another category: it can combine transfer protocols with workflow and operational features. It is not a separate name for the SFTP protocol itself. Evaluate the actual capabilities rather than assuming that an SFTP endpoint includes a workflow engine.

Self-hosted SFTP or managed SFTP hosting?

With a self-hosted setup, your team takes responsibility for the server deployment and operating controls. With a managed service, the provider operates an agreed portion of that infrastructure. The boundary varies: a managed transfer service can, for example, connect to storage and identity components that remain under your control.

For an evaluation, ask who owns patching, account provisioning, key revocation, storage, monitoring, backups and incident response. Check which responsibilities remain yours instead of assuming “managed” means no administration.

Test the behavior your integration actually needs: authentication, folder isolation, large files, retries, metadata changes, rename semantics and access logs. Ask about quotas, transfer charges, retention and recovery commitments. A successful test upload is a useful start, not a complete acceptance test.

For a team that already operates this infrastructure, self-hosting may fit its requirements. For a team that mainly needs a stable file-transfer endpoint, a managed service is worth evaluating. The decision should account for operating work, not just the server's monthly price.

Common SFTP errors and what to check

Treat these as starting points for diagnosis, not proof of one specific cause. Endpoint reachability, authentication and file permissions are different failure stages. AWS's connectivity guidance and the OpenSSH configuration documentation cover the underlying connection and trust checks.

Record the precise error and the stage at which it occurs. “Cannot connect” and “cannot write this file” need different investigations. During troubleshooting, preserve host-key verification rather than making every unknown endpoint trusted.

The practical takeaway

SFTP provides encrypted file transfer through SSH. The protocol is only one part of a dependable integration: server identity, account permissions, completion handling and business acknowledgments deserve equal attention.

Need an endpoint without operating the server yourself? Sync Motion offers managed SFTP hosting in Germany and the United States. Choose a region, check the features your workflow requires and test with your existing client before moving production transfers.

Sources

Sources checked during research on September 12, 2026.

Footnotes

1. RFC 4253 — The Secure Shell (SSH) Transport Layer Protocol. https://www.rfc-editor.org/rfc/rfc4253.html ↩ ↩² ↩³ ↩⁴

2. OpenBSD/OpenSSH — sshd_config(5). https://man.openbsd.org/sshd_config.5 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. RFC 4217 — Securing FTP with TLS. https://www.rfc-editor.org/rfc/rfc4217.html ↩ ↩² ↩³ ↩⁴

4. WinSCP — SFTP protocol. https://winscp.net/eng/docs/sftp ↩ ↩² ↩³ ↩⁴ ↩⁵

5. AWS Transfer Family — Transferring files over a server endpoint using a client. https://docs.aws.amazon.com/transfer/latest/userguide/transfer-file.html ↩ ↩² ↩³

6. OpenBSD/OpenSSH — sftp(1). https://man.openbsd.org/sftp.1 ↩ ↩² ↩³

7. EUR-Lex — Regulation (EU) 2016/679, including Article 32. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng ↩

8. U.S. HHS — Summary of the HIPAA Security Rule. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html ↩