SFTP Encryption: Is SFTP Encrypted, What SSH Protects, & What Auditors Expect

Is SFTP encrypted, and how does SFTP encryption work?

This question is usually asked as a data compliance or business security concern, so it’s about more than just whether the protocol has “secure” in its name or “is encrypted”. The hidden question is about the extent and reliability of that encryption. It’s about:

• Whether the data is protected while it moves across the network.
• Whether logins and file contents are hidden from anyone watching the traffic.
• Whether the setup can fall back to weaker settings without anyone noticing.
• Whether you can prove what happened later, not just assume it.

That leads to the mechanics question: “how does SFTP encryption work” from the moment a connection opens to the moment the first file is read from or written to.

SFTP is the file-transfer command layer (list, upload, download, rename, delete). The encryption doesn’t come from SFTP itself. It comes from SSH, which creates the secure connection first. Once the SSH handshake finishes, the entire SFTP session is secure and protected in transit: logins, commands, directory listings, and file data.

What is SFTP encryption?

SFTP encryption is provided by SSH. When a transfer client connects, SSH performs a “handshake” to agree on cryptographic algorithms, runs a key exchange (like Diffie-Hellman or Curve25519) to derive symmetric session keys, verifies the server using an SSH host key or host certificate, and then encrypts and integrity-protects all SFTP commands and file data for the life of the session.

How the pieces fit together: SFTP → SSH → encryption algorithms → compliance evidence

• SFTP is the file transfer part: it sends file commands and file bytes.
• SSH is the security part: it creates the encrypted session that SFTP travels through.
• SSH is where encryption algorithms and integrity mechanisms are chosen (for example AES-GCM or ChaCha20-Poly1305, with integrity provided by AEAD or by HMAC in older modes).
• Compliance and audit reviews usually require proof of encryption, meaning proof of your enforced configurations plus logs that show identity, activity, and even the negotiated security outcome.

The SSH handshake that makes SFTP encrypted

Before any file transfer starts, SSH runs a setup process called the handshake. This is the part that turns a plain TCP connection into an encrypted session.

Step 1: Version and algorithm exchange

The client and server exchange version strings (or identifiers) and then share (to collate) ordered lists of supported algorithms. SSH doesn’t pick one item and move on. It selects a full set of compatible choices, typically including:

• Key exchange (KEX) algorithm.
• Host key algorithm (how the server proves it is the right server).
• Session cipher (how data is encrypted in transit).
• Integrity mechanism (AEAD integrated integrity, or a separate MAC in older setups).
• Optional compression settings.

This is the point at which “what encryption does SFTP use” becomes specific to your environment. The real answer depends on what your chosen managed or self-hosted SFTP server allows and what the chosen client is capable of negotiating.

Step 2: Key exchange to derive shared secret material

Next, SSH runs a key exchange. This is needed because the fastest encryption for file traffic uses shared symmetric keys, but the client and server have to agree on those keys over the internet without ever sending them directly.

During key exchange, each side creates a temporary private value, shares only the matching public value, and then uses its private value plus the other side’s public value to compute the same shared secret. Anyone watching the network can see the public values but can’t calculate the shared secret without a private value. 

SSH then turns that shared secret into the symmetric session keys used to encrypt the SFTP session and verify packet integrity. If the exchange is ephemeral, new temporary values are used for each connection, so captured traffic from an older session stays protected even if a long-term key is compromised later.

What is SSH key exchange?SSH key exchange is the handshake step where the client and server generate shared secret material without sending session keys over the network. That secret is then used to derive symmetric keys that encrypt and integrity-protect the SFTP session.

Step 3: Server identity proof using the SSH host key

Encryption doesn’t automatically mean you reached the intended endpoint. An attacker can sit in the middle and create two encrypted sessions, one with the client and one with the server, and relay traffic between them. SSH defends against this “man in the middle” attack by requiring the server to prove it holds the private half of its host key during the handshake.

The client verifies that proof using a trusted host key or a host certificate chain. How trust is established depends on the model you use:

• Trust on first use (TOFU): the client accepts the server’s host key on the first connection and warns if that key changes later.
• Pinned host keys: the client is preloaded with the expected host key fingerprint, so the first connection is checked too.
• SSH host certificates: the client trusts a certificate authority (CA) and validates the server’s host certificate, rather than storing individual host keys.

If host key verification is ignored, SFTP can still be encrypted, but it may be encrypted to the wrong server.

