An attack surface you don’t have can’t be breached
The SFTP.cloud architecture, for the people who’ll be asked to sign off on it.
In our last post we introduced SFTP.cloud and made a claim that deserves a closer look: your files never live in our cloud, and your network never opens a single inbound port to make that happen. To most CTOs that lands somewhere between “nice marketing” and “physically impossible.” So here’s the architecture, in one diagram (and a few paragraphs to explain it).
Start with the question every security review eventually asks: where is the attack surface, and who owns it?
In the standard managed-file-transfer SaaS model, the answer is uncomfortable. Your files sit at-rest on the vendor’s infrastructure, and your endpoint is reachable because something inbound is exposed: a listening port, a NAT rule, a hole punched in the DMZ. You outsourced your file transfer and inherited two attack surfaces you don’t control: the vendor’s storage, and your own inbound exposure.
SFTP.cloud removes both. Not hardens. Removes.
The inverted data plane. Public clients (SFTP, FTPS, FTPES, HTTPS) connect to a highly available protocol edge in our cloud. That edge terminates the protocol and relays the bytes. It does not store them. A lightweight connector you deploy on or next to your own storage opens an outbound connection to that edge, and traffic flows back through it to where your files actually live: your subnet, your disks, your keys. The cloud sees an encrypted data stream. It never sees a file-system. NO CUSTOMER FILES HERE isn’t a policy we promise to honor, it’s a property of the design.
The inverted control plane. The same inversion applies to management. Your credentials, your access policies, your service configuration: none of it lives in our cloud either. Your control nodes connect outbound to the management layer; the management layer never reaches in. There is no inbound admin endpoint on your side to discover, scan, phish, or brute-force. There is no door to knock on.
Now add it all up the way a CTO has to:
Inbound firewall rules required: zero. No NAT, no port forwarding, no DMZ. The connector dials out; nothing dials in.
Customer files in the vendor cloud: zero. Your files stay in your storage subnet, under your control.
Blast radius of a cloud-side compromise: a stateless protocol relay with no files and no standing inbound path to your network. Nothing to steal, and nowhere to pivot.
Data residency: trivially answered, because the answer never changed. Your files never left your subnet.
We’ll say the rest plainly, because the category won’t: most “secure” cloud file transfer is really just secure storage of your files on someone else’s servers. We think that’s the wrong default. An attack surface you don’t have can’t be breached. And a file we never hold can’t be leaked.
For the record, SFTP.cloud remains an entirely new product, not a replacement for Syncplify Server!, R2FS!, or AFT!. It’s built for teams that need an internet-facing, fully managed endpoint without surrendering custody of their data to get one.
Release date is still under wraps. The connector deployment model, architecture deep-dives, and early-access details are coming. Subscribe, and we’ll post here first.