How do you recognise a responsible escrow agent?
Five questions with verifiable answers.
In the debate about social media, the term "responsible social media" comes up ever more often. Strikingly, the two camps mean opposite things by it. The platforms mean that users should handle the service more sensibly. Regulators mean that the design must change, because the system currently rewards the wrong things. The European legislator has since settled that question: what counts when assessing a service is how the system is built, not the good intentions expressed around it. And if that is already the standard for social media, then certainly for the place where companies' source code and data are stored.
Escrow knows exactly the same distinction, and something comes on top: escrow agent is not a protected or regulated profession. There is no legal framework, no title protection and no supervisory authority. Every provider fills it in in its own way, and every provider calls itself independent and secure. Anyone putting arrangements side by side is therefore quickly comparing apples and oranges.
Responsible escrow is therefore not a label a provider awards itself, but a test the customer performs: questions with verifiable answers, regardless of how a provider has set up its arrangement. This page contains five. Ask them of every escrow provider you consider, including us; our answers are at the bottom.
Why this weighs heavier with escrow
With a social media service, you notice yourself when something goes wrong. With an escrow arrangement, you only notice at the moment you need to fall back on it. That is precisely the moment the supplier is bankrupt or has discontinued its services. Correction after the fact no longer exists.
For the supplier it weighs just as heavily, for a different reason. The contents of a deposit are its intellectual property: source code, architecture, configurations. Often the company’s most valuable asset, bundled in one place outside its own doors. With information of that weight, you do not want wrong hands to be forbidden; you want them to be excluded.
Wrong hands need not involve intent, either. A data breach, a configuration error or a compromised account at the provider is enough. A prohibition does not protect against that; exclusion does. What a provider cannot read cannot leak from the provider.
The difference between a promise and a design
A promise is: we do not look inside your deposit. A design is: we cannot look inside your deposit.
That difference is not wordplay. In many escrow arrangements, the escrow agent itself generates and manages the key pair used to encrypt the deposit file. The agent can then decrypt the contents at any time. With direct Git synchronisation it is a step more fundamental still: there the source code arrives at the escrow agent in readable form, without any key involved. There is no reason to assume anything is done with it. The point is that the customer cannot rule it out, and neither, therefore, can a court or a foreign authority.
Consider what is inside that deposit: the intellectual property your business runs on. Not even your escrow agent should have access to it; independent access is at the very least a security risk.
With zero-knowledge, the supplier encrypts client-side, before delivery. The encryption key goes to the beneficiary and never reaches the escrow agent. The deposit file is end-to-end encrypted (E2EE). Access is thereby technically excluded, not merely contractually forbidden.
Sovereignty works on the layer below: does the storage fall under EU law, or does a foreign legal system have an entry point? The two layers reinforce each other. If something is demanded under compulsion, there is nothing meaningful to hand over without the key.
The five questions
| # | Question | What it tests |
|---|---|---|
| 1 | Does the arrangement hold up if a party falls away? | Both scenarios. Does a deposit fall outside the estate in a supplier bankruptcy, or does availability depend on the cooperation of the receiver, as with cloud account credentials in a deposit? And has the provider’s own continuity been safeguarded in advance, so that storage and release continue if the provider itself fails? |
| 2 | Are the provider and the storage sovereign? | Both layers: a foreign parent company or establishment gives a legal entry point regardless of where the storage is, and storage under foreign law does the same even with a European provider |
| 3 | Can the provider read the contents of a deposit? | Whether the contents ever arrive readable (for example via Git synchronisation) and who holds the encryption key: is access technically excluded or merely forbidden? |
| 4 | Can the contents be independently verified in advance? | Whether there is more than storage alone: integrity checks and key verification say nothing about the contents; only an independent verification investigation does |
| 5 | Can a deposit be used independently after release? | Whether a deposit is free of vendor lock-in: does standard tooling suffice, or are there vendor dependencies left, such as software from the provider, credentials of a cloud platform, or taking over the contract and the bills of that platform account. Every dependency complicates the release, at the very moment the supplier has fallen away. And a deposit often exists for decades; every dependency has to keep working all that time |
With questions 2 and 3 there is no bluffing: they are visible in the trade register and in the architecture. The other three can be answered with documentation a provider can simply publish.
Answering them is thereby a quality test in itself. The oldest quality principle reads: say what you do and do what you say. The second half can only be checked once the first half is there. A provider that does not publicly describe its setup cannot be tested on the first part at all. Our comparison of escrow providers shows exactly that: a light grey cross there means that a feature is not publicly described, or that we could not find it when compiling the comparison.
Why questions and not a certification mark
A certification mark merely moves the question of trust: you then trust the body that issues it. Verifiable answers do not; you can check them yourself, in the architecture, in the trade register or in the documentation.
Part of that honesty is stating what escrow does not do. Escrow arranges availability, not ownership. The intellectual property remains with the supplier; an arrangement ensures that a deposit becomes available under the agreed release conditions, with the accompanying right of use.
Our answers
Whoever proposes five questions should be the first to answer them.
1. Does the arrangement hold up if a party falls away?
Yes, on both sides. Under our agreement, a deposit automatically passes into safekeeping upon a supplier bankruptcy. It is thereby immediately clear to the receiver that it falls outside the estate; a deposit is thus directly available to the rightful party, with the accompanying right of use. And Softcrow’s own continuity is safeguarded through an independent foundation, so that the obligations under the agreement continue: deposits remain available and releases proceed, even if Softcrow itself were to fail. That is in everyone’s interest.
2. Are the provider and the storage sovereign?
Yes, both. Softcrow Trusted Electronic Services B.V. is an independent Dutch company from Almere, founded in 1991, without a foreign parent company or establishment. The storage runs 100% within the EU, in ISO 27001-certified data centres, and falls outside US jurisdiction: free from the CLOUD and USA PATRIOT Act.
3. Can the provider read the contents?
No. A deposit never arrives at Softcrow in readable form: the supplier encrypts it with AES-256, quantum-safe, before delivery. The key goes to the beneficiary and never reaches Softcrow. Underneath all our services lies SecureStorage, our own zero-knowledge storage infrastructure. Zero-knowledge is an architecture principle here, not a zero-knowledge proof from cryptography: we provide no mathematical proof, we simply do not have the key.
4. Can the contents be independently verified in advance?
Yes, as an option. First the honesty that belongs with zero-knowledge: because we cannot see inside a deposit, our own checks only say something about the storage and the key. The weekly integrity check (SHA256) guards that a deposit is unchanged; with the free key verification, the beneficiary establishes that the key is correct, well before it is needed. The contents themselves are tested by the verification investigation: the supplier builds a working environment from the deposit under the supervision of an independent NOREA Register IT auditor, and the report of findings indicates whether a working application can be compiled from the deposit.
5. Can a deposit be used independently after release?
Yes. A standard deposit opens with 7-Zip or WinZip; for incremental deposits the open-source program Restic suffices. The format is open (AES256-ZIP) and no Softcrow software, no platform account and no third-party contract is needed. What the beneficiary receives depends on no one else.
Ask them, including of us
An escrow agent should be built in such a way that it cannot break its own promise. Take these five questions into every conversation about escrow. And accept no answer that amounts to “just trust us”.
See the comparison of five providers →
Would you like to hold your situation against these questions? Feel free to consult Michel Kiès; a conversation is without obligation. Calling directly also works: +31 (0)20 696 20 50.
By submitting this form you confirm that you have read Softcrow’s privacy statement and agree to the way Softcrow handles your data.