SFTP Encryption at Rest: How It Works and How to Enable It

Whether the files on an SFTP server are encrypted has two separate answers. Transfers are always encrypted, because SFTP runs inside an SSH session and nothing crosses the network in the clear. The files sitting in the upload directory afterwards are usually plain files that any account with read permission on that folder can open.

The gap has nothing to do with SFTP being badly designed. SFTP is a file transfer protocol layered on SSH, and SSH secures connections. Storage is somebody else's problem, and this article is about who that somebody is and how to pick between the three practical options without buying more than the situation needs.

The short answer

SFTP does not encrypt data at rest and was never intended to. Adding at-rest protection is a separate decision with three viable implementations.

SFTP encrypts the transport, not the storage

An SFTP session begins with an SSH key exchange, after which every byte in both directions is encrypted with a negotiated symmetric cipher and integrity-checked with a MAC. When a client uploads patients-2026-07.csv, the contents are protected from the moment they leave the client until the server has them in memory. The server then writes the file to disk through the normal filesystem API, and the SSH session that carried it closes. Nothing about SSH follows the file onto the volume.

Anyone with read access to that directory afterwards sees the file exactly as the sender wrote it, including the service account the SFTP server runs as, local and domain administrators, backup software, the storage array, and whoever ends up with the drive when the machine is retired.

Why the gap matters under HIPAA, PCI DSS and GDPR

Compliance frameworks treat transmission and storage as separate controls, which is why passing a transit requirement does not carry you through the storage one.

Under the HIPAA Security Rule, encryption and decryption of stored electronic protected health information appears at §164.312(a)(2)(iv) as an addressable implementation specification under Access Control, while transmission security sits separately at §164.312(e). Addressable does not mean optional; it means an organisation must implement it or document why an equivalent alternative is reasonable and appropriate given its risk analysis. PCI DSS requires stored account data to be rendered unreadable wherever it is stored, distinct from the requirement covering transmission over open networks. GDPR Article 32 names encryption of personal data as an example of an appropriate technical measure without splitting it by state. An auditor who is happy with your SFTP configuration will still ask what happens to the file after it lands.

What encryption at rest actually protects against

Being precise here saves an awkward conversation later. Encryption at rest defends data accessed outside the running system: a disk pulled from a decommissioned server, a SAN volume re-provisioned without being wiped, a backup tape that goes missing in transit, a cloud snapshot copied by someone whose IAM policy was broader than anyone realised, or a VM image cloned out of the hypervisor.

It does not defend against a compromised running server, because the server holds the key and decrypts on demand by design. It does not defend against a compromised account, because the attacker downloads files through the same path a legitimate user does and receives the same unencrypted data. Server-side encryption at rest narrows the set of people who can read the files to those who can authenticate as a user with access, which is a meaningful reduction when your administrator population is larger than your authorised-reader population.

Three ways to add encryption at rest to an SFTP server

Full-disk and filesystem encryption

BitLocker on Windows, LUKS or dm-crypt on Linux, and eCryptfs or fscrypt for per-directory encryption all operate below the file transfer server. The SFTP service sees an ordinary filesystem, the operating system encrypts blocks or individual files, and no application configuration changes at all.

The threat this addresses is physical or image-level: a stolen drive, a decommissioned server, a copied VM image. Once the machine is booted and the volume is unlocked, every process with filesystem permissions reads the files unencrypted, including a compromised service and any logged-in administrator.

For an organisation running one or two SFTP endpoints on hardware it controls, with a small admin team and a threat model centred on hardware leaving the building, this is frequently the correct answer, and it costs nothing beyond the time to enable it and a real process for storing the recovery keys. A BitLocker key that exists only on the departed administrator's laptop is a data loss event waiting for a motherboard failure.

Server-side encryption in the file transfer platform

The MFT-level approach moves encryption into the file transfer server. The file arrives over SFTP, and rather than writing it to disk as-is, the server encrypts it on the way in and decrypts it on the way out for users authorised to read it. The bytes on disk are encrypted, so an administrator logged in to the server console sees files they cannot open.

Two things distinguish this from the filesystem approach. Encryption follows the file rather than the volume, so a file copied off the server, backed up, or replicated elsewhere stays encrypted. Selection is per account rather than per volume, so a server hosting several trading partners can encrypt for the ones handling regulated data and leave the rest alone. The cost is coupling, because the file transfer server owns the key material and anything else that needs to read those files has to go through the server.

Encrypting before the file is uploaded

