Cyber Resilience Act and escrow: when does safeguarding matter?

What is the relationship between the Cyber Resilience Act and escrow? Learn when source code, documentation and cryptographic keys matter for business continuity.

The Cyber Resilience Act introduces European cybersecurity requirements for certain hardware and software products with digital elements. A key principle is that security is not only relevant during development or at the point of sale. Maintenance, support and vulnerability handling throughout a product's lifetime also play a role.

This can affect the way organisations look at their dependency on software and technology vendors.

If maintenance is only possible using materials to which a single vendor has exclusive access, a continuity risk arises.

What is escrow?

Escrow is an arrangement in which predefined materials are placed with an independent third party.

For software this can involve source code, documentation and build information.

For other digital products, firmware, configurations, certificates or cryptographic keys may also be relevant.

The independent party stores the materials and releases them only when predefined conditions are met.

The principle is that the vendor does not have to hand over its confidential materials to the user by default, while the user still has a fallback for exceptional circumstances.

Why does this become relevant under the Cyber Resilience Act?

The CRA requires manufacturers to manage cybersecurity risks across the different phases of the product lifecycle.

Manufacturers must also define a support period during which vulnerabilities are handled effectively.

Where maintenance remains necessary during that period, the continuity of the materials required for it also matters.

This does not mean the CRA makes escrow mandatory.

It does mean organisations can examine whether certain technical dependencies are sufficiently safeguarded.

Example: cryptographic keys

An FHI event on cybersecurity named cryptographic keys as a practical example of such a dependency.

Keys may be needed for secure boot, firmware updates, authentication and secure communication. If a vendor disappears and no one else can obtain access to the necessary key, maintenance or production can be obstructed.

Key escrow can be used in such a situation to hold a key independently under controlled conditions.

Because cryptographic keys are highly sensitive, access, security and release procedures must be designed with care.

Deposit, verification and continuity

When assessing an escrow arrangement, it helps to keep three separate topics apart.

Deposit

The deposit describes which materials are stored independently.

It must match the components that are actually needed to maintain or restore the product.

Verification

Verification checks the deposited materials.

This can range from a check on presence and readability to a technical test establishing whether software can be rebuilt reproducibly from the materials.

Continuity

Continuity concerns the situation after a disruption occurs.

Questions that arise include:

  • When may the materials be released?
  • Who gains access?
  • Which rights does that party receive?
  • Which vendor can take over maintenance?
  • Are additional infrastructure or services required?
  • Can security updates still be produced and distributed afterwards?

A well-filled deposit without a workable follow-up procedure does not automatically provide continuity.

Who can this be relevant for?

Escrow can be considered by organisations that depend on business-critical software or digital products.

That can be relevant for software users, vendors, procurement departments, legal teams, risk management and product owners.

Relevance increases when:

  • the product must be supported over a long period;
  • a single vendor controls essential technology;
  • source code is not available elsewhere;
  • firmware can only be signed by one party;
  • transfer to an alternative vendor is complex;
  • an outage has significant operational consequences.

Assessment checklist

First map the technical dependencies.

Then check:

  1. which materials are needed for maintenance;
  2. who controls those materials;
  3. which third parties are indispensable;
  4. which components are not easily replaceable;
  5. whether an independent deposit is necessary;
  6. which verification level is appropriate;
  7. which circumstances may trigger a release;
  8. which rights are needed after release;
  9. who can practically carry out the continuity work.

Only then can it be determined whether software escrow, key escrow or another continuity measure is appropriate.

Key CRA dates

The CRA entered into force on 10 December 2024.

The reporting obligations under Article 14 apply from 11 September 2026. The main obligations of the regulation apply in full from 11 December 2027.

Conclusion

The Cyber Resilience Act turns cybersecurity into a topic that must be managed throughout the lifecycle of digital products.

Vendor dependency can become relevant in that context.

Escrow is not a statutory default solution, but it can be applied where continuity depends on source code, documentation, firmware, keys or other materials concentrated with a single party.

Which form is appropriate depends on the product, the risk and the technical chain.

Anyone considering an escrow solution can compare different escrow arrangements and independent escrow agents, and have it assessed which form fits the specific continuity risk.

Sources