Why software escrow matters more than ever

Why software escrow matters more than ever

Software is the backbone of modern operations. ERP platforms, industry-specific applications, AI systems, and SaaS tools run the workflows that businesses depend on every day. Most of these systems come from external providers, typically as SaaS, licensed custom software, or specialized industry platforms.

That creates a structural dependency on the vendor. As long as the vendor is healthy, the dependency is invisible. When the vendor falters, the consequences are immediate: maintenance and support stop, the source code stays out of reach, security patches are no longer issued, critical systems can fail, and emergency replacement projects rarely come cheap. For business-critical software, this kind of disruption can translate directly into operational and financial damage.

This is the gap software escrow closes.

What software escrow actually is

Software escrow is the deposit of a software product's source code with a neutral third party — the escrow agent. The model is also referred to as source code escrow.

The principle is simple. The source code is held securely and released only when contractually defined events occur (so-called release triggers). If those events are met, the licensee can continue operating, maintaining, and developing the software, even without the original vendor.

A standard arrangement involves three parties:

• The software vendor (licensor), who develops the product
• The licensee (customer), who uses the product
• The escrow agent, who holds the source code in trust

on:mint extends this classical escrow logic with a digital infrastructure for deposit, versioning, and controlled access — combining the legal contract layer with a modern technical layer in a single environment.

Access to the deposited code is granted only under clearly defined conditions: the release triggers.

Typical release scenarios

A source code deposit is never released arbitrarily. The escrow agreement specifies which events qualify as a trigger.

In practice, release clauses must be drafted carefully. Rather than tying release to a "hard" insolvency event, escrow agreements typically define a set of "softer" insolvency-adjacent scenarios. This approach aligns with established case law and avoids the risk of disadvantaging creditors.

Common release scenarios in source code escrow include:

• Discontinuation of business operations
• Breach of maintenance or support obligations
• Announced end-of-life of the software
• Acquisition of the vendor by a competitor
• Loss of key engineering staff
• Other contractually defined escalation or failure conditions

When a trigger event occurs, the escrow agent releases the deposited code in line with the agreed conditions. From there, the licensee can run the software in-house, perform maintenance and bug fixes, bring in external developers, or continue to evolve the product.

A well-structured source code escrow keeps the licensee operational — even in a worst-case scenario.

Why the legal structure has to be airtight

For software escrow to actually work when it matters, the legal architecture has to be precise.

Segregation from the insolvency estate

A central concern is that the deposited source code does not become part of the vendor's insolvency estate. This is achieved by placing the code with the escrow agent in trust, well before any insolvency event is on the horizon.

Note on jurisdiction: Bankruptcy-proof structuring (Insolvenzfestigkeit) is a specific requirement of German insolvency law. International escrow agreements operating under other legal frameworks do not necessarily face this exact issue, although comparable concerns around third-party access to escrowed assets in an insolvency scenario typically still apply in some form. The right structuring depends on the governing law of the agreement.

Insolvency-resilient usage rights at release

A source code deposit is only useful if the licensee is also legally permitted to use the code once it is released. Escrow agreements therefore typically include a conditional grant of usage rights: the license to use the code does not transfer up front, but takes effect when the contractually defined release conditions are met.

Contracts in favor of third parties

Escrow agreements are often structured so that the licensee, as the beneficiary, holds an independent claim to the release of the code once the agreed conditions are triggered. This is an important distinction from purely technical custody models. A robust escrow setup has to organize the deposit and secure legal access in the event of a release.

Synchronizing the license agreement with the escrow agreement

A common drafting mistake is to treat the license agreement and the software escrow agreement as separate documents. The result can be a paradox: the source code is released, but the licensee lacks the rights to actually use or develop it.

A clean structure requires alignment between three layers: the deposit obligation (what is deposited and when), the release criteria (what gets released under which conditions), and the license and usage rights to the source code. When these are synchronized, the system works as intended.

From software escrow to digital escrow

For most companies, the conversation starts with classical source code escrow. In practice, it quickly becomes clear that source code alone is rarely enough to keep a business-critical system running.

Modern applications are built from a wide range of technical and operational components. To keep them maintainable and continuable, you typically need more than the code itself:

• Training data for AI systems
• Large operational data sets
• Technical configuration information
• Cloud credentials
• Engineering and operational documentation

This is why modern escrow solutions extend the classical model into a broader concept: digital escrow. Different categories of digital assets can be deposited.

IP Escrow protects technical know-how and trade secrets — design data, technical specifications, and manufacturing details.

Key Escrow secures sensitive credentials such as passwords, cryptographic keys, and cloud access tokens.

