CRA Third-Party Component Escrow

Meet your five-year CRA component duty with verified escrow.

From 11 December 2027, the CRA’s Article 13(5) holds you responsible for every component you integrate with, even unmaintained open-source ones. Third-Party Component Escrow deposits each with its supplier docs — kept current and verified for your support period.

Book a demo Get a sample pack

Every component deposited, current, and verified.

Component deposit

CRA Art. 13(5) Component Set — Verified

Supplier

Last sync Today

Verification Complete

CRA EU AI Act NIS2 DORA ISO 27001

Software Resilience Certificate Certified tier · signed

openssl 3.0.14 Verified

LicenseApache-2.0

Supplier docsHeld

Versions kept12

Join 3 500+ companies that trust Codekeeper to keep every component current and verified.

Article 13(8) demands you patch your product and its components for your entire support period. A component abandoned upstream leaves you owing a fix you cannot build. Third-Party Component Escrow keeps every component recoverable, so your conformity stops depending on who still publishes that component.

CRA

EU AI Act

NIS2

DORA

ISO 27001

SOC 2

One verified escrow deposit for the third-party component requirements running through your compliance frameworks.

The old way

A one-time component backup jeopardizes CRA compliance

Most manufacturers archive one copy of their third-party and open-source components, or pull each one from a package registry at build time. That worked while a dependency was only a build-time concern. Article 13(8) now requires patches for those same components years after you ship.

Registries delete versions, projects are abandoned, suppliers stop shipping. Once a component exists nowhere upstream, you cannot reproduce it — or patch the product it shipped in. Failing Article 13 costs up to €15 million.

The archived component copy

components-v2.1.zip ZIP

Archived · 14 Mar 2024

Out of Date

Captured once — while upstream deletes, abandons, and moves on.

Why we built it

Escrow built for the code you did not write

Codekeeper has protected third-party component access for over a decade. A recovery limited to your own source code stalls on the open-source libraries and licensed vendor code inside your product. Our automated deposits, integrity checks, and version control hold every third-party component at the version you shipped.

10+

years managing escrow

3 500+

companies protected

ISO 27001

certified

50+

integrations

Six capabilities behind provable component due diligence

Each capability closes a different gap in keeping third-party components reachable across your product’s support period.

Component-level deposits

Every third-party and open-source component you integrate is deposited in full, together with the supplier documentation describing what that component does.

Immutable encrypted vault

Deposits are held in AES256/512 encrypted, tamper-proof storage outside your infrastructure, so a breach, corruption, or deletion on your systems cannot reach the components.

Automated deposit syncing

Codekeeper syncs component changes from your connected repositories and cloud platforms across 50+ integrations, so every release you ship has its components captured and current.

Documented version history

Each deposit is stored as its own dated version, and you set how many to retain, so a four-year-old product draws the components that shipped inside it.

Verified deposit contents

Verification confirms your deposited components are present, complete, and structurally sound, and your Software Resilience Certificate records what was checked and when.

Supplier documentation sourcing

Codekeeper can approach each component supplier for the integration and security documentation the CRA obliges them to provide, and deposit what they return as a dated record.

How it works

How Third-Party Component Escrow works

Setup is live in 24 hours. After that, every component deposit updates on its own schedule, and Codekeeper confirms what is held long before a market surveillance authority asks to see it.

Acme Gateway 4.2 In-scope components

3 of 4

openssl 3.0.14 · Apache-2.0

zlib 1.3.1 · Zlib

Embedded Linux BSP 6.1 · vendor licensed

protobuf 25.3 · BSD-3-Clause

1. Identify your in-scope components.

You list the third-party and open-source components integrated into each product, and connect the repositories and cloud platforms they are pulled into.

Deposits

3 active · last verified today

Software Resilience Certificate

Software Resilience
Certificate

Passed

2. Codekeeper deposits and verifies each component.

