Skip to main content

OCCTET · Open Source Compliance Toolkit

Your CRA journey

A map of OCCTET results for SMEs and open source projects, from the first question about the Cyber Resilience Act to compliance that lasts.

CRA milestones

  1. Entry into force
  2. Rules for conformity assessment bodies apply
  3. Reporting of exploited vulnerabilities and incidents
  4. All obligations apply

Types of resources

  • OCCTET deliverable
  • Tool
  • Guide
  • Checklist or template
  • Webinar recording
  • FAQ and references
  • Event
  • Community
  • From the ORC working group

Not sure where to start with the CRA?

Find your role

Your obligations depend on what you do with open source. Pick the profile that fits you best.

Manufacturer

SME building products with open source

Pain point: Due diligence on every open source component you ship, with a small team and no compliance department.

You place the product on the EU market, so its CRA obligations, including the open source inside, are yours.

Follow the journey

Upstream developer

Open source project or maintainer

Pain point: Security questionnaires from every downstream user, and uncertainty about what the CRA expects from you.

The CRA does not regulate open source development as such, but your practices shape how downstream users manage risk.

Questions along the way?

Ask the community CRA FAQ

The Open Regulatory Compliance (ORC) working group, hosted by the Eclipse Foundation, maintains a CRA FAQ organised by audience and topic. It also gathers the European Commission's official FAQs and guidance, and ENISA's answers on vulnerability reporting.

The SME journey to CRA readiness

Six steps that scale with the criticality of your product and the resources you have. Each one points to the OCCTET results that help.

  1. Does the CRA apply to my product, and what does it require?

    Pain point: Regulatory fog. Roles, obligations and deadlines are hard to read, and there is no compliance team to decode them.

  2. Where do we stand today, and which gaps matter most?

    Pain point: No baseline. Security work exists but is rarely structured or documented.

  3. Which open source components are inside our product?

    Pain point: Invisible dependencies. Incomplete SBOMs and unknown transitive components.

  4. Which components deserve closer scrutiny?

    Pain point: Uniform checks waste effort, while critical, internet-facing components get too little attention.

  5. How do we handle vulnerabilities and show our work?

    Pain point: Patches are applied, but decisions and evidence are not recorded for the technical documentation.

  6. How do we stay compliant over the whole product lifetime?

    Pain point: One-off efforts decay. Vulnerabilities surface years after release and maintainers move on.

  7. CRA-ready, and staying ready

    Compliance is continuous. Reassess when your product, its exposure or its dependencies change.

Shared support areas

Webinar library

Watch the recordings of OCCTET webinars and CRA Mondays talks, from the CRA basics to SBOMs and the toolkit.

Back to the top