Skip to main content

CRA Adoption Best Practices

SME CRA Compliance Guidelines

A practical, proportionate path for SMEs integrating FOSS components: who should focus on what, how to assess risk, which level of due diligence to apply and how to keep it up over time.

On this page

SME personas: what to focus on

SMEs approach CRA adoption from different roles and levels of technical maturity. The following personas illustrate common responsibilities and what each role should prioritise when using and integrating FOSS components.

Persona A

Non-technical manager

CEO / COO / Operations manager

Focus: Making sure the business can demonstrate a reasonable, repeatable compliance approach without needing deep technical detail.

  • Ensure roles are assigned (who owns updates, who monitors vulnerabilities, who approves dependencies).
  • Ensure basic evidence exists (SBOM availability, security contact, update policy, vulnerability reporting channel).
  • Approve time and budget for “minimum viable compliance” activities.
  • Require simple documentation: what we use, why we use it, how we keep it updated.

Persona B

Technical lead

CTO / Lead developer / DevOps lead

Focus: Implementing practical controls that reduce risk and can be maintained over time.

  • Integrate security into the lifecycle (review, testing, secure releases, updates).
  • Establish dependency visibility (SBOM, dependency scanning, tracking transitive dependencies).
  • Implement vulnerability handling (intake, triage, patching process, release notes).
  • Ensure traceability (versioning discipline, changelog, protected branches, access controls).

Persona C

Product owner / compliance coordinator

Product manager / QA / Security champion

Focus: Connecting product decisions, customer expectations, and compliance evidence.

  • Clarify product scope and intended use (where FOSS is used, where exposure exists).
  • Apply a risk-based view: which components are critical vs low-risk.
  • Maintain lightweight evidence packs (risk decisions, component register, update history).
  • Coordinate across teams so monitoring and updates don’t fall between roles.

These personas are not mutually exclusive. In many SMEs, one person may cover multiple roles. The key is ensuring that ownership and accountability are explicitly assigned.

From ad-hoc consumption to structured governance

The CRA signals a broader transformation: compliance is no longer limited to internal product design. It extends across the software supply chain. For SMEs, this implies a shift from ad-hoc open source consumption to structured, risk-based ecosystem governance.

Ad-hoc consumption

Fragmented & manual

Structured governance

Risk-based & scalable

Open source stewards become key actors in this governance architecture, and the consumption of non-stewarded components will be subject to intense scrutiny to properly gauge the associated risks. Rather than individually auditing every upstream project, SMEs can:

  • Leverage steward-aligned processes
  • Rely on structured security frameworks
  • Document engagement as part of due diligence
  • Demonstrate proportionate, risk-based management

This approach aligns with the CRA’s intent: improving cybersecurity without imposing a disproportionate burden.

Due diligence for open source components

Integrating FOSS components into products with digital elements introduces shared responsibility across the software supply chain. Under the CRA’s risk-based framework, manufacturers, including SMEs, are expected to apply appropriate and proportionate due diligence when selecting, integrating, and maintaining third-party software components.

Due diligence is not intended to discourage the use of open source software. On the contrary, FOSS remains a foundational enabler of innovation and competitiveness. However, it must be integrated responsibly. Due diligence ensures that:

You understand what you are integrating

You know the level of risk it introduces

You can justify your integration decision

You are able to monitor and maintain it over time

Due diligence is not a one-time check before release. It is a lifecycle-oriented activity that continues throughout the product’s expected lifetime, in line with the CRA’s requirements for secure development and vulnerability management.

Risk-based assessment of FOSS components

Before integrating a FOSS component, SMEs should assess three key dimensions. The questions are designed to be understandable for both technical and non-technical decision-makers.

Functional criticality

Ask:

  • Does this component handle authentication, encryption, access control, or updates?
  • Is it central to the product’s core functionality?
  • If this component fails, would our product stop working?
  • Could it compromise data confidentiality, integrity, or availability?

The more critical the function, the more careful the evaluation should be. A logging library is not the same as an authentication module.

Exposure level

Ask:

  • Is this component accessible from the internet?
  • Does it process input from external users?
  • Is it exposed through APIs?
  • Or is it fully internal and isolated?

Higher exposure increases the attack surface. An internal utility component may require lighter review than a publicly exposed service component.

Impact of failure

Ask:

  • Could exploitation lead to personal data breaches?
  • Would service disruption impact customers?
  • Would this trigger regulatory notification obligations?
  • Could it damage our reputation?

Impact determines how much effort is justified in risk management.

These factors work together

  • A moderately critical component that is publicly exposed may require enhanced controls.
  • A highly critical component used only internally may justify structured but proportionate review.

The goal is proportionality, not uniform control.

Proportional due diligence levels

Consistent with the CRA’s proportionality principle, due diligence practices may be structured across increasing levels of maturity.

Level 1

Foundational due diligence

Appropriate for components with low criticality and limited exposure.

Measures include:

  • Verification of project activity and recent maintenance
  • Review of publicly disclosed vulnerabilities
  • License compatibility verification
  • Inclusion of the component in the Software Bill of Materials (SBOM)

The objective is transparency and traceability. For many SMEs, this is a realistic and achievable baseline aligned with proportional compliance expectations.

Level 2

Structured due diligence

Appropriate for components with moderate criticality or exposure.

Additional measures may include:

  • Review of governance transparency and maintainer structure
  • Assessment of vulnerability reporting and response practices
  • Evaluation of release discipline and versioning clarity
  • Automated dependency scanning tools

Structured due diligence introduces predictability. It reduces reliance on ad-hoc decisions and supports documented internal risk assessments.