Each component is deposited with its documentation, every change stored as a dated version, and the deposit verified against what your product contains.

Codekeeper Software Resilience Certificate

ProviderAcme Gateway 4.2

TierCertified

ComponentsPassed · 14 Jun 2026

Valid to14 Jun 2027

Authorized · Codekeeper

Verified

3. Produce your component evidence on request.

On a reasoned request under Article 13(22), you draw the exact deposit version they need, with its Software Resilience Certificate.

Set up in a day. From there, the deposit stays current on its own.

Book a demo

These companies’ systems are protected, compliant, and resilient.

They made the decision. They built their resilience. They have peace of mind. You can too.

“We’ve had a great experience with CodeKeeper. The setup process was smooth, and the team made everything very straightforward. Knowing our critical software assets are securely protected gives us real peace of mind. Their support has been responsive and professional, and the overall service has been reliable and easy to work with. Highly recommended.”

Jordan Adler

“We worked with Codekeeper as our escrow provider for major enterprise deployments and found them to be extremely professional, responsive, and flexible throughout.
I'd highly recommend Codekeeper. They clearly understand the realities of working with growing tech businesses and enterprise customers alike.”

Ross Kilshaw

I found Codekeeper's solution excellent for what I need. I scheduled a demo to better understand the possibilities. Very easy! It was a clear and straightforward meeting, focused exactly on what I needed. Excellent service!

Thiago Mendes

Framework mapping

One escrow solution for multi-framework compliance

Third-party component obligations repeat across the regulations you already report against, and each one puts the duty on a different party. One escrow deposit, kept current and verified, produces what each framework expects to see.

CRA — Art. 13(5) Every integrated third-party component, kept patchable across the support period.

EU AI Act — Art. 25(4) Component information and technical access for a high-risk AI system provider.

NIS2 — Art. 21(3) Component and secure-development evidence for each direct supplier.

DORA — Art. 28(4)(d) Pre-contract due-diligence records for each ICT third-party service provider.

ISO 27001 — A.5.21 Documented control of component risk across your ICT supply chain.

SOC 2 — CC9.2 Vendor risk evidence covering every component supplier you rely on.

Buying components rather than writing them? The CRA’s Article 3(1) makes your supplier a manufacturer too, so their component documentation in escrow enforces an existing duty.

What's at stake

Your component evidence decides how the CRA review ends

Without Third-Party Component Escrow

€15 million or 2.5% of annual turnover for failing the Article 13(5) due-diligence duty.
€5 million or 1% of annual turnover for handing a market surveillance authority an incomplete component record.
Corrective measures come on top of the fine so a restricted, recalled, or withdrawn product costs you twice.
A component withdrawn upstream leaves you unable to rebuild the release that shipped — or patch a vulnerability you now own.
Time lost chasing every component supplier for their integration and security documentation yourself.

24 hrs the CRA’s Article 14 allows one day to flag an actively exploited vulnerability. An unidentifiable component turns that into a breach at the top penalty tier.

With Third-Party Component Escrow

Every component you integrate deposited in full, outside the systems and registries that could lose it.
Every dated version stays retrievable — even for a four-year-old product.
Verification confirms each deposit is complete, and the Software Resilience Certificate records what was checked and when.
A reasoned request becomes a retrieval, not a reconstruction.
Codekeeper can approach your component suppliers for their documentation and deposit what they return, so your team stops chasing.

Book a demo

Sample

Inside a third-party component escrow report

A sample report showing every deposited version of your component set, the supplier documentation held against it, and the verification result confirming the deposit matches the components your product contains under the CRA’s Annex I Part II point 1.

Component set · versions

Verification results

Codekeeper Software Resilience Report

ProductAcme Cloud Ltd

TierCertified

SBOM verifiedComplete · 14 Jun 2026

Components1,284 · CycloneDX

Issued by Codekeeper

Verified

Get the sample component escrow report

We’ll email the sample component escrow report to you.

