Published
Summary: SFTP and correctly configured FTPS protect the transfer between client and server, but the file is not encrypted at the server that receives it. The transfer server can read the content. Encrypting the stored data is a separate control and does not make the transfer end-to-end encrypted either. For many file flows it is enough – but if the supplier must not be able to read the content, the file has to be encrypted before it leaves you, and that is a requirement you have to write down rather than hope for.
”Is the transfer encrypted?” is one of the most common questions in a supplier review, and the answer is almost always yes. The question that settles the matter is asked less often: who can read the file?
What TLS and SSH actually protect
SFTP runs over SSH and FTPS over TLS. Both protect the channel between the client and the server: someone listening on the network sees that a connection exists, but not what is sent inside it, and cannot alter the content in transit without it being detected.
Then the channel ends. The server decrypts what it receives, because otherwise it cannot put the file in the right folder, validate the format, trigger a flow or pass it on to the next system. Encrypted storage does not change that: encryption at rest protects against some forms of unauthorised access to the storage media, such as a stolen disk, but not against an administrator or application with permission to read the folder.
What end-to-end encryption means
End-to-end encryption means only the endpoints hold the plaintext. The sender encrypts with the recipient’s key, and everything in between – the network, the server, the operator – does not have the keys and therefore cannot read the content even if it wanted to. That is the model in encrypted messaging services, and it is also what PGP-encrypted files do inside a file flow.
The distinction is not academic. Above all, it decides whether the supplier can technically access the content in plaintext.
Why the difference matters in practice
- The processor has actual access. When the platform can read the content it is not enough to note that a data processing agreement exists – you need to know which roles can open the files, which sub-processors are involved and where the processing takes place.
- An incident at the supplier includes your files. If the platform is compromised, it is not only metadata that is exposed. With end-to-end encryption the attacker would have obtained encrypted files without the keys.
- ”Encrypted” on a questionnaire usually means transport encryption. That is not a wrong answer, but it answers a different question from the one you asked if what you wanted to know was whether the supplier can read the content.
When you genuinely need end-to-end
Many common file flows do not need end-to-end encryption. For them, transport encryption together with strong authentication, narrow permissions, sound key management and logging gives sufficient protection for the transfer itself and for access. What goes wrong more often lies around it: files sent by email instead of through the flow, files that reach the wrong recipient and accounts left in place after someone has left. A managed flow with owners and routines solves that, not end-to-end encryption.
There are flows where the requirement is reasonable: special categories of personal data that have to pass an external party which does not need the content, material covered by professional secrecy or source protection, and information that is price-sensitive or under embargo. The answer then is to encrypt the file before it is uploaded – PGP or the equivalent – with key management held by you and the recipient rather than by the platform.
The cost should be stated plainly: a file the platform cannot read is also a file it cannot validate, convert or search, and a lost key means the file is gone. Encrypting before upload is therefore a deliberate choice for named flows, not a general setting.
How to write the requirement
A requirement phrased as ”the file transfer shall be end-to-end encrypted” will get a yes from suppliers who mean TLS. The wording needs to say what you want to achieve instead:
- The file shall be encrypted before it leaves our environment, and the supplier shall not have access to plaintext or keys.
- State which roles at the supplier can technically read the content, and how that access is logged.
- State which protocols and versions are used for the transport, TLS 1.2 or later for instance, and how the storage is encrypted.
The same three points work when someone is reviewing you. Answer with what you have – transport protocol, storage encryption and which roles can read – rather than stretching the words end-to-end further than they reach. A reader who knows the difference trusts that answer more, and a reader who does not is helped by having it explained.
If you want to go a step further into the choice between the protocols and the platforms, we have written about SFTP, FTPS and MFT and when each one fits.
We help organisations set up and manage secure file transfer with encryption, permissions, logging and automated flows. If you would like to go through how your file flows look today, you are welcome to contact us.
Sources: ISO/IEC 27001:2022, Annex A.8.24 on the use of cryptography and A.8.12 on data leakage prevention; NIST SP 800-52 Rev. 2 on TLS configuration; the Swedish Authority for Privacy Protection (IMY) guidance on security measures when processing personal data.
This text is general information and does not constitute legal advice in an individual matter.