Third-Party Materials in Escrow Deposits...

A source code deposit can be complete down to the last file and still be impossible to build. The reason is usually something the depositor’s own developers rarely think about: the commercial compiler licensed to their build server, the reporting library purchased years ago, the plugin pulled from a vendor’s private repository, or the managed database service the application quietly depends on. None of these live inside the codebase. When a release condition occurs, the beneficiary often discovers these gaps at the exact moment the software is needed most.

This is one of the oldest and most universal issues in software escrow. It has existed for as long as escrow agreements have, and it affects on-premises software and SaaS applications alike. The good news is that beneficiaries have two well-established ways to address it, and a reliable method for confirming that either approach actually worked.

This guide walks through both options, how they compare, and why Technical Verification is the only way to know for certain that your deposit and its third-party dependencies are complete and accurate.

Why Third-Party Materials Matter in an Escrow Deposit

Modern software is assembled as much as it is written; a typical enterprise application relies on dozens, sometimes hundreds, of components the depositor did not create. Some are free and open source; others are commercial products licensed under terms the depositor agreed to individually.

The escrow deposit is meant to give a beneficiary what it needs to maintain and support the software if the provider can no longer do so. Source code alone rarely meets that goal. Without the tools, libraries, and environment needed to compile, configure, and run the application, the beneficiary holds a set of files it cannot turn back into working software.

What Counts as a Third-Party Material?

Third-party materials generally fall into a few categories:

• Build tools: commercial compilers, build automation tools, plugins and packaging utilities.
• Licensed libraries and SDKs: reporting engines, charting components, encryption modules and vendor-specific software development kits.
• Runtime components: database engines, application servers, middleware and specific runtime versions.
• Open-source dependencies: packages pulled from public repositories, which can be removed, renamed, or altered over time.
• SaaS and cloud dependencies: managed cloud services, third-party APIs, identity providers and infrastructure configurations that cannot be placed in a deposit as files.

That last category is especially relevant for SaaS escrow, where much of what keeps the application running exists as a service rather than as software that can be copied.

Option 1: Require the Depositor to Deposit the Third-Party Tools

The most direct approach is to require the depositor to include the third-party tools themselves in the escrow deposit, alongside the source code, documentation, and build instructions.

How It Works

The escrow agreement specifies that the deposit must contain all third-party software required to build, compile, and run the application. The depositor then places installers, binaries, libraries, or packages for those tools into the deposit with each update.

The Licensing Question

On the surface, this option can look like it conflicts with the depositor’s license commitments to its own vendors: many commercial licenses restrict copying, redistribution or transfer to another party.

The software escrow industry has long viewed deposit materials as archival backups. They are held securely, they are not installed or used in production, and they are released only under the specific conditions defined in the escrow agreement. Under that view, depositing a licensed tool is closer to keeping a backup copy than distributing the software to a new user.

That said, license terms vary widely. Some vendors explicitly permit escrow deposits, some are silent, and some prohibit transfer outright. A beneficiary that receives a licensed tool through an escrow release may also need its own license to use it going forward. The depositor’s legal team, and ideally the beneficiary’s, should review the relevant licenses before this requirement is finalized.

When Option 1 Works Best

Depositing the tools works well when the dependencies are open source, when commercial vendors permit archival copies, or when specific tool versions are difficult to obtain later. It offers the beneficiary the most self-contained deposit and removes the risk of a required tool disappearing from the market.

Option 2: Require an Updated List of Third-Party Tools

When depositing the tools themselves is not practical or permitted, the second option is to require the depositor to submit, and keep current, a detailed list of every third-party tool and dependency the software requires.

This is often treated as a fallback position during negotiations, and it can be very successful when the list is thorough and maintained.

What the List Should Include

A useful third-party materials list goes well beyond product names. At a minimum, it should capture:

• The name of each tool, library, or service
• The vendor or source (including repository location for open-source packages)
• The exact version or release used in the current build
• The license type and any known restrictions
• The role the component plays (build, runtime, testing, deployment)
• Configuration notes or settings required for the build
• For SaaS applications, the cloud services, APIs, and account dependencies the application relies on

Why the List Approach Works

