Software escrow is a contract under which a vendor deposits source code, build instructions, and dependencies with a neutral third party, who releases the deposit to you if a defined trigger fires — vendor bankruptcy, product discontinuation, breach of support obligations — and most deposits in existence would not compile if released tomorrow, because nobody ever verified them. Escrow is a fine control with a terrible default configuration. The default is "deposit-only," which buys you a legal right to a zip file of unknown quality.
I run vendor and OSS continuity for a living, so here is the practitioner's view: when escrow earns its fee, when it is theater, and what continuity planning looks like for the software you don't buy — SaaS and open source.
What escrow actually is, mechanically
Three parties sign a tripartite agreement: you (beneficiary), the vendor (depositor), and an escrow agent — the established ones are NCC Group's Escode, Iron Mountain, and newer players like Codekeeper. The vendor deposits materials on a schedule (per release, quarterly, or annually), and the agent releases them to you when a release condition is met.
Negotiate the release conditions harder than the deposit contents. Common triggers, roughly in order of how often they actually fire:
- Vendor ceases business or enters insolvency proceedings
- Product end-of-life or discontinued support
- Acquisition followed by discontinuation
- Material breach of maintenance obligations (slowest trigger — expect a dispute process measured in months)
Note what is not on the list by default: security abandonment. A vendor who ships nothing but keeps invoicing you has breached nothing. If unpatched criticals matter to you — and if you are reading this blog, they do — write a trigger like "failure to remediate CVSS 9.0+ vulnerabilities within 90 days of disclosure" into the maintenance breach definition.
The verification ladder: where the money goes
| Level | What the agent does | Rough annual cost | What you actually know |
|---|---|---|---|
| Deposit-only | Stores the media | Low hundreds to ~1k USD | A deposit exists |
| File verification | Lists and virus-scans contents | Low thousands | The zip isn't empty |
| Build verification | Compiles from the deposit per the runbook | 5k–20k USD | The code builds |
| Full usability | Builds, deploys, runs acceptance tests | 20k+ USD, per release | You could actually operate it |
The gap between levels one and three is the whole game. In release events, the most common failure is not missing source — it is a build that depends on a private package feed, a license server, a specific Jenkins box, or "Dave's laptop." If the software is genuinely continuity-critical, pay for build verification at least annually. If it is not worth that fee, ask whether the escrow itself is worth its fee.
What belongs in a deposit (this is where SBOMs earn rent)
A deposit that survives contact with reality contains, per tagged release:
- Source at the release tag, including build scripts and IaC
- Lockfiles and vendored dependencies — or a mirror of the private registry contents; public registries will not necessarily have five-year-old versions of everything when you need them
- An SBOM for the release, so you know what the dependency tree even was
- Pinned toolchain versions — compiler, SDK, base images by digest
- A build runbook that names no internal hostnames
- A third-party services inventory: every SaaS API, license server, and telemetry endpoint the product calls, because those contracts die with the vendor
Requiring an SBOM per deposit has a pleasant side effect: you can diff deposits across releases and check the vendor's dependency hygiene while they are still alive. Managing those artifacts is exactly what tooling like SBOM Studio exists for, and running the deposited manifests through SCA tells you what you would be inheriting on day one of a release event — a codebase with 200 known criticals is continuity in name only.
SaaS breaks the model
Classic escrow assumes that source code equals continuity. For SaaS, it does not. If your CRM vendor folds, their source code without their operational data, infrastructure, and staff is a museum piece. SaaS continuity is a different bundle:
- Data escrow or contractual export SLAs — full export in a documented format, exercised quarterly, not "upon request"
- IaC and runbooks in the deposit, so the system is theoretically re-hostable
- Realistic RTO expectations: standing up a dead vendor's SaaS from escrow is a months-long project. Often the honest continuity plan is "exportable data plus a named alternative vendor," and escrow money is better spent on migration rehearsal.
Say that out loud in the contract negotiation. A cheap data-export clause you test twice a year beats an expensive source escrow you never open.
Open source continuity: nobody to sign the agreement
Half my dependency tree has no vendor, so there is no one to escrow anything. Continuity for OSS is a different discipline with the same goal:
- License flips. HashiCorp relicensing Terraform to BUSL in August 2023 (spawning OpenTofu) and Redis moving off BSD in March 2024 (spawning Valkey) established the pattern: your continuity plan for commercially-backed OSS is the credible fork, and the community's ability to execute one. We analyzed the trend in our piece on commercial open source license shifts.
- Abandonment. For single-maintainer projects, continuity means an internal mirror of source and published artifacts, so an upstream deletion (left-pad taught everyone this in 2016) or a registry takedown cannot break your builds.
- Your fork muscle. Can your org build the dependency from source at all? For your top-20 critical dependencies, prove it once a year. It is the OSS equivalent of build verification.
The common thread across vendor, SaaS, and OSS continuity is unglamorous: know exactly what you depend on, keep a copy you control, and rehearse the failure before it happens.
Frequently asked questions
Is software escrow worth it for every vendor?
No. Reserve it for software that is genuinely irreplaceable inside your recovery-time objective — typically systems that would take more than a quarter to migrate off. For everything else, contractual data export rights and a named alternative are cheaper and more likely to work.
How often are escrow deposits actually released?
Rarely — industry figures suggest only a low single-digit percentage of agreements ever trigger. That is not an argument against escrow, but it is the reason verification matters: a control that fires once a decade must work the first time, unrehearsed.
What should we ask for in build verification?
The agent (or an independent engineer) builds the product from the deposit alone, on a clean machine, following only the deposited runbook, and produces the shipped artifact version. Insist that failures are reported to you, not just to the vendor, and that re-deposit plus re-verification follows within 60 days.
Does an SBOM requirement belong in escrow agreements?
Yes, per deposit. It costs the vendor little, lets you assess inherited vulnerability debt before a release event, and doubles as an audit of whether the deposit's dependency snapshot is complete. A deposit whose SBOM references packages missing from the deposit fails verification by definition.