Skip to main content

CRA Adoption Best Practices

CRA Adoption Best Practices

Practical, risk-based guidance for SMEs and open source communities to adopt and integrate Free and Open Source Software (FOSS) in line with the EU Cyber Resilience Act (CRA).

Explore the best practices

These pages translate the CRA’s risk-based mandate into actionable best practices for the open source community, and offer SMEs a clear path to secure and compliant FOSS integration. They focus on integrating security across the lifecycle, ensuring governance and transparency, and building supply chain resilience.

Ready-to-use checklists and templates

Lightweight tools from the SME Practical Implementation Toolkit, ready to tick online, print or download into your own tracker.

Risk is contextual, not inherent

Under the CRA, cybersecurity obligations are not uniform or prescriptive. Manufacturers must implement “appropriate and proportionate” security measures based on identified risks, rather than striving for absolute security. Obligations are scaled based on:

  • The intended purpose of the product
  • The foreseeable use and misuse
  • The severity and likelihood of potential impacts
  • The role of the software component within the product

For FOSS components, this means that the same open source library might pose a low risk in one scenario and a high risk in another, entirely dependent on how and where it is deployed. A risk-based approach looks beyond the fact that a component is open source and assesses:

Functional criticality

Does the component handle vital functions like authentication, cryptography, update mechanisms, or network exposure?

Attack surface

Is the component exposed to untrusted inputs or external interfaces?

Dependency depth and transitivity

How many indirect dependencies are introduced, and how well are they understood?

Maintenance and responsiveness

Is the project actively maintained? Are security issues promptly acknowledged and addressed?

Integration context

How is the component configured, hardened, and isolated within the final product?

These factors, and not the development model itself, are what determine the required level of due diligence and security controls.

Grounded in SME evidence

The guidance is informed by anonymised, aggregated results from voluntary assessments on the OCCTET CRA Self-Assessment Platform. No company-level or personal data is included.

Registered companies
48
Countries represented
22
Organisations declaring they are subject to the CRA
20
Average maturity score across domains
1.66/ 3
Average maturity score per domain Scale from 0 (not in place) to 3 (fully in place). Technical controls are more mature than governance, documentation and lifecycle processes.
  • Confidentiality 2.16
  • Resilience 2.06
  • Network security 1.90
  • Protection from unauthorised access 1.76
  • Integrity 1.65
  • Vulnerability management & disclosure 1.63
  • Secure software development lifecycle 1.54
  • Release requirements 1.48
  • Logging & detection 1.34
  • Risk management & governance 1.11

Recurring structural gaps

  • Limited documented risk management framework
  • No clearly assigned ownership for dependency updates
  • Absence of formalised release documentation discipline
  • Incomplete SBOM or dependency visibility
  • Reactive rather than lifecycle-oriented vulnerability management

The challenge is not introducing complexity, but introducing clarity.

What this means for CRA-aligned adoption

  • SMEs benefit most from proportional, structured, and lightweight guidance.
  • Governance and lifecycle clarity are more critical gaps than pure technical controls.
  • Documentation, traceability, and repeatability are key enablers of CRA alignment.
  • Simple ownership assignment and visibility mechanisms can significantly improve maturity.

How mature is your organisation?

Measure your own preparedness in minutes with the free and confidential CRA self-assessment.

Start the self-assessment

Back to the top