Step 4: Session keys are derived and the connection switches into protected mode

Once key exchange completes and the server identity check succeeds, both sides derive symmetric session keys from the shared secret and start protecting packets of data. From this point onward, SSH applies the negotiated session cipher and integrity mechanism to the session.

Two details that matter when explaining or documenting controls for compliance:

• Separate keys per direction: client-to-server and server-to-client use different keys.
• Rekeying: long-lived sessions can refresh keys during the connection.

Step 5: User authentication and the SFTP subsystem

Only after SSH has switched the connection into encrypted mode does the program you’re using to connect, meaning your SFTP client (for example WinSCP, OpenSSH sftp, or an automated script), authenticate as a specific user.

Once the server accepts that login (password or SSH key, depending on your setup), the SFTP client opens an SSH channel and asks the server to start the SFTP subsystem. That subsystem is simply the server-side SFTP service running inside the same SSH session.

From that point on, every SFTP command and every byte of file data travels inside encrypted SSH packets. SFTP isn’t switching encryption on or off. It is using the protected session SSH already set up.

Key exchange: Diffie-Hellman and Curve25519

These are the key exchange names that show up in SSH server configs, client capability lists, and partner security questionnaires, so it helps to describe them in plain terms without losing accuracy.

Diffie-Hellman (DH) is the older family you will still see widely. Each side generates a private value and a public value, trades public values, and computes the same shared secret locally. Someone watching the network can record every packet and still cannot compute the shared secret without a private value.

Curve25519 is a modern elliptic-curve method used in many SSH stacks (often shown as curve25519-sha256). The sha256 label refers to hashing used during key exchange and key derivation, not the session cipher that encrypts the file data.

Two practical factors determine whether key exchange helps you the way you expect:

• Ephemeral key exchange: If the key exchange uses fresh, temporary values for each connection, each session gets unique key material. That supports forward secrecy, meaning a compromise later should not automatically expose captured traffic from older sessions.
  
• Downgrade paths: If you leave legacy key exchange options enabled for compatibility, a client can negotiate those older options. That expands the set of possible outcomes, sometimes without anyone noticing, and can undermine the security level you think you are enforcing.

Cipher negotiation and what gets protected

Cipher negotiation is where the connection settles on the exact algorithms it will use for this session. SSH takes the client and server capability lists from Step 1, selects a compatible set (key exchange, host key algorithm, session cipher, integrity), derives the session keys, and then starts protecting traffic.

Two details are important  here:

• SFTP doesn’t choose the cipher. SSH chooses it, based on what the server allows and what the client supports. That means the negotiated cipher is an outcome of configuration plus client capability, not a fixed property of “SFTP” as a protocol.
• SSH enforces confidentiality and integrity. Confidentiality prevents anyone on the network from reading logins, commands, directory listings, or file data. Integrity detects tampering in transit. Older configurations use a separate MAC (often HMAC-based). Modern configurations use AEAD ciphers where integrity checks are built in.

MAC vs AEAD, what’s the difference?A MAC (Message Authentication Code) is a keyed integrity check that detects tampering in transit. AEAD (Authenticated Encryption with Associated Data) combines encryption and tamper detection, so altered packets fail verification.

Session encryption and integrity in the simplest terms

After the handshake completes, every SFTP command and every byte of file data travels inside encrypted SSH packets. At this point, encryption’s already on, so the focus shifts to how SSH keeps the session private and makes sure nobody can secretly alter traffic in transit.

If you’re documenting SFTP encryption for compliance reviews and audits, these are the details that you’ll need to cite:

• Packet integrity checks: each packet is verified, so tampered packets fail verification and get rejected.
• Replay resistance: SSH uses sequence numbers, so captured packets can’t just be replayed later as if they were fresh traffic.
• Rekeying: long sessions can refresh keys during the connection, which limits how much data is protected under one key set.

That’s the crux of how SFTP encryption works: SSH negotiates the cryptography, proves the server identity, derives keys, then encrypts and integrity-protects the session that carries SFTP.

What encryption algorithms does SFTP use, and what else needs to get locked down?

What encryption does SFTP use?

SFTP uses the encryption negotiated by SSH. Common modern SSH session ciphers include AES-GCM (AES-256-GCM or AES-128-GCM) and ChaCha20-Poly1305. Integrity is provided either by AEAD modes (encryption that also detects tampering) or, in older SSH setups, by a separate HMAC (a keyed integrity tag checked on every packet).