The third option puts encryption in the sender's hands. The partner PGP-encrypts the file with your public key before uploading, and it stays unreadable until you decrypt it with a private key that lives wherever you choose. The SFTP server stores an opaque blob, and a compromise of that server yields nothing readable.

This is the strongest of the three and the most operationally demanding. Every partner needs your public key, keys expire and get rotated, and someone has to run the process that decrypts files into whatever system consumes them. When the sending side is an internal application you control, the burden is small. When it is forty external partners of varying technical sophistication, key distribution becomes a permanent job.

CompleteFTP supports PGP encryption and decryption in the Enterprise MFT edition, with keys stored as properties on folders. PGP keys set on a folder are not applied automatically, and encryption or decryption happens only when a process trigger, written in the server's JavaScript scripting language (JSS), calls the PGP functions explicitly.

Choosing between them

Full-disk encryption suits a single-purpose server, a small administrator team, and a risk register whose top entry is hardware or a VM image escaping. Platform-level encryption suits a shared server where some accounts hold regulated data and others do not, where administrators should not be able to read customer files, and where you want the same system holding the audit trail. Client-side PGP suits regulated data flowing between a manageable number of technically capable parties, particularly when the file transfer server sits in a DMZ or at a hosting provider you do not fully control. Layering is normal, and full-disk encryption underneath platform encryption covers the decommissioning case that platform encryption alone leaves open on swap files and temporary directories.

How encryption at rest works in CompleteFTP Enterprise MFT

CompleteFTP calls the feature Encryption At Rest, abbreviated EAR in the documentation. It has been available since version 11.0, is an Enterprise MFT feature absent from the Standard and Professional editions, and uses 128-bit AES.

Two switches, one on the site and one on the user

Encryption at rest turns on for a user only when two settings agree: the site-wide "Encrypt stored files" setting under the site's filesystem settings, and the "Encrypt stored files" setting on the individual user. Configuration is per user rather than per folder, so an account is the unit you make decisions about.

Turning the site-wide setting off stops new files from being encrypted while leaving existing encrypted files readable, and they continue to be decrypted automatically on download. Turning it off is a way to stop encrypting rather than a way to bulk-decrypt what is already there.

Transparent decryption, and what cannot decrypt

Users transferring files see unencrypted data. They upload a file, the server encrypts it as it writes, they download it later and receive the original bytes back, and nothing in the client changes. Someone logged directly on to the server machine cannot read the files at all.

Outside a transfer, the documented route to the unencrypted file is the encrypt and decrypt administrator commands run from the SSH administrator command line, which take a source and destination path in the virtual filesystem:

decrypt -s /home/myuser/test_encrypted.txt -d /home/myuser/test_plain.txt

What encryption at rest breaks

This is the limitation to plan around, and CompleteFTP's documentation states it plainly. FTP scripts are executed by an external program and cannot decrypt server files, and batch files and standalone executables cannot decrypt them either. Any post-processing pipeline that reaches into the upload directory expecting a readable file will find encrypted data.

The exception is JSS process triggers, which run inside the server and are fully integrated with its virtual filesystem, so they can decrypt files. If uploaded files need automatic processing after arrival, that processing has to be written as a JSS trigger or has to fetch the file through the server rather than off the disk.

Directory listings and file sizes

Encrypted files are a few bytes larger than their unencrypted originals, and by default CompleteFTP reports the encrypted size in directory listings. A per-user setting called "Report decrypted size" shows the original size instead. Determining whether each file is encrypted takes work, so the documentation warns that listings become significantly slower with that option on and advises leaving it off unless the decrypted size is required.

What happens during a backup

Files backed up from an EAR-enabled folder are backed up encrypted, which is the useful half of the behaviour, because a backup set that leaks does not leak the file contents. The other half is that restoring those files somewhere else does not give you readable data, and neither does handing them to a forensic tool or a data recovery service. Include the server configuration in the same protected backup rotation as the data, verify a restore of both together at least once, and confirm that more than one person can perform it.

The controls a regulated workload needs around it

Encryption at rest is one control among several, and it helps to see where it sits. For health or payment data the controls auditors most often ask about are strong authentication in front of the data, an audit trail of who read what, and an account and key lifecycle that survives staff turnover. None of this makes an organisation compliant on its own; that determination belongs to your compliance function and your risk analysis. What each control is for is general; how a particular server provides it is where the product details come in.

Authentication in front of the encrypted files

Encryption at rest reduces the readable population to authenticated users, so authentication carries more weight once it is on. A regulated deployment usually wants accounts backed by a central directory rather than a separate list, key-based authentication for automated connections, and a second factor on any interactive route into the data.

