If your Managed Cloud SFTP service also hosts your files, it’s not Zero Trust
Let's walk through the whole process and understand it together
▸ Skip to the very bottom if you’re just here for the early-access offer…
“Zero trust” appears on almost every MFT website nowadays. Usually right next to a padlock icon, a compliance badge, and a sentence about encryption in-transit and at-rest.
Then you read the architecture page, and realize the files live on their servers, or they require the credentials and an in-path to access your storage. LOL! 😂
Both things cannot be simultaneously true: Zero Trust is not a “feature”, it’s an architectural property of the system, it’s either built-in by design, or it doesn’t exist.
What zero trust actually asks of an architecture
Strip away all the marketing blah-blah, and the requirement becomes clear: never grant standing trust + verify every request + assume any component can be compromised. Bottom line: design the entire platform so that when one of its parts falls, the damage stops there (aka, minimize the blast radius).
That last part is the one this industry keeps pretending it doesn’t exist. Zero trust is not primarily about how strong your authentication is, it’s about what an attacker gets when an attacker skips through a crack anyway. If the answer is “your files”, the model has failed, no matter how many authentication factors guarded the door.
So the honest test for any managed cloud SFTP service is a single question: if someone (a hacker, a rogue AI agent, you name it!) fully compromised the vendor’s platform tomorrow, what would they walk away with?
Where the trust actually sits in most of this category
There are two common answers today, and neither one survives the question.
The vendor holds your files. They sit on the vendor’s infrastructure, sometimes only during a transfer, often for much (much!) longer. Everything about your security posture now depends on that vendor’s operational discipline being perfect, permanently. You have granted a standing trust relationship to an environment you cannot inspect, patch, monitor, or contain. That is an implicit trust zone. It is precisely the thing zero trust was designed to eliminate.
The vendor holds your storage credentials. This one somehow manages to “feel safer” (the mighty power of marketing?) but that’s precisely why it’s worth being extra careful about it. Your files stay in your own S3, GCS, or Azure Blob storage. The vendor simply holds an access key, an IAM role, or a service account so the platform can reach in and fetch them… Hum, wait, what? 🤔
Look at what was actually granted! A credential that can read your storage is functionally the same as holding the storage, only with a minuscule built-in delay. Compromise the platform, extract the credential (often already held in RAM, unencrypted and trusted, for speed) and the outcome is identically catastrophic.
Both models come to the same place: they ask you to extend permanent trust to an environment outside your control, and they call the result “zero trust” because the traffic is encrypted.
Encryption is not the same as zero trust
Encryption protects data from parties who are not holding the keys, it stops nothing against a party who does.
This is why “encrypted in transit and at-rest” is a weak claim in this category and always has been. A secret held by an endpoint cannot defend against that endpoint’s own compromise.
So, a service can be fully encrypted, competently run, compliant with several frameworks and regulations, and still fail every meaningful zero trust test.
What passing the test would look like
If the standard is “compromising the vendor yields nothing”, then the architecture has to satisfy way stricter conditions than the ones described above.
Customer files must never reside on the vendor’s infrastructure. Not in transit staging, not in a cache, not briefly, not ever.
The vendor must never hold a credential set that grants access to customer storage. Not scoped, not rotated, not vaulted. It simply has to be not-held.
The path to storage must be opened from the customer side, outwards to the SaaS MFT side, so nothing in the vendor’s platform can initiate a reach inward even if it wanted to.
Storage is wherever the customer already keeps it, cloud or on-premises, because a design that only works when the customer’s data is in someone else’s cloud has the exact problem we are trying to avoid built into its design.
Those conditions are demanding. They also rule out most of what is currently sold as zero trust managed file transfer. And that is the whole point.
Why we keep coming back to this
This level of True Zero Trust is the design goal we set for SFTP.cloud before we even wrote its first line of code, and it is the reason the architecture looks so unusual. We do not hold your files. We do not hold keys into your storage. We never needed a way to reach into your network, so we did not build one.
So, when you evaluate your next MFT solution, ask yourself what an attacker gets when the platform falls. Then decide whether the words on the homepage matched the answer.
We are building SFTP.cloud to give a boring answer to that question. Early access is open to the first 100 people who want in: reserve your spot at sftp.cloud. Not ready yet? Subscribe to this blog and we will keep you posted.