You've just had a promising enterprise sales conversation. They're interested, the deal is as good as done, and procurement sends over their requirements. Software escrow you expected — it comes up in almost every enterprise contract now. But there's an unexpected requirement sitting next to it: a software bill of materials.
Same deadline, same contract on the line. But now you're wondering whether these are two separate things to set up, whether one somehow satisfies the other, or whether depositing an SBOM in your escrow arrangement even makes sense.
In this post, I'll walk you through how the two fit together and what it looks like to take care of both in one go.
What your clients get out of a software escrow
When you set up a software escrow agreement, you're depositing everything your client would need to keep running if your company wasn't in the picture anymore. Source code, build instructions, deployment configurations, credentials, technical documentation — all of it goes into a secure vault managed by a neutral third party.
If a release trigger fires — your company becomes insolvent, discontinues support, or breaches the agreement — your client gets handed the contents of that vault and the support to use them. The goal is that they can take what's in there and keep their operations going without you.
P.S. Don't worry they don't get ownership. Take a look at how escrow protects your IP.
Essentially, you're promising your client that no matter what happens, they can run your software for as long as they need it. That's not a small thing. Enterprise clients are making long-term operational decisions based on your software — budgets, headcount, and infrastructure. Software escrow is what makes that commitment credible, and for a lot of enterprise buyers, it's what makes you a vendor they'll actually sign with.
That's the trust dynamic at the heart of escrow. And it's worth keeping in mind as we get into SBOMs, since it touches on the same idea.
Why clients now ask for SBOMs along with escrow
Your enterprise clients' legal and procurement teams have spent the last few years watching catastrophic supply chain incidents play out in public. One vulnerable open-source library gets pulled into thousands of products. One dependency carries a flaw nobody caught before it shipped. The damage travels downstream.
The Cloudflare outage in November 2025 is proof of that — one routine configuration change, and thousands of sites went offline for six hours.
It pays to be cautious. Open-source components, third-party libraries, and external dependencies are a normal part of how software gets built — but they carry inherited risk. A library that's widely trusted today can have a critical vulnerability disclosed tomorrow. A dependency that's been stable for years can get abandoned, forked into something unmaintained, or quietly compromised. Your clients can't see any of that from the outside.
But an SBOM (which is basically a full inventory list of all the components used to build a piece of software) lets them track which components might carry risk and set up suitable recovery protocols in advance.
This isn't just a nice-to-have either. The EU's Cyber Resilience Act is making SBOM provision a legal requirement for software sold in Europe. CISA guidance in the US has been pointing in the same direction for a while, too. It's a compliance requirement on your client's end as well; they need to be able to demonstrate their recovery capabilities.
That's exactly why an escrow and SBOM combo is so valuable to them. When your client has both, they can cross-reference the SBOM against what's in the deposit and confirm everything that needs to be there is actually there. If they ever find themselves in a recovery scenario and something isn't building correctly, the SBOM gives them a map. They can identify exactly which piece is missing or broken, rather than trying to diagnose a problem with no reference point.
» Find out how IP Escrow can protect your intellectual property.
So how do you include an SBOM in an escrow deposit?
It's a pretty straightforward setup. You're not building a separate process or managing a parallel system. The SBOM slots into the deposit the same way everything else does. Here are three things worth thinking through to get it right:
-
Where it lives. Your SBOM goes directly into the escrow deposit alongside your source code — same vault, same update cadence. It's one more asset in the deposit, describing what the code next to it contains.
-
What format to use. The two you'll encounter are CycloneDX and SPDX. Both are machine-readable and recognized by enterprise procurement teams and regulatory auditors. You don't need to agonize over the choice; either works, and your toolchain probably already has a preference.
-
How it stays current. A six-month-old SBOM tells your client what was in your software when someone last ran the export, not what's in it today. If you've added a dependency, removed one, or updated a version since then, the SBOM is wrong. An automated daily sync mechanism is essential for keeping your SBOM updated alongside the code it describes.
An inaccurate SBOM is worse than not having one. It creates confidence in information that isn't current, and that's exactly the kind of issue a client needs to avoid during a recovery.
A deposited SBOM and a verified one aren't the same thing
Including an SBOM in your deposit is the right move. But on its own, it doesn't close the procurement requirement. It just raises the next one.
Procurement teams and auditors aren't looking for a document they'll just file away. They need confirmation that the document is accurate. That the components listed are actually present in the deposit. That the code is current. That the whole thing can be built from what's in the vault. Without that confirmation, an SBOM can't be trusted.
This is where verification comes in. Codekeeper runs automated checks against your deposit to confirm the escrowed materials are complete, current, and buildable — and that your SBOM accurately reflects what's there. When that process completes, Codekeeper issues a Software Resilience Certificate.
That certificate is what you hand over during a procurement meeting. It's documented, third-party proof that your deposit has been tested and your SBOM has been confirmed against it. For a procurement team satisfying DORA or NIS2 requirements, that's the artifact they need before they can sign for your software.
What this gets you in a sales conversation
Once you understand the mechanics, the commercial case writes itself. When your prospect's procurement team enquires about software escrow and an SBOM, you can say: both are handled, both are verified, here's the certificate.
That's a different conversation than "we'll sort out the SBOM and come back to you." The last thing you want is to delay a sale and let a competitor jump in while you get it sorted.
Besides, you only need to set it up once. Your software escrow agreement can be set up to include future clients as they sign on, and Codekeeper keeps everything current. That's a pretty low-friction setup to ensure you always have a favorable stance when entering procurement conversations.
The vendors worth trusting don't wait to be asked
Enterprise clients make up their minds about vendor reliability well before contracts get signed. The escrow arrangement, the verified SBOM, the certificate you can hand over — all of it tells your client the same thing: you've already thought about what happens to them if something goes wrong, and you've made sure they'll be all right.
That's the kind of vendor a client wants to sign with. And keep long-term.
» Take a look at how Codekeeper's verification testing offers proof software escrow contains everything your client needs — SBOM included.
