CRA Compliance Checklist: Open Source Hardware
In scope when placed on the EU market commercially — explicitly excluded for non-commercial hobby and research use; steward model applies to community OSH projects not placing products on the market
Open source hardware (OSH) projects occupy a unique position under the CRA. The regulation explicitly excludes hardware developed for non-commercial purposes, shared freely without monetisation. However, when open source hardware designs are manufactured and sold commercially — even by small businesses or community projects — the CRA's full scope applies. The CRA also introduces a 'steward' concept for open source projects that is relevant to OSH ecosystems. Understanding the commercial/non-commercial boundary is essential.
1. Scope & Classification
Determine whether your OSH project 'places products on the market' — if you sell hardware commercially, even as a small business, CRA applies
Selling assembled OSH hardware, DIY kits, or pre-programmed boards for commercial gain constitutes placing products on the market. CRA applies regardless of whether the design files are open-source. Non-commercial sharing of design files alone does not trigger CRA.
Assess the CRA 'open source software steward' provisions — if your OSH project provides software that others commercialise, steward obligations may apply
CRA Article 17 introduces lighter-weight obligations for open source software 'stewards' — entities that provide software on a non-commercial basis that is then used in commercial products. Stewards must publish a CVD policy and cooperate with manufacturers. Assess whether your project is a steward.
Assess CRA classification for commercially sold OSH products based on the product's function and deployment — Default for general hardware, Class I or II for safety-critical functions
An OSH product is classified the same as any equivalent commercial product. A commercially sold OSH industrial controller is Class I; an OSH smart home hub is Default. The open-source nature does not affect classification.
Compile SBOM for commercially sold OSH products covering all firmware components, libraries, and dependencies
OSH projects often use many open-source software components. Use automated SBOM tools (Syft, CycloneDX tools, SPDX generators) to compile complete SBOMs including all transitive dependencies.
2. Product Security (Annex I Part I)
For commercially sold OSH products, apply all Annex I Part I security requirements — open source design does not reduce security obligations
Commercial OSH products must meet the same security requirements as proprietary equivalents: no insecure defaults, encrypted communications, signed updates, minimal attack surface, and protection against common vulnerability classes.
Implement secure defaults in firmware for commercially sold OSH devices — disable debug interfaces, require setup credentials, enable secure boot where hardware supports it
Many OSH projects ship with development-friendly insecure defaults (serial console enabled, default credentials, debug interfaces). Commercial products must have production-safe defaults, not developer-friendly defaults.
Implement cryptographically signed OTA updates for commercially deployed OSH devices
Platforms like Arduino, ESP32, and Raspberry Pi support various OTA update frameworks. Implement signed OTA using a framework appropriate to your hardware platform.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy — for commercial OSH products, this is mandatory under CRA Article 13; for OSH stewards, Article 17 requires a CVD policy
Both commercial OSH manufacturers and OSH stewards must have a CVD policy. Use the CVD Portal to create a CRA-compliant policy. Host it on your project website and at /.well-known/security.txt.
For OSH projects with a community of downstream manufacturers, establish a vulnerability notification process to alert commercial users of your design
As an OSH steward, you should notify commercial manufacturers using your design when significant vulnerabilities are discovered in the shared firmware or design. This supports the ecosystem's collective CRA compliance.
Define security support commitments for commercially sold OSH products — even small businesses must meet CRA support obligations
There is no SME exemption from the CRA security support obligation. Define and publish a realistic support period for your commercially sold products.
4. Article 14 Incident Reporting
For commercial OSH manufacturers, apply Article 14 reporting obligations — the open-source nature does not change these obligations
If you commercially sell OSH products and an actively exploited vulnerability is discovered, Article 14 notification obligations apply. Small businesses should prepare simple but effective reporting procedures.
Prepare a simplified Article 14 notification process appropriate to your organisation's size — use the CVD Portal Article 14 timeline tool
Small commercial OSH manufacturers can use the CVD Portal's Article 14 timeline tool to understand and plan their notification obligations without requiring a large security team.
5. CE Marking & Technical Documentation
For commercially sold OSH products, prepare CRA technical file — open source design files can be referenced in the technical file
The open-source design files, hardware schematics, and firmware source code can form part of the CRA technical file. Include security analysis, SBOM, CVD policy, and risk assessment documentation.
Issue EU Declaration of Conformity and affix CE marking for commercially sold OSH products before EU market placement
Commercial OSH products require a DoC referencing the CRA. The open-source nature of the design does not exempt commercial sales from CE marking requirements.
Track your Open Source Hardware compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
I designed an open source PCB and share the design files on GitHub — does CRA apply to me?+
If you share design files freely and do not sell the hardware commercially, you are not placing products on the market and the CRA does not apply to you as a manufacturer. However, if anyone manufactures and sells the design commercially, they become the manufacturer for CRA purposes. If your project includes firmware and you consider yourself the project steward (providing ongoing development and CVD coordination), CRA Article 17 steward provisions may apply — lighter-weight obligations than full manufacturer responsibilities.
We run a crowdfunded OSH project and sell hardware to backers — are we in scope?+
Yes. Selling hardware to backers via crowdfunding is commercial market placement and triggers full CRA obligations. The commercial/non-commercial boundary is about revenue, not the funding mechanism. Crowdfunding campaigns that result in hardware being distributed to backers for payment constitute placing products on the market. All Annex I requirements, CVD policy, SBOM, and DoC obligations apply.
We are a small maker business with fewer than 10 employees selling OSH kits — does the CRA apply to very small businesses?+
Yes, but with some proportionality. The CRA applies to all commercial manufacturers regardless of size. However, CRA Recital 18 and Article 13(9) acknowledge that obligations should be applied proportionately for micro and small enterprises. The substantive requirements (Annex I security, CVD policy, SBOM, DoC) still apply. What may be proportionate is the depth of documentation and the complexity of processes for very small businesses. Consult your national market surveillance authority for guidance on proportionate compliance for micro-enterprises.
Need a CVD policy for Open Source Hardware?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.