In practice, SFTP doesn’t “use” one fixed encryption algorithm. It runs inside SSH, and SSH negotiates an algorithm set for each session. So what you end up with depends on two things: what the server permits and what the client can negotiate. That’s why a statement like “SFTP uses AES-256” only holds if your server configuration restricts negotiation to an approved list of modern options (an allow-list).

To answer this question, we’ll need to cover all the “possibles”:

Session ciphers you’ll usually see today

Modern SSH configurations often prefer authenticated encryption because it provides confidentiality and tamper detection together. Common modern session ciphers include:

•  AES-256-GCM and AES-128-GCM
•  ChaCha20-Poly1305

Older environments may still negotiate non-AEAD ciphers (such as AES-CTR) paired with a separate MAC (such as HMAC-SHA-256). That can be acceptable, but it increases the number of combinations you must control and explain, and it makes it easier for older clients to steer sessions into outcomes you didn’t intend.

AES-256-GCM vs AES-128-GCM

Both are modern and widely considered strong. In real systems, the choice is usually driven by policy language, client compatibility, and performance under load.

• AES-128-GCM: often slightly faster on some systems and still a strong modern option.
• AES-256-GCM: commonly preferred because standards and partner questionnaires explicitly ask for 256-bit encryption.

A practical, defensible posture is to allow both, order preferences intentionally, and remove legacy fallbacks so older clients cannot push sessions into weaker modes. 

While a strong option, the main risk to mention here is nonce reuse. With GCM, reusing a nonce with the same key is a catastrophic failure that can break confidentiality and integrity. In practice, the bigger danger is usually implementation error or downgrade exposure, not AES-128 versus AES-256 itself. 

ChaCha20-Poly1305

ChaCha20-Poly1305 is also authenticated encryption. It often comes into play when hardware varies or when smaller cloud instances don’t have consistent AES acceleration. In those environments, ChaCha20 performance is often steadier and easier to predict under concurrency.

Risk-wise, this is another strong option, but like GCM, risk comes with misuse of nonces, implementation failure, or weaknesses in surrounding components rather than practical cipher issues, but in SSH it’s also worth naming the Terrapin attack. 

Terrapin, or CVE-2023-48795, showed that SSH sessions using ChaCha20-Poly1305 could be exposed to handshake message truncation and security downgrade under affected conditions. 

SHA-256 and SHA-512: where they fit

SHA-256 and SHA-512 are hashing functions. In SSH they usually appear inside other mechanisms, not as the cipher that encrypts file data. Common roles include:

• Key exchange and key derivation steps (for example, curve25519-sha256)
• HMAC integrity checks in non-AEAD setups (for example, HMAC-SHA-256)

In terms of risks, again, the issue is usually misuse, not a practical break of SHA-256 or SHA-512 in SSH. Plain SHA-2 has a length-extension property, which is one reason secure protocols use it inside safer constructions such as HMAC or defined key-derivation steps rather than treating a raw hash as protection on its own.

Weak ciphers to disable (RC4, 3DES, CBC)

If you want predictable security outcomes and to stay compliant, don’t leave legacy options enabled on primary endpoints. The usual candidates to remove are:

• RC4
• 3DES
• CBC-mode ciphers (including AES-CBC)

If you must support legacy clients, isolating them on separate endpoints keeps your main endpoint hardened and makes monitoring cleaner.

SFTP authentication methods

Encryption protects the channel. Authentication decides who can use it. Many SFTP incidents come from weak authentication, unmanaged keys, or overbroad permissions rather than from cipher selection.

Common SSH authentication methods include:

• Password authentication: easy to deploy, but hard to defend at scale. If enabled, pair it with rate limits, lockouts, IP restrictions, and monitoring.
• Public key authentication: the baseline for automation and a strong option for human access when key lifecycle is managed.

Public and private keys, in case you’re still not sure

A key pair is two linked values or keys:

• Private key: stays with the client. If it leaks, access has leaked.
• Public key: stored on the server and used to verify signatures.

During authentication, the client proves possession by signing a challenge with the private key. The server verifies the signature using the stored public key. The private key never needs to cross the network, which is one reason key-based authentication is common for SFTP automation.

The operational burden then shifts to lifecycle management: issuing keys, storing them safely, rotating them, and removing them when access should end.

Multi-factor authentication (MFA) and what works with SFTP

Most automated SFTP jobs can’t handle an interactive MFA prompt, so MFA needs to be implemented where it actually applies.