Preserve every third-party component you ship.

Liability for a third-party component never comes with an easy way to control it. Without that control, you face regulatory penalties — even a market ban. An independent escrow deposit gives you the control you need to turn a dependency you cannot govern into an asset you hold.

Book a demo Get a sample pack

Frequently asked questions

What counts as a third-party component under CRA Article 13(5)?

A third-party component under the CRA’s Article 13(5) is any software or hardware sourced from outside your own development and integrated into your product with digital elements. Article 3(6) defines a component as software or hardware intended for integration into an electronic information system, so a licensed SDK, an embedded operating system, a protocol stack, a container base image, a package registry dependency, and an AI model all qualify.

What is CRA Third-Party Component Escrow?

CRA Third-Party Component Escrow is escrowed, versioned storage of the third-party and open-source components integrated into your product, together with the supplier documentation behind those components and a verification result confirming each deposit is complete. Codekeeper syncs the deposit as your components change and holds every version independently of your own systems and of the registries you pulled from.

Does the CRA due-diligence duty apply to open-source components?

Yes. The CRA’s Article 13(5) names them directly, including components of free and open-source software never made available on the market in the course of a commercial activity. So an open-source component can fall entirely outside the CRA, the maintainer of that component can hold no obligations under the Regulation, and your duty over that component still stands.

Can a manufacturer transfer the CRA component due-diligence duty to the component supplier?

No. The CRA’s Article 13(5) places the duty on the manufacturer integrating the component, and Article 64(10)(b) exempts open-source software stewards from administrative fines altogether. A supplier failing upstream reduces nothing you owe, which is why an independent deposit of the components matters.

How long must a manufacturer keep third-party components available under the CRA?

The CRA sets no retention period for the components themselves. What runs long is the duty attached to them. Article 13(8) requires you to handle vulnerabilities in your product and its components across your product’s whole support period, a minimum of five years, and Article 13(13) requires your technical documentation to stay at the disposal of market surveillance authorities for at least ten years or the support period, whichever is longer. Holding the components is how you stay able to meet the first duty.

Does a manufacturer have to report vulnerabilities found in a third-party component?

Yes. The CRA’s Article 13(6) requires you to report the vulnerability to the person or entity manufacturing or maintaining that component, including an open-source component, and to remediate it under Annex I Part II. Where you developed a fix, you must share the relevant code or documentation with that maintainer, in machine-readable format where appropriate.

How is this different from a component scanner or a CRA due-diligence assessment?

A scanner and an assessor tell you whether a component is safe to integrate; escrow holds the component and the record behind that decision. Codekeeper renders no judgment on your components or your suppliers. Most manufacturers need both: an assessment to run the check, and a deposit to keep the component reachable afterwards.

How is this different from keeping components in our own repositories or registry mirrors?

A deposit is held by an independent party, outside the systems that could lose the component and outside the registries that could withdraw it. Mirrors are pruned, repositories are migrated and retired, and version history usually breaks in the move. A review of a four-year-old product needs the components that shipped, which working infrastructure rarely still holds.

What happens if a component supplier stops trading or a component is withdrawn from a package registry?

A component held in escrow stays reachable through a supplier ceasing to trade and through a registry withdrawal alike. The deposit continues independently of your supplier’s status and of whether the component remains published anywhere upstream, so the version you integrated is still retrievable. Without a deposit, a withdrawn component leaves you unable to evidence what you shipped and unable to rebuild the product to patch it.

Which regulations does Third-Party Component Escrow support?

It supports the CRA most directly, covering the component due-diligence duty under Article 13(5) and the component vulnerability-handling duty under Article 13(8). The same deposit serves the written-agreement duty in EU AI Act Article 25(4), supplier assessment under NIS2 Article 21(3), pre-contract due diligence under DORA Article 28(4)(d), ICT supply chain risk management under ISO 27001 A.5.21, and vendor risk assessment under SOC 2 CC9.2.