How do you carry out open-source component due diligence under the CRA?
Article 13(5) requires a manufacturer to carry out due diligence when integrating third-party components, including free and open-source components not made available in the course of a commercial activity, so that those components do not compromise the product's cybersecurity. That duty sits with the manufacturer, not with the open-source maintainers or with any implementation partner. The scope of the work depends on what each component does inside the product. A logging library, a cryptographic module, a TLS stack and an update client carry very different risk, so the first decision is to map each integrated component against the functions the product relies on, such as cryptographic functions, update mechanisms and secure communications. No fixed price or duration is supplied for this work, so the reader should ask for a written scope that lists the components, the checks and the records before estimating effort.
The verification itself draws on the component's documentation, its security update history, its known vulnerabilities in public databases, its software bill of materials where one exists, its support period and an assessment of its maintainer's security posture. Software composition analysis is the usual way to surface known vulnerabilities at scale, and the Commission's FAQ also lists sandboxing or isolating highly critical components as an option. Where a component is central and poorly documented, testing may be the only way to close the gap. An implementation partner can set up the verification records, the scanning tooling and the review workflow, and can document what was checked and when. Those records are one-time setup plus recurring work, because components change and new vulnerabilities are published after integration.
Responsibility for the conclusions stays with the organization, which must decide whether each component is acceptable, what to isolate, and what to remediate or replace. Where the product's conformity route requires a notified body, that body assesses conformity, and no consultant or tooling vendor can issue that outcome. Our reading of the route for a given product should be confirmed against the regulation and the Commission's guidance before the due diligence file is finalized. Reading the guidance and the FAQ early helps the team match its records to what an assessor will expect to see.
Which checks the Commission lists for third-party components
Article 13(5) asks manufacturers to exercise due diligence before integrating third-party or open-source components. The Commission's FAQ 4.4.2 lists the checks that show whether a component can be trusted, and each one produces different evidence for the integrator's file. Work through them together, because no single check covers the whole question.
CE marking check
Confirm whether the component already carries a CE marking and, if it does, which conformity route was used. For a component that is not commercially supplied, such as much open-source software, there may be no marking at all, so the absence is itself a finding to record. The evidence is the marking or the documented reason it is missing. The question it answers is whether anyone has already assessed this component against the essential requirements, or whether the integrator must do that work.
Security update history
Review how quickly and how consistently the component's maintainers have released security fixes in past releases. A project with a long record of published advisories and prompt patches tells a different story from one with silent fixes or none. The evidence is a dated list of past advisories, releases and fix turnaround. The question it answers is whether the component is likely to receive fixes for the support period your product needs.
Known vulnerabilities in public databases
Check the European vulnerability database and other public vulnerability databases for open and resolved issues affecting the exact version you plan to ship. Record the version, the database queried, the date of the query and each finding's status. The evidence is a dated query record tied to the version. The question it answers is which known weaknesses the integrator inherits on day one and whether a fix or mitigation exists.
Software composition analysis
Run software composition analysis on the component to identify its own dependencies, licenses and known vulnerable libraries. A component can be clean while the libraries it pulls in are not, so the scan must cover transitive dependencies. The evidence is a scan report with the tool, version and date recorded. The question it answers is what the component actually contains once it is built into your product.
Component SBOM review
Where the maintainer publishes a software bill of materials, review it against the build you intend to ship and against the component version you have pinned. Check that the listed components, versions and hashes match what you will integrate. The evidence is the reviewed SBOM with a note of any gaps. The question it answers is whether the component's own inventory is accurate enough to feed your product SBOM without guesswork.
Support period and maintainer posture
Confirm the component's support period, meaning whether its maintainers are still committed to releasing fixes, and assess the maintainer's security posture, including their disclosure process, release signing and governance. For a single-maintainer project or one that has stopped releasing, the risk of inheriting an unfixed flaw rises sharply. The evidence is a written assessment with dates and sources. The question it answers is whether anyone will still fix this component when you need it.
How to run due diligence from inventory to a documented decision
This sequence turns a list of integrated open-source and third-party components into a documented decision for each one, with a recheck schedule that keeps the decisions current. Each phase produces an artifact that the next phase depends on, so the record can be shown to an assessor or market surveillance authority.
Build the inventory of integrated components
The product team starts from the SBOM for the release in scope and lists every third-party and open-source component the product ships or depends on at runtime, including transitive dependencies, container base images and bundled libraries. Each entry records the name, version, supplier or maintainer, license and where it sits in the architecture. The step is done when the inventory matches the build output for that release, and someone other than the author has checked it against the SBOM. Components that are not in the SBOM are a gap to fix before moving on.
Map each component to the functions it serves
For each entry, the engineering and security leads write down what the product relies on that component to do, such as cryptographic functions, authentication, update mechanisms, secure communications, parsing of untrusted input or network exposure. The Commission guidance treats this functional mapping as the starting point for due diligence, because the depth of checking depends on what the component is trusted to do. The output is a table linking each component to its functions and a flag for components that touch security-critical functions. Components with no security role are recorded as such, with the reason.
Run vulnerability and support checks
The security team runs software composition analysis against the inventory and checks each component against the European vulnerability database and other public vulnerability sources. For each component, they review its security update history, confirm the version in use is still supported by its maintainer, and check the component's own SBOM where one exists. They also look at the maintainer's security posture, such as how it publishes advisories and fixes. The output is a findings list per component with known vulnerabilities, support status and open questions, which feeds the risk decision in a later phase.
Test components where the risk requires it
For components that handle security-critical functions or show unresolved findings, the security engineers decide what testing is proportionate. Options include reviewing the component's conformity or assurance documentation, running targeted tests against the functions the product uses, fuzzing parsers, and confirming configuration defaults. Highly critical components may be sandboxed or isolated from the rest of the product, which the Commission lists among the actions manufacturers may take. The output is a short test record per tested component, with results, the version tested and any defects found, and a note on components that were not tested and why.
Record a risk decision for each component
The product owner and security lead agree a decision for every component, using the functional map, the findings and the test results. Typical outcomes are to accept the component as is, accept it with compensating controls such as isolation or configuration limits, upgrade or replace it, or remove it. Where a vulnerability is found in an integrated component, the record also shows the report to the maintainer and any fix the manufacturer develops, as Article 13(6) requires. The output is one signed decision record per component, with the reasons, the owner and the date, stored with the technical documentation.
Set a recheck cadence and triggers
The team sets how often each decision is reviewed and which events force an earlier review, such as a new vulnerability in a component, an end of support notice, a new release of the component, or a change in how the product uses it. The recheck cadence is set by the product owner and approved by whoever signs the risk decisions. The output is a review calendar and a trigger list stored with the decision records, and a named owner for each component. Confirm with your own assessor how they expect the cadence to be evidenced.
When to sandbox or isolate a component instead of trusting it
Commission CRA FAQ 4.4.2 lists sandboxing or isolating highly critical components among the actions a manufacturer may take when integrating third-party components. The clearest case is a component that runs with broad privileges, such as one that holds cryptographic keys, manages authentication, or can write to storage and network interfaces the rest of the product relies on. Due diligence may show that the component is well maintained and has a clean vulnerability history, but a flaw in it would still reach everything the product protects, so isolation limits the blast radius even when the component is trusted.
- Process separation: Run the component in its own process under a dedicated low-privilege account, so a compromise does not inherit the parent's rights.
- Container or VM boundary: Place the component in a container with restricted capabilities, read-only file systems and a seccomp profile, or in a separate virtual machine where the threat model justifies the extra cost.
- Narrow interfaces: Expose only the functions the product needs through a defined API, and log every call across the boundary.
- Least-privilege network policy: Allow only the specific connections the component requires, and deny the rest by default.
Keep the threat model, the privilege inventory before and after isolation, configuration files, and test results that show a simulated compromise cannot reach protected assets. Isolation lowers residual risk for privilege escalation but does not remove the need to track the component's vulnerabilities.
Some components exist to parse data from outside the product, such as image decoders, document converters, XML or JSON parsers, protocol libraries and media codecs. Their risk comes from malformed or hostile input, which can trigger memory corruption, resource exhaustion or logic errors. Isolation is useful here because the failure is often triggered by content the component is designed to read, not by an attacker who already has access to the product. Even a well-tested parser has a history of defects, so a sandbox turns a parsing flaw into a contained crash instead of a compromise of the surrounding system.
- Parser in a separate worker: Move parsing into a worker process that receives input over a narrow channel and returns structured output, with a timeout and memory limit.
- Resource limits: Cap CPU time, memory and file size per request so that crafted input cannot starve the rest of the product.
- Input validation before the boundary: Reject oversized or malformed input early, while treating the validator as a control that also needs testing.
- Fuzz testing: Run fuzzers against the isolated component and record crashes, coverage figures and fixed defects.
Keep the input handling design, sandbox configuration, fuzzing reports and crash handling logs. Isolation reduces the impact of parsing defects, while fuzzing and upstream reporting address their cause.
Due diligence under Article 13(5) includes checking the component's support period, its security update history and the security posture of the people or organization maintaining it. A component that is abandoned, updated rarely, or maintained by an unidentified group may still work well, but the manufacturer cannot count on fixes arriving. Where such a component cannot be replaced, isolation becomes a compensating measure. Article 13(6) also applies: if the manufacturer finds a vulnerability, it must report it to the maintainer and share any fix it develops, which is harder when no maintainer responds. Illustrative example: a manufacturer finds an unmaintained image library used for thumbnails and isolates it so that a future defect cannot reach account data.
- Replacement assessment: Record whether an actively maintained alternative exists and what migration would cost, before deciding to isolate.
- Fork ownership: If the manufacturer maintains a fork, document who is responsible for patches and the support period for that fork.
- Upstream contact attempts: Keep dated records of reports sent to the maintainer and any responses, as evidence for Article 13(6).
- Hardened deployment: Apply the strongest sandbox available, and restrict the component to the features the product uses.
Keep the support assessment, the replacement analysis, upstream correspondence and a decision record stating why the component was retained. Isolation does not replace a maintained component, so the decision should be revisited when support changes.
No single architecture fits every component, so the choice should follow the risk the component introduces, the privileges it needs and the cost of operating the boundary. The main options are no isolation, process separation, containers, virtual machines and separate hardware or services. Each step up adds protection but also adds complexity, performance overhead and operational work for the platform team. The CRA asks manufacturers to justify their decisions through the risk assessment, so the reasoning matters as much as the configuration. Readers should confirm the specific features of any sandboxing tool in their own environment, because capabilities differ by platform.
- Option comparison: Record each option considered, the residual risk it leaves, and the reason for the selected option.
- Residual risk statement: State what remains after isolation, such as a vulnerability in the isolated component that still affects the functions it exposes.
- Testing of the boundary: Verify that the boundary behaves as designed through negative tests, including attempts to reach files, networks or secrets outside its scope.
- Review trigger: Set conditions for reassessment, such as a new major version, a change in privileges or a serious upstream vulnerability.
- Ownership: Assign who maintains the sandbox configuration across the support period.
Keep the decision record, boundary test results and review log together, and ask any implementation partner to deliver them with the configuration. Only an independent assessor can judge whether the resulting documentation satisfies the regulation.
What to do when you find a vulnerability in an open-source component
Article 13(6) requires a manufacturer that finds a vulnerability in an integrated component, including an open-source component, to report it to the person or entity maintaining that component and to share any fix the manufacturer develops. The first practical step is to confirm the finding. Reproduce the issue against the exact component version in your product's SBOM, record which build and configuration you tested, and decide whether the flaw is reachable in your product. A scanner hit on a dependency that your code never calls is a different case from a reachable flaw, and your records should show which one you concluded and why.
Next, check whether the vulnerability already has an advisory. Search the public databases your software composition analysis tool uses, the European vulnerability database and the component's own security policy or issue tracker. If an advisory and fixed release exist, your main task is to upgrade or patch and to document the date you learned of the issue. If none exists, contact the maintainer through the channel the project publishes, usually a private security address, and send enough detail to reproduce the problem. Keep the report factual and avoid public disclosure before the maintainer has had a reasonable chance to respond. Confirm with counsel how your contract or licence terms apply to the exchange.
Where you develop a fix, share it with the maintainer as a patch or pull request and keep your own fork change set minimal and traceable. Store the report, the maintainer's acknowledgement, the patch, the version it applies to and any reply in your vulnerability records, linked to the affected SBOM entry. That trail is the evidence an assessor will ask for when testing Article 13(6). Article 14 reporting to ENISA is a separate duty, with its own triggers and deadlines. Decide early whether the finding also meets that threshold, and use the CRA reporting obligations guidance as the next step before you act on it.
Who owns the due diligence, who prepares the evidence and who assesses it
Due diligence on third-party and open-source components is split across four roles, and each role produces a different output. Keeping those outputs traceable, from the component inventory to the final conformity file, is what lets an assessor follow one component through the whole chain. DeployOpen does not issue reports or certificates.
Manufacturer owns the decision
Under Article 13(5), the manufacturer is accountable for every third-party and open-source component it integrates, including components that no supplier sells. Only the manufacturer can accept the residual risk of a component, record why it was accepted, and decide whether to replace, isolate or keep it. Assign a named owner to each component, keep a written decision log, and set a review trigger that fires whenever a new known vulnerability is published.
Implementation partner prepares evidence
An implementation partner such as DeployOpen can build the component inventory, the software composition analysis pipeline, the verification records and the sandboxing setup inside the client's own cloud accounts, data centers or air-gapped networks. The partner prepares evidence for the manufacturer to review, but the manufacturer still makes the decisions. Ask for scope, deliverables and handover format in writing before work starts, and confirm who holds the credentials and how records stay current after handover.
Component maintainer receives reports
Under Article 13(6), when a manufacturer finds a vulnerability in an integrated component, including open-source code, it must report the vulnerability to the entity maintaining that component and share any fix it develops. The maintainer is usually not your contractor and owes you no service level unless a contract says so. Before integration, check whether the upstream project publishes a security contact and advisories, and confirm that your fix can be contributed back under the component's license.
Independent auditor or notified body assesses
Most products follow self-assessment under module A, but a notified body is needed for class II and critical products, and for class I important products where harmonized standards are not applied in full. The independent body assesses conformity and issues any certificate, so your due diligence records may be examined by a third party before CE marking. Confirm your conformity route early, because the route determines who reviews your component records.
Questions buyers ask about CRA open-source due diligence
Does a manufacturer have to check every open-source library in its product?
Yes, every integrated third-party or open-source component needs due diligence under Article 13(5), but the depth of the check can vary. The duty applies when a manufacturer integrates a component, including free and open-source software not made available in the course of a commercial activity, so that the product's cybersecurity is not compromised. The practical starting point is to identify what the product needs from each component, such as cryptographic functions, update mechanisms or secure communications, and then verify those functions through documentation, assurance evidence and, where appropriate, testing. Components that touch none of these functions need a lighter check. Confirm the depth you apply with your notified body or conformity assessment provider, and read section 7.3 of the Commission guidance before settling your method.
What drives the effort of open-source component due diligence?
The effort rises with the number of components, the product's class and how often components change. A product with a few dozen dependencies in a default-category product has a very different workload from a class II important product with thousands of transitive packages updated every month. Ask these questions before you agree on scope:
- How many direct and transitive components does the product integrate, and are they recorded in an SBOM?
- Which components implement cryptography, updates or secure communications, since those need deeper verification?
- How frequently do upstream releases arrive, and how quickly must you review each one?
- Does the product class require a notified body, which changes how much evidence must be retained?
Recurring work, such as reviewing new releases and vulnerability reports, usually outweighs the one-time initial review.
Can software composition analysis tools alone satisfy the due diligence duty?
No, software composition analysis is one action among several, not a complete due diligence process. Commission CRA FAQ 4.4.2 lists checking public vulnerability databases, performing software composition analysis, reviewing the component's SBOM, checking the security update history, confirming the support period, assessing the manufacturer's security posture and, where relevant, sandboxing highly critical components. An SCA tool covers the vulnerability lookup and inventory parts well. It does not judge whether a component's maintainers patch promptly, whether a component's support period matches your product's support period, or whether isolation is needed. Those judgments must be documented by your team. Confirm with your assessor how they expect the evidence to combine tool output and human review.
Can our own engineering team carry out CRA component due diligence in-house?
Often yes, provided the team has the skills and time to complete the documented steps. The duty falls on the manufacturer, which means the organization owns the decisions, the records and the conclusions. Internal teams usually handle the inventory, SCA output and upstream monitoring well, while security expertise is needed for judging critical components, designing sandboxing and reviewing cryptographic dependencies. Many organizations split the work: internal staff keep the component register current, and an outside specialist sets the method, performs the deeper reviews and prepares the evidence file. An implementation partner such as DeployOpen can plan, implement and document the process inside your environment, but it does not issue assessment reports or certificates; an independent assessor does that.
What does an implementation partner need from our team to start?
A partner needs an accurate picture of the product, its build pipeline and the people who make release decisions. Most fixed-scope engagements begin with a written scope agreed before work starts, so the inputs should be ready early. Prepare these items:
- The current product architecture and a list of integrated components, with versions
- Any existing SBOM output and the tools that generate it
- Release and update processes, including who approves a component change
- Documents describing the product's support period and intended lifetime
- Access to the source repositories, build systems and test environments inside your infrastructure
The quality of these inputs strongly affects the quote, so ask the partner to list them in the written scope.
Must a notified body review our open-source component checks?
It depends on your product class and the conformity route you follow. Most products use self-assessment under module A, but a notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II and critical products (Article 32; Commission CRA FAQ 6.1 and 6.2). Where a notified body is involved, expect it to review how you identified and verified components as part of the technical documentation. Even where self-assessment applies, you must keep the evidence available for market surveillance authorities. Confirm the route with a notified body or the Commission guidance before you commit to a timeline.
What usually delays due diligence or makes it expensive
Most delays in CRA component due diligence come from gaps in records rather than from difficult technical work. The risks below share a root cause: the manufacturer cannot show, quickly and in writing, what each third-party or open-source component is, why it was accepted and who will fix it.
No current SBOM
Without a current software bill of materials, a team cannot check its components against vulnerability databases, review their support periods or answer a question about whether a given library is present. Teams often discover this when a vulnerability is announced and they must search manually across repositories and builds. Ask who generates the SBOM, when it is regenerated (at every release, at minimum) and whether it covers transitive dependencies and container base images. Confirm the format your tooling produces before you rely on it.
Undocumented decisions
Due diligence is only useful if the reasoning behind each accepted component is written down. When a component is adopted without a record of what the product needs from it, such as cryptographic functions, update mechanisms or secure communications, the team must reconstruct that reasoning during an assessment, which is slow and expensive. Keep a short decision record per component that names the function it serves, the evidence reviewed, the date and the approver. Store these records with the technical documentation so they travel with each release.
Treating a passing scan as due diligence
A clean software composition analysis report shows only that known vulnerabilities in the database were not matched. It does not confirm the component's update history, support period, the manufacturer's security posture or whether the component fits the product's risk profile. Teams that stop at the scan often reopen the work later. Pair scanning with a review of the component's documentation, its CE marking or assurance evidence where one exists, and a documented judgment on its maintenance status.
Unclear maintainer ownership
Article 13(6) requires a manufacturer that finds a vulnerability in an integrated open-source component to report it to the maintainer and share any fix it develops. If nobody can name the maintainer, the project's security contact or the reporting channel, that duty cannot be met on time. Projects with a single volunteer maintainer, abandoned repositories or forks with unclear stewardship carry the most risk. Record the maintainer, the security contact and the disclosure channel for each component before the release that depends on it.
Late discovery of critical components
A component that is later found to be highly critical to the product's security, such as a parser handling untrusted input or a component that runs with elevated privileges, may need isolation or sandboxing. Changing that design after release is costly because it affects architecture, testing and the support plan. Classify components by criticality during design, not after integration, and note which ones the Commission's FAQ actions such as sandboxing would apply to. Confirm the classification with the people who own the architecture.
How DeployOpen prepares component due diligence evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the components you integrate can be inventoried, verified and recorded as due diligence evidence. We prepare the systems and records; your organization owns the decisions, and an independent assessor reaches any conformity conclusion.
How we scope
- Agree a written, fixed scope listing the products, components and integrations covered by the due diligence work.
- Confirm with you which component functions matter for security, such as cryptography, update mechanisms and secure communications.
- Define the deliverables, timelines and responsibilities in writing before any work begins, with ongoing support available as a retainer.
How we build
- Run software composition analysis and review each component's SBOM against the versions actually deployed in your environment.
- Check public vulnerability databases and each component's security update history and support period, recording the results.
- Where a component is highly critical, configure sandboxing or isolation and test those boundaries before go-live.
How we hand over
- Deliver a due diligence register per component with sources checked, findings, dates of review and the decisions taken.
- Document upstream vulnerability reports and any fixes you develop, with records of the maintainer notification.
- Provide runbooks and configuration records so your team and any independent assessor can reproduce the checks.
How we support
- Refresh the component register when versions change, new advisories appear or a component reaches end of support.
- Retest integrated components and sandbox boundaries on a schedule your team agrees in the scope.
- Confirm with your legal and compliance leads which evidence an independent assessor will need for your conformity route.