Data Escrow preserves large data sets over the long term, including production data, analytics, and IoT data.

AI Escrow secures the central components of AI systems — model architectures, training data sets, and vector databases.

Together, digital escrow protects not just software, but the entire digital value base of an organization.

How software escrow works on on:mint

on:mint's Data & IP Integrity Platform combines legal escrow structures with a user friendly infrastructure for secure digital deposit. The goal is simple: a source code escrow that is both legally sound and technically verifiable.

For companies, the result isn't just a contract. It's an integrated setup in which legal release rules, technical deposit, and ongoing updates work as a single system.

The process moves through several stages.

1. Setting up the escrow

Each engagement starts with an individually drafted Software Escrow Agreement. The agreement specifies what is deposited, when the deposit takes place, the release criteria, and the usage rights that take effect upon release.

2. Depositing the source code

The vendor then deposits the full code base together with the technical artifacts required to actually work with it. A professional source code deposit goes well beyond the code itself and typically includes:

• The complete source code
• Build environments
• Dependencies and configuration files
• Technical documentation
• Installation and setup instructions
• Database schemas and migration information
• Infrastructure information
• Third-party component inventories

These artifacts are what make a deposited software stack reproducible, maintainable, and extensible in a release scenario. This is also where the difference between a simple code copy and a robust escrow becomes visible: only when the surrounding technical and operational information is complete can the deposited state actually be put to work.

3. Automated updates via repository integration

on:mint connects directly to GitHub and GitLab. New versions can be transferred automatically into the escrow system. Unlike a standard Git repository, the escrow stores complete versions rather than just diffs, so each version remains independently reconstructible.

4. Verification of the deposited material

A deposit is only as useful as the material inside it. If the files exist but cannot be built, run, or maintained, the escrow doesn't deliver on its promise.

on:mint can extend the deposit with full verification. Verification provides additional assurance for all parties involved and reduces the risk of a release scenario where the data is technically present but practically unusable.

The technical infrastructure behind the deposit

on:mint uses a combination of modern technologies to make software escrow particularly secure.

Blockchain as proof of integrity

Every deposited version is hashed cryptographically. The hash acts as a digital fingerprint of the code and is anchored on a public blockchain. This produces an immutable record of when a version existed and a verifiable proof that it has not been modified since. The source code itself remains confidential.

Decentralized storage on IPFS

The code itself is not stored on the blockchain, but in a decentralized storage system. on:mint runs an access-controlled IPFS infrastructure for this purpose.

IPFS addresses files by their content rather than by their storage location. Each file receives a unique Content Identifier (CID). This architecture has several advantages: higher availability, stronger tamper resistance, no central point of failure, and verifiable integrity at the level of individual versions. Distributing files across multiple storage nodes makes the system resilient and reduces single-point-of-failure risk.

The Data Vault: a digital safe for software escrow

The Data Vault is a central component of the platform. It functions as a digital safe for all assets deposited within the software escrow. Access is controlled through token-based authentication and role-based permissions, allowing precise control over who has access, what actions are permitted, and under which conditions data can be released.

Within a Vault, multiple data rooms — referred to as Streams — can be configured to separate source code, documentation, and technical assets. This makes it possible to model complex escrow structures across vendor, customer, and escrow agent.

What sets on:mint apart is the way it brings these layers together: the legal custody logic, versioning, controlled access, and verifiable documentation all live in one system.

What companies should look for in a software escrow

Not every piece of software needs an escrow. The case becomes compelling whenever a company is materially dependent on a specific solution. Typical scenarios include:

• Business-critical software in core operations
• Custom software or proprietary platforms
• Long-term dependency on a single vendor
• Specialized industry solutions
• Software embedded in production or data pipelines

For custom software and specialized SaaS, switching vendors quickly is rarely realistic. Without source code escrow, this exposes the business to significant operational risk.

The right question isn't only whether a deposit exists, but how reliable it actually is:

• Is only the code deposited, or also the supporting documentation?
• Are the build environment and dependencies fully captured?
• Are the release rules clear and legally robust?
• Is the deposited state current and properly versioned?
• Has the completeness of the material been verified?

A professional source code deposit reduces risk only when legal structure and technical execution are in alignment.

Software escrow as a safeguard for digital business models

The digital economy increasingly runs on software, data, and platform technology — and so does the dependency on the providers of those technologies. Software escrow, and in particular a professional source code deposit, gives companies a structured way to manage that exposure.

Solutions like on:mint combine legal escrow structures with modern infrastructure for source code escrow. The result: companies retain control over business-critical software, even when vendors fail or stop meeting their obligations. That makes software escrow a foundational element of any modern digital risk strategy.