One wrinkle is worth planning for: a Multi-Factor Authentication (MFA) is straightforward on a web interface but has no place in the SFTP protocol, which authenticates with a password or a key and nothing interactive. The usual answer is to require public keys on the SFTP side and reserve password-plus-second-factor for the web interface. In CompleteFTP that maps to Active Directory-backed accounts, public key authentication for SFTP, and TOTP two-factor authentication on HTTP and HTTPS.

Auditing who accessed what

Encryption at rest records nothing about access. It changes who can read the bytes, not who did. Proving that a particular user downloaded a particular file at a particular time is the job of an audit log, a separate control and the one an investigator actually asks for. A server aimed at regulated use keeps that log with configurable retention and a format an auditor can read. Our SFTP audit logs guide covers what they look for, and how CompleteFTP records it.

Account and key lifecycle

The decisions that actually get reviewed are procedural rather than cryptographic: which accounts have encryption enabled, who checks that new accounts handling regulated data inherit it, who holds the configuration backup once the person who set the server up has left, and how a partner's key is replaced without an outage. Rotating a key without downtime needs a server that lets one account hold several keys at once, so the new key can be added and confirmed before the old one is removed. CompleteFTP allows this from the Professional edition up.

Interest tends to come from sectors where stored data is already subject to review:

"We are looking to take advantage of the Encryption At Rest provided in the higher version of CompleteFTP."
a US receivables management organization (EnterpriseDT support archive)

Common gotchas

Performance is rarely the problem people expect. The cost that is actually documented, and the one more likely to be felt, is the per-user report decrypted size option described above, which makes directory listings significantly slower.

Key recovery after staff turnover. The administrator who enabled encryption is often the only one who knows how the configuration is backed up. Document it, store it where a second person can reach it, and test it.

Mixed deployments drift. Encryption is set per user, so a server with some encrypted accounts and some unencrypted ones needs a rule about which category new accounts fall into.

Automation written before encryption was enabled. The batch file that has been picking up uploads for three years will keep running and will start producing garbage output rather than failing loudly. Inventory anything that reads the upload directory directly before you turn encryption on.

Compliance claims about the algorithm. CompleteFTP is not FIPS 140-2 validated, and neither we nor anyone else should imply otherwise. It can be configured to use FIPS-approved algorithms, which is a different statement and one your auditor will distinguish between.

Frequently asked questions

Does SFTP encrypt files at rest?

No. SFTP encrypts the SSH connection carrying the file, and once the transfer completes the server writes an ordinary file to an ordinary filesystem. At-rest protection has to come from the operating system, the file transfer server, or the application that produced the file.

Is data encrypted at rest on an SFTP server?

Only if it has been configured that way. A default OpenSSH or Windows SFTP service stores uploaded files as plain files, readable by anyone with permission on that directory, including administrators and anyone who obtains the disk or a backup.

What is the difference between encryption in transit and encryption at rest?

Encryption in transit protects data moving between machines and is defeated by an attacker reading the network. Encryption at rest protects data sitting on storage and is defeated by an attacker who obtains both the storage and the key.

How do you encrypt files at rest on a Windows SFTP server?

BitLocker encrypts the volume the SFTP directories live on and covers the case where a disk or VM image leaves your control. A file transfer server with built-in encryption at rest encrypts each file as it is written, so the files stay unreadable to anyone logged in to the server.

Does encryption at rest protect against a hacked server?

Not on its own. It protects data accessed outside the running system, such as a stolen disk, a decommissioned image, a copied backup, or a cloud snapshot. An attacker who controls a running server, or who holds valid credentials for an account with access, receives the same decrypted data a legitimate user receives.

Is HIPAA compliance possible with SFTP alone?

SFTP addresses transmission of electronic protected health information and nothing else. Storage encryption, access control, audit controls, workforce procedures, risk analysis and business associate agreements all sit outside it.

What is the difference between server-side and client-side encryption?

Server-side encryption means the file arrives unencrypted over the secure connection and the server encrypts it before writing, so the server holds the key and can decrypt on download. Client-side encryption means the sender encrypts before the file leaves their machine, so the server stores something it cannot read.

Where to go next

For one or two SFTP servers on hardware you own, BitLocker or LUKS plus a documented recovery key procedure covers the common threat at close to zero cost. CompleteFTP's Encryption At Rest documentation has the configuration procedure and the process trigger caveat in the vendor's own words. The Enterprise MFT trial installs with encryption at rest available, so you can enable it on a test account and see what your existing automation does with encrypted files before committing to it. For the wider picture, see MFT compared with SFTP and the SFTP server guide.

Other technical articles

Download Free Trial