Approaches that usually survive scrutiny during audits:

• Admin access: Require MFA for the management portal where users, SSH keys, permissions, endpoints, and audit log exports are handled.
• Human interactive access: Put MFA in front of manual access using a bastion/jump host or access broker, then allow SFTP onward under tight rules (often time-limited).
• Automation: Use SSH public keys (avoid password-only logins), keep permissions narrow, restrict network access (IP allow-lists or private networking), rotate keys, and alert on unusual transfer patterns.

Encryption at rest and why SFTP is not part of it

SFTP encrypts data in transit. Once a file lands on storage, encryption at rest is handled by the storage layer and its key controls.

SFTP encryption in transit vs encryption at rest

Encryption in transit protects data while it moves across networks. SFTP encryption in transit is provided by SSH session encryption and integrity checks. Encryption at rest protects stored data on disks, volumes, snapshots, backups, and object storage, and is enforced by the storage system and its key management controls.

Common at-rest controls include:

• Filesystem or volume encryption: LUKS (Linux) and BitLocker (Windows) protect data if disks or detached snapshots leak.
• Storage-layer encryption with managed keys: Common in cloud object and block storage, including Amazon S3 for object storage, where encryption at rest is enforced at the storage layer and governed by key management controls.

In terms of compliance and risk management, encryption at rest reduces risk if media or snapshots leak, but it does not stop someone who already has valid access from reading and exporting data. That is why access controls, auditing, and monitoring are all part of a healthy data management system.

SFTP is transport security, not data governance

SFTP encryption is strong transport security. It protects data while it moves between endpoints. In regulated workflows, the next question is usually accountability: who accessed what, what changed, what was retained, and what evidence exists.

SFTP provides encryption in transit by running inside SSH, but it does not provide governance by itself. Governance controls such as audit trails, retention, policy enforcement, monitoring, and evidence export must be implemented around SFTP. 

A great way to do this without complication is by using a strong managed file transfer solution (MFT) that incorporates these controls and facilitates data compliance.

SFTP encryption: compliance implications for GDPR, HIPAA, FERPA, GLBA, and SOC 2

Encryption supports confidentiality expectations under all of these, but none treat encryption as the complete control story.

• GDPR: SFTP encryption protects personal data in transit, but reviews also focus on least privilege, retention discipline, and evidence of handling and breach response readiness.
• HIPAA: SFTP can support transmission security for ePHI, but HIPAA programs also require audit controls, access management, and evidence that safeguards operate over time.
• FERPA: Encrypting education records in transit helps, but FERPA expectations also include controlled access and accountability around disclosure.
• GLBA: Encryption helps protect customer information, but GLBA reviews emphasize access controls, monitoring, vendor oversight, and proof that safeguards are applied consistently.
• SOC 2: Encryption in transit and at rest is common, but SOC 2 evidence often centers on identity, change history, monitoring, incident response, and audit trails tied to systems and people.

Audit-ready SFTP logging 

SFTP encryption may be  strong, but without detailed logging and consistent monitoring it’s hard to prove what happened. In practice, evidence and reliability are part of security and essential for compliance.

Audit-ready SFTP logging ties identity to activity and change-history. It captures authentication, sessions, file operations, and administrative actions with timestamps, retention, and export paths suitable for investigations and compliance evidence.

Logging you need, and it should be exportable:

• Authentication events: success and failure, lockouts, source IPs, key fingerprints.
• Session metadata: connect and disconnect, negotiated algorithms when available.
• File operations: upload, download, delete, rename attempts, permission failures.
• Administrative actions: user creation, key changes, permission changes, configuration changes.
• Correlation fields: partner identifiers, job IDs, transfer identifiers to trace retries and duplicates.

Encryption key management

Another topic that comes up in regulated data management audits is your key management policy. Encryption claims become much more convincing when key control is obvious. Reviewers usually look for:

• Provider-managed vs customer-managed keys.
• Key rotation and revocation practices.
• Logged, reviewable key policy changes.
• Coverage across replicas, backups, and exports.

Enterprise SFTP encryption in practice: performance, tuning, and controls in managed file transfer systems

Enterprise level transfer security and compliance is all about keeping outcomes consistent across partners, across clients, and under load, while still being able to show evidence later.

Enterprise transfer security usually doesn’t fail because SSH can’t encrypt. It fails because encryption outcomes aren’t enforced consistently across the network, and because it’s hard to prove exactly what happened later without stitching together logs from multiple places.

