Risk, Evidence & Conformity: The Cyber Resilience Act for Default Products

The Interview

I sat down with Daniel Thompson-Yvetot to break down one of the most consequential pieces of EU legislation for the software industry: the Cyber Resilience Act (CRA) — specifically how it applies to default products (the vast majority of digital products on the market).

Daniel is a recognized expert in open source governance and regulatory compliance, and his insights cut through the legal jargon to reveal what engineering teams and product owners actually need to do.

What Are “Default Products” Under the CRA?

The CRA classifies digital products into three tiers:

1. Default products — the vast majority (~90% of all digital products)
2. Important products (Class I and II) — higher-risk categories
3. Critical products — essential infrastructure

Default products face the lightest compliance burden, but “lightest” doesn’t mean “none.” Every product with digital elements sold in the EU must meet baseline cybersecurity requirements.

The Three Pillars for Default Products

1. Risk Assessment

Every manufacturer must conduct a cybersecurity risk assessment before placing a product on the market. This isn’t a checkbox exercise — it requires:

• Identifying potential threats and vulnerabilities
• Assessing the severity and likelihood of exploitation
• Documenting residual risks that cannot be eliminated
• Updating the assessment throughout the product lifecycle

“You can’t just do this once at launch and forget it. The CRA explicitly requires ongoing risk management — when you ship an update, when a new vulnerability class emerges, when the threat landscape shifts.” — Daniel Thompson-Yvetot

2. Technical Documentation

Default products require comprehensive technical documentation including:

• Product architecture and design decisions relevant to security
• SBOM (Software Bill of Materials) — at minimum the top-level dependencies
• Vulnerability handling process — how you receive, triage, and fix reports
• Security update mechanism — how patches reach end users
• Conformity assessment records — evidence that requirements are met

This documentation must be maintained for 10 years after the last unit is placed on the market (or 5 years for support period, whichever is longer).

3. Self-Assessment Conformity

Here’s the good news for default products: you can self-assess. Unlike Important Class II or Critical products, you don’t need a third-party notified body to certify compliance.

The self-assessment process (based on Module A of EU Decision 768/2008):

1. Conduct the risk assessment
2. Implement essential cybersecurity requirements (Annex I)
3. Prepare technical documentation
4. Draft an EU Declaration of Conformity
5. Affix the CE marking

Key Deadlines

What This Means for Open Source

Daniel highlighted the critical distinction the CRA makes:

• Open source stewards (foundations, maintainers) are NOT manufacturers
• But companies that take open source and commercialize it ARE manufacturers
• If you sell a product containing open source components, YOU are responsible for CRA compliance of those components

“The liability follows the money. If you’re monetizing software in the EU market, you own the compliance obligation — regardless of whether you wrote every line of code.” — Daniel Thompson-Yvetot

Practical Steps to Start Today

1. Inventory your products — which ones have digital elements sold in the EU?
2. Classify correctly — most will be “default” (check Annex III and IV for exceptions)
3. Generate SBOMs — automate this in your CI/CD pipeline now
4. Establish a vulnerability disclosure process — coordinated disclosure with 24-hour early warning to ENISA
5. Document everything — start the technical file today, not in 2027

Related Reading

• EU Cyber Resilience Act: What CTOs Need to Know
• CRA Impact on Open Source Supply Chains
• SBOM Generation with Syft and Grype

This interview was recorded at a recent industry event. Follow Daniel Thompson-Yvetot for more CRA insights, and subscribe to my channel for weekly interviews on AI infrastructure, security, and cloud native topics.