A complete list gives the beneficiary a procurement roadmap. If a release occurs, the beneficiary knows exactly what to license, download, or provision to reconstruct the environment. It also avoids most licensing concerns, since no third-party software changes hands through the deposit.

Where the List Approach Falls Short

The list depends entirely on accuracy and upkeep. Versions change with nearly every release cycle, and older versions of commercial tools can become unavailable for purchase. If the list falls out of date, or if a dependency was never recorded in the first place, the beneficiary may not discover the gap until it is trying to rebuild the software under pressure.

Comparing the Two Approaches

Combining Both Options

Many escrow agreements land on a hybrid. The depositor deposits everything it is permitted to deposit, such as open-source packages and tools whose licenses allow archival copies, and maintains a detailed list for everything else, including commercial tools with restrictive licenses and cloud services that cannot be captured as files.

This structure gives the beneficiary the most coverage while respecting the depositor’s license obligations. It also creates a clear standard both parties can point to when deposits are updated.

Why Technical Verification Is the Only Way to Know for Sure

Regardless of which option you choose, both approaches share the same weakness: they rely on the depositor’s own assessment of what the software needs. Developers work in environments that have been configured over years. Tools installed long ago, environment variables set once and forgotten, and dependencies cached locally can all be invisible to the people writing the list or assembling the deposit.

The only way to confirm that the deposit and its third-party materials are complete and accurate is to test them through Technical Verification.

PRAXIS Technical Verification is built around a full rebuild standard. The software is compiled and assembled from the deposit materials, which exposes missing tools, undocumented dependencies, incorrect version numbers, and gaps in build instructions before a release condition ever occurs.

Verification is available at multiple levels, so the depth of testing can match the criticality of the application. At Level 3, for example, PRAXIS witnesses, evaluates, and video-captures the depositor building the software from source code, identifying the steps, resources, and artifacts the build requires. That video is placed alongside the source code, credentials, and documentation as part of the deposit, and PRAXIS provides a comprehensive findings report once the deposit material audit is complete. For third-party materials specifically, this process brings hidden dependencies to the surface and creates a record of exactly what the build used.

When findings do identify gaps, the depositor can remediate them, whether that means adding tools to the deposit, correcting the tools list, or updating build documentation. The beneficiary then holds a deposit that has been tested against reality rather than assumed to be complete.

Keeping Third-Party Materials Current Over Time

A verified deposit reflects the software at a single point in time. Third-party dependencies shift with every major release, so the agreement should address how they stay current.

Practical measures include requiring the tools list to be updated with every deposit, requiring re-verification after major releases or platform changes, and retaining prior deposits so earlier versions of tools and code remain available. PRAXIS Automated Escrow helps keep deposits aligned with the software as it evolves, and Infinite Retention preserves every deposit version, which matters when a specific older tool version is the one the build depends on.

Because deposit materials can include licensed software, credentials, and proprietary code, the security of the escrow agent also matters. PRAXIS is SOC 2 certified, giving both depositors and beneficiaries confidence in how those materials are protected.

Practical Steps for Beneficiaries

1. Identify the third-party requirement in your current agreement. Review whether the existing escrow agreement addresses third-party materials at all, and whether it requires deposits, a list, or neither.
2. Decide on your preferred position. Determine whether depositing the tools, maintaining a list, or a hybrid approach best fits the software and its licensing landscape.
3. Define what the list must contain. If a list is part of the agreement, specify the required fields, including exact versions and license information.
4. Address SaaS dependencies separately. Document cloud services, APIs, and infrastructure configurations that cannot be deposited as files.
5. Build verification into the agreement. Require Technical Verification at an appropriate level, along with re-verification after significant releases.
6. Remediation plan. Establish how verification findings will be addressed and how quickly the depositor must correct gaps.

The Bottom Line

Yes, you can require your software or SaaS provider to address third-party materials in the escrow deposit, and you have two dependable ways to do it. Depositing the tools offers the most self-contained protection, while a maintained tools list is a practical and often successful alternative when licensing gets in the way. Most agreements benefit from a combination of both.

Whichever path you choose, the deposit is only as reliable as its weakest dependency. Technical Verification turns assumptions about completeness into documented findings, so your organization knows its continuity plan will hold up when it counts.

Talk to PRAXIS about Technical Verification