Enterprise encryption challenges

• Different algorithms across partners and tools: One legacy client, one permissive allow-list, or one “temporary” exception can change what gets negotiated in practice The session is still encrypted, but not necessarily to the standard that policies, questionnaires, or risk teams assume.
• Key-sprawl and messy offboarding: SSH keys scale well, but they also linger. Without a strict lifecycle, old keys become long-lived access paths that add risk.
• Policy vs. uptime pressure: In self-hosted transfer settings, teams under pressure can sometimes widen cipher and key exchange options to stop breakage, then never tighten them again. 
• Evidence gaps: Identity and file activity aren’t captured in a consistent, exportable way across endpoints. That turns audits and incident response into manual reconstruction with all sorts of gaps.

Performance and cipher cost in real workflows

Encryption has a CPU cost, but it’s rarely the only driver of transfer time. A few patterns matter in enterprise environments:

• Busy endpoints: Many simultaneous sessions can push CPU into crypto-bound behavior, especially on smaller instances.
• Hardware differences: AES-GCM performance depends heavily on CPU support for AES acceleration. Where that acceleration is inconsistent, ChaCha20-Poly1305 can be a steadier option.
• Policy-driven cipher choices: AES-256-GCM vs AES-128-GCM is often a policy and compatibility decision, not a “safe vs unsafe” split. The more important control is preventing fallback to older modes.

Other than this, protocol and client choice matters, but it’s a complex play of interactions. Read our SFTP vs. FTPS performance benchmarks study to learn more about these interacting factors and how to choose the right setup for your enterprise workflow..

Where managed file transfer (MFT) helps

MFT solutions, particularly options that support compliance standards, help enterprise teams run, scale, and enforce repeatable, defensible control across an organization. Full featured solutions will help you standardize enforcement, key management discipline, and evidence collection without depending on every individual server and script being configured perfectly. Typical MFT responsibilities (responsibilities that are effectively “outsourced” to MFT)  include:

Typical MFT responsibilities include:

• Server hosting and operations: They run the SFTP endpoint/s as a managed service, with hardened defaults, reliable uptime, and predictable but scalable capacity, so it isn’t tied to one VM, one disk, or one person’s config.
• Upkeep and patching: A good MFT will keep the SSH/SFTP stack and underlying systems updated, including security patches, dependency updates, and configuration control.
• Availability and recovery: They build in redundancy and recovery paths so an endpoint failure doesn’t turn into data loss.
• Central policy enforcement: They enforce approved SSH algorithms, authentication rules, and partner restrictions applied consistently.
• Scalable onboarding and offboarding: Repeatable partner setup and teardown so access doesn’t depend on ad hoc choices  and old keys don’t hang around.
• Key management hygiene: Central ownership of credentials and SSH keys, with clear visibility into who has access, what’s active, and what must be revoked. Also, the ability to enforce key management cycles at the organizational level.
• Audit-grade logging: Authentication events, admin changes, and file operations tied to identity, timestamped, retained, and exportable for compliance evidence.
• Monitoring and SIEM alignment: Logs and alerts that can be routed into SIEM pipelines so suspicious patterns (brute force attempts, unusual download volume, sudden permission changes) are caught fast.

Achieve enterprise SFTP encryption with SFTP To Go

SFTP To Go is a managed cloud SFTP service with emphasis on consistent encryption enforcement, scalable access management, and detailed evidence. Our secure file transfer and storage service combines a range of controls in one platform:

• Encryption in transit with multi-protocol support: SSH session encryption and integrity protection for SFTP connections, driven by enforced server configuration and client capability. Workflows often incorporate secure HTTPS and FTPS channels as well, and these are also supported. 
• Encryption at rest (Amazon S3): Landed files are stored on Amazon S3 with storage-layer encryption at rest.
• Scalable access and key management: Central management of users, credentials, and SSH keys so partner access can be provisioned and removed cleanly, without chasing down scattered configuration notes..
• MFA for administrative access, also enforceable at user level: MFA on the web portal to reduce the risk of unauthorized changes to users, keys, permissions, and exports. With mandatory MFA for admin users. 
• Logging and audit evidence: Centralized audit logging and export capabilities that support compliance mapping across GDPR, HIPAA, FERPA, GLBA, and SOC 2, with monitoring alerts via webhook and  a clearer path to SIEM ingestion than ad hoc per-server log collection.

Frequently asked questions