Security
Built so that compromising us
still doesn’t expose you.
Managed file transfer has been one of the most systematically attacked categories in enterprise software for the past several years. Even considering just the four largest vendors, they alone suffered at least one mass exploitation event each, with hundreds or thousands of downstream organizations affected.
The pattern keeps repeating because the flaw is in the architecture: internet-facing systems that hold credentials to customer storage and/or stage customer files on their own storage. Compromise one and you reach everything inside it, across every customer running it.
This page explains what SFTP.cloud does to prevent all that.
No credit card. No feature locks. Walk away by doing nothing.
Guarantees
Three things we cannot do, even if we wanted to.
Files
We cannot read your files.
Your files are never written to the storage we own. Not encrypted at rest on our disks, not cached, not buffered to a temporary volume under load, not held in a queue while a transfer completes.
.
Bytes cross our edge in flight, inside the encrypted channel between your Connector and your user. There is no code path in the service that writes customer file content to persistent storage, because there is no customer file storage in the service to write it to.
Credentials
We cannot reach your storage.
We hold no access key, no secret key, no OAuth refresh token, no service principal, and no cross-account role you need to grant us to access your storage.
.
Your Connector authenticates to your storage from inside your network, using credentials you created, stored where you chose to store them. If you rotate them, you don’t have to tell us. If you revoke them, we’ll never know, because we never had them in the first place.
Audit trail
We cannot rewrite what happened
Every session produces two independent audit chains. One is written by our Head. One is written by your Connector. Each hashes every line together with the hash of the line before it, so that altering any entry invalidates everything after it.
The two chains are signed with different keys. Ours is ours. Yours is generated on your Connector, held by you, and never transmitted to us. We cannot forge an entry in your chain. You cannot forge one in ours. And because both sides receive the same signed session voucher from the control plane, entries can be matched across the two chains and checked against each other.
If the two records ever disagree, you will find out, using a key we do not have. You can verify this yourself.
The verification tool is a downloadable open-source project. It runs on your machine, against your log chains, with no involvement from us at any point.
We are not in a position to tell you your logs are intact. You are.
The audit trail, in detail
Two records, two keys, two parties.
Tamper-evident logging is not a new idea, and several vendors claim it. What is uncommon here is that there are two records, and they are produced by two independent entities.
A single hash-chained log held by a vendor proves that an outsider did not alter it. It proves nothing about the vendor, because whoever holds the signing key can rebuild the chain from any point and sign it again.
Two chains, signed with two keys held by two different parties, remove that limit. Even if we were to rebuild ours, we cannot rebuild yours, because the key was generated on your Connector and we have never held a copy. You can rebuild yours and not ours. Neither of us can produce a consistent, matching pair of forged records.
The session voucher is what makes the comparison possible. When a session starts, the control plane issues a signed voucher that both the Head and your Connector receive. It cannot be modified by either side; any alteration ends the session. That voucher is the key that lets you line up an entry in your chain against the corresponding entry in ours.
Transport and cryptography
Encrypted against the traffic captured today and decrypted tomorrow.
Encrypted against the traffic captured
today and decrypted tomorrow.
-
Post-quantum key exchange on every protocol.
SFTP, FTPS, FTPES and HTTPS all negotiate post-quantum cipher suites. This matters for data with a long confidentiality life, where traffic captured today could be decrypted by a future adversary.
-
Mutual TLS (mTLS) between every internal component.
The Head, the control plane and your Connector all (mutually) authenticate each other with certificates. There is no internal hop where a component is trusted just because of where it sits on a network.
-
Standard protocols, standard clients.
Your partners connect with the software they already use. Nothing proprietary, nothing to install.
Encryption at rest
Encryption at rest,
with a key we never have
Every supported backend can hold your files in plain form, or encrypted with a key that lives on your Storage Connector and that we never receive.
This covers a case most file transfer products cannot address at all: someone reaching your storage directly, without going through us. A misconfigured bucket policy, a leaked cloud credential, a contractor with console access they should have lost months ago. If the objects are encrypted with a key held on your Connector, what any of those people find is ciphertext.