Security

If we are breached, you are not.

Managed file transfer has been one of the most attacked categories in enterprise software for years. Each of the four largest vendors has had at least one mass exploitation, with hundreds or thousands of downstream organizations affected.

The pattern repeats because the flaw is in the architecture: internet-facing systems that hold credentials to your storage, or stage your files on their own disks. Compromise one and you reach everything inside it, for every customer running it. This page explains how SFTP.cloud is built so that doesn't happen to you.

Start your free trial See how it works

14 days. No credit card. No feature locks.

Our infrastructureWhat an attacker would find
Your filesNever written to our storage.
0
Credentials to your storageThey stay on your Connector.
0
A way into your networkYour Connector only dials out.
0
The key to your audit chainGenerated on your Connector, never sent to us.
0

Nothing of yours to take.

01Guarantees

Three things we cannot do, even if we wanted to.

  • 01Files

    We cannot read your files.

    Your files are never written to storage we own: not encrypted at rest on our disks, not cached, not buffered to a temporary volume under load, and 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. The service has no code path that writes file content to persistent storage, because it has no customer file storage to write to.

  • 02Credentials

    We cannot reach your storage.

    We hold no access key, secret key, OAuth refresh token or service principal, and you never grant us a cross-account role.

    Your Connector authenticates to your storage from inside your network, with credentials you created and stored where you chose. Rotate them and you don't have to tell us. Revoke them and we won't notice, because we never had them.

  • 03Audit trail

    We cannot rewrite what happened.

    Every session produces two independent audit chains, one written by our Head and one by your Connector. Each hashes every line together with the line before it, so changing any entry invalidates everything after it.

    The chains are signed with different keys, and yours never leaves your Connector. If the two records ever disagree, you find out with a key we don't have. See how below ↓

Every system can be attacked. The better question is what an attacker could take from you. With SFTP.cloud: neither your files nor the keys to them.

02The audit trail

Two records, two keys, two parties.

Tamper-evident logging isn't new, and several vendors claim it. What is uncommon here is that there are two records, produced by two independent parties.

A single hash-chained log held by a vendor proves that an outsider didn't 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 parties remove that gap. We could rebuild ours, but not yours: your key was generated on your Connector and we have never had a copy. You could rebuild yours, but not ours. Neither of us can forge a matching pair of records.

The session voucher makes the comparison possible. When a session starts, the control plane issues a signed voucher to both the Head and your Connector. Neither side can change it, and any attempt ends the session. The voucher lets you line up each entry in your chain with the matching entry in ours.

Try itClick any entry to alter it

Our chain · signed with our key

Your chain · signed on your Connector

Both chains verify, and every entry matches its counterpart.

03Verify it yourself

Don't take our word for it. Check your logs yourself.

The verification tool is an open-source project you download. 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.

View logverify on GitHub
Tool
syncplify/logverify
Source
Open source, on GitHub
Runs on
Your machine
What it needs from us
Nothing

04Transport and cryptography

Protected against traffic captured today and decrypted tomorrow.

  • 01

    Post-quantum key exchange on every protocol.

    SFTP, FTPS, FTPES and HTTPS all negotiate post-quantum cipher suites. That matters for data that has to stay confidential for years, where traffic captured today could be decrypted by a future adversary.

  • 02

    Mutual TLS between every internal component.

    The Head, the control plane and your Connector authenticate each other with certificates. No component is trusted just because of where it sits on a network.

  • 03

    Standard protocols, standard clients.

    Your partners connect with the software they already use. Nothing proprietary, nothing to install.

05Encryption at rest

Encryption at rest, with a key we never have.

Every supported backend can hold your files as they are, or encrypted with a key that lives on your Storage Connector and is never sent to us.

That covers a case most file transfer products can't address at all: someone reaching your storage directly, without going through us. If your objects are encrypted with a key held on your Connector, all they find is ciphertext.

If someone reaches your storage through

  • A misconfigured bucket policyThey find ciphertext
  • A leaked cloud credentialThey find ciphertext
  • A contractor whose console access should have ended months agoThey find ciphertext

Bring your own key. Keep your own key.

Check every claim on your own storage.

Connect your storage, run a transfer and verify both audit chains yourself. Fourteen days, no credit card, and nothing to cancel if it is not for you.

Start your free trial

Want to see the moving parts first? See how it works or talk to an engineer. The person who answers builds the product.