Level 3

Enhanced due diligence

Appropriate for highly critical or publicly exposed components.

Enhanced measures may include:

  • Continuous vulnerability monitoring
  • Review of coordinated disclosure practices
  • Evaluation of long-term maintenance commitment
  • Consideration of voluntary security attestations under Article 25
  • Engagement with maintainers where appropriate

Particularly relevant for components that:

  • Handle sensitive data
  • Are publicly exposed
  • Support essential product functionality
  • Operate in regulated or high-impact environments

Enhanced due diligence strengthens resilience across the broader software supply chain.

Not sure which level applies? The decision matrix combines criticality and exposure to recommend one. Templates supporting levels 1 to 3 are available in the checklists and templates.

Use the decision matrix

Ongoing monitoring and lifecycle responsibility

Due diligence does not end at the moment of integration. Vulnerabilities may be discovered years later. Maintainers may change. Releases may slow down. Lifecycle responsibility requires continuous awareness of evolving vulnerabilities and project maintenance status.

SMEs should

  • Monitor vulnerability disclosures affecting included dependencies
  • Track new releases and security updates
  • Maintain updated SBOM records
  • Reassess risk when exposure or architecture changes

Reassess especially when

  • New product features are introduced
  • Public exposure increases
  • Regulatory requirements change
  • Upstream maintenance activity declines

This continuous approach aligns directly with the CRA’s lifecycle security obligations.

Consuming security attestations

Where available, voluntary security attestations under Article 25 may support structured due diligence. Attestations can:

  • Provide standardised and comparable information on governance and security practices
  • Reduce repetitive compliance requests directed at maintainers
  • Facilitate integration into internal risk assessment processes

Integrator responsibility remains

Reliance on attestations does not eliminate integrator responsibility. SMEs must evaluate the relevance of attested information in relation to their own integration context, exposure level, and product architecture. Attestations enhance transparency but do not replace contextual risk assessment.

Common pitfalls and red flags

Common pitfalls in FOSS integration

SMEs frequently encounter recurring challenges:

  • Assuming that widespread adoption automatically implies security
  • Failing to identify indirect (transitive) dependencies
  • Conducting one-time validation without ongoing monitoring
  • Relying on upstream patching without tracking update adoption
  • Integrating components without documenting selection rationale

Recognising these patterns enables SMEs to shift from reactive integration toward structured risk management.

Red flags to watch for

Indicators that may suggest elevated risk:

  • No visible security reporting channel
  • Long periods without updates or maintenance
  • Unresolved critical vulnerabilities without communication
  • Inconsistent versioning or release documentation
  • Lack of clarity regarding maintainer responsibility
  • Large dependency trees with limited transparency

A red flag does not automatically disqualify a component. However, multiple indicators may justify enhanced due diligence or reconsideration of the integration strategy.

Quick due diligence checklist

Twelve simple questions on basic visibility, vulnerability awareness, supply chain transparency, and lifecycle considerations. An accessible, proportionate entry point for SMEs with limited resources.

Open the checklist

The SME path to CRA-aligned FOSS adoption

The CRA is risk-based and lifecycle-oriented. SMEs can adopt a practical approach by following a simple path that scales with product criticality and resources.

  1. Start Set ownership and baseline visibility

    • Assign responsibility for: dependency selection, security updates, vulnerability monitoring, and documentation.
    • Create a minimal inventory of key FOSS components used in the product.

  2. Identify scope Where FOSS matters in your product

    • Identify which parts of the product are internet-facing, handle data, or are security-sensitive.
    • Clarify which components are critical to product functionality.

  3. Assess risk Use proportional thinking

    • Evaluate each component using: criticality, exposure, and impact.
    • Decide what level of due diligence is reasonable (foundational / structured / enhanced).

  4. Apply proportional controls Do what is appropriate

    • For low-risk components: basic checks + SBOM + monitoring.
    • For higher-risk components: structured governance checks, stronger release discipline, more monitoring.

  5. Monitor Make it continuous, not one-time

    • Track vulnerabilities and upstream updates.
    • Keep the SBOM updated for each release (or at least major releases).
    • Ensure updates are adopted in a timely way.

  6. Reassess When things change

    • The product becomes more exposed (new integrations, internet exposure).
    • Critical functionality changes.
    • Upstream maintenance declines.
    • New vulnerabilities appear that affect core dependencies.

This path is designed to help SMEs demonstrate a structured and defensible approach, even with limited resources.

Decision matrix for FOSS component due diligence

To support consistent and proportionate decision-making, the matrix combines two dimensions, functional criticality and exposure level, and recommends the due diligence level (L1 / L2 / L3) defined above.

Functional criticality Exposure level InternalIsolated useLimitedControlled accessPublicInternet-facing
LowL1 FoundationalL1 FoundationalL2 Structured
MediumL1 FoundationalL2 StructuredL3 Enhanced
HighL2 StructuredL3 EnhancedL3 Enhanced

How to use this matrix

  1. Determine the functional criticality of the component:
    • Does it support core functionality?
    • Does it handle authentication, encryption, or updates?
    • Would failure significantly impact the product?
  2. Determine the exposure level:
    • Is it internal only?
    • Is it accessible through authenticated APIs?
    • Is it publicly exposed?
  3. Locate the intersection in the matrix to identify the recommended due diligence level.

Important considerations

  • This matrix provides guidance, not rigid classification.
  • If the impact of failure is exceptionally high (e.g., safety, regulated environment), SMEs may choose to apply a higher due diligence level.
  • The matrix supports proportionality, avoiding both over-engineering and under-assessment.

Back to the top