EN 
FR 
DE 
IT
Free diagnostic · No obligation
Are you ready for the
Cyber Resilience Act?
4 steps, 5 minutes. Check your obligations, measure your maturity, get an action plan.
⏱ ~5 min
📋 4 steps
🔒 Local data
🇪🇺 EU Reg. 2024/2847
✅ 100% free
01
Step 1 of 4
Your market role
What is your role for this product? Art. 3 §13-15
The CRA distinguishes 3 roles with different obligations. Choose the role that matches this specific product. The same company can have multiple roles across its product lines.
Tip: if you have the product designed and sell it under your brand, you are a Manufacturer, even without a factory.
Tip: if you have the product designed and sell it under your brand, you are a Manufacturer, even without a factory.
⚠️ Please select your role to continue.
1 / 4
02
Step 2 of 4
Product scope
Can the product connect to a network or device? Art. 3 §1
A "Product with Digital Elements" (PDE) is any software or hardware capable of connecting, even occasionally, via Wi-Fi, Bluetooth, Ethernet, USB, cloud API, etc.
YES: smartwatch, IP camera, mobile app with backend, IoT sensor, SaaS API
NO: static PDF document, fully offline software with no network interface
YES: smartwatch, IP camera, mobile app with backend, IoT sensor, SaaS API
NO: static PDF document, fully offline software with no network interface
Does the product fall under sectoral regulation? Art. 2 §2
Certain sectors are fully or partially excluded from the CRA in favour of sector-specific rules.
Examples: MDR / IVDR (medical) · EASA (aviation) · Vehicle type-approval · Defence equipment
Examples: MDR / IVDR (medical) · EASA (aviation) · Vehicle type-approval · Defence equipment
What is the risk class of the product? Art. 7 & Ann. III-IV
The class determines the certification level. If unsure, choose "Default class".
Class I: residential gateways, web browsers, antivirus, password managers, VPNs, wearables
Class II: industrial OS, secure microprocessors, smart cards, TPMs, critical industrial routers
Default: all others — smart TVs, connected toys, consumer applications…
Class I: residential gateways, web browsers, antivirus, password managers, VPNs, wearables
Class II: industrial OS, secure microprocessors, smart cards, TPMs, critical industrial routers
Default: all others — smart TVs, connected toys, consumer applications…
⚠️ Please answer all questions above.
2 / 4
03
Step 3 of 4
Life cycle & support
Is the software non-commercial open source? Art. 3 §14a
Open source software developed entirely outside any commercial activity (volunteer contributions, hobby projects) is excluded from the CRA.
Caution: paid support, SaaS, or a component embedded in a sold product means the CRA applies.
Caution: paid support, SaaS, or a component embedded in a sold product means the CRA applies.
Planned support duration Art. 13 §8
The CRA requires a defined and published support duration. 5 years minimum is the recommendation for manufacturers. It must be communicated to users before purchase.
1 year
10+ years
3 years
Duration under 5 years — justification required.
How are updates deployed? Art. 13 §3
The CRA requires that security patches are offered automatically by default, unless the user explicitly opts out.
⚠️ Please answer all questions.
3 / 4
04
Step 4 of 4 — Last step!
Your security maturity
Honestly evaluate your current level on each of the 10 key CRA requirements.
Legend:
✅ Done
⚠️ Partial
❌ Not done
— N/A
⚠️ Please evaluate all requirements.
4 / 4
✓
Diagnostic result
Product out of CRA scope
Not connected — CRA not applicable
Your product has no digital connectivity and does not fall within the scope of the Cyber Resilience Act (Art. 2 §1 & Art. 3 §1).
Monitor over time
If the product gains connectivity later (software update, Bluetooth module, cloud API…), it enters the CRA scope and compliance work must begin.
Talk to our experts →
ℹ
Diagnostic result
Total sectoral exclusion
Full sectoral coverage — CRA not applicable
Your product is fully covered by a specific EU sectoral regulation (MDR, EASA, vehicle type-approval…) — total exclusion from the CRA (Art. 2 §2).
Exclusion does not mean no obligations
The applicable sectoral regulation may impose equivalent or stricter cybersecurity requirements. A sector-specific analysis remains essential.
Sectoral analysis by our experts →
✓
Diagnostic result
Non-commercial Open Source
Non-commercial OSS — outside CRA scope
Open source software developed entirely outside any commercial activity is excluded from the Cyber Resilience Act scope (Art. 3 §14a).
The commercial boundary is often blurry
Paid support, SaaS, or a component embedded in a sold product — as soon as any commercial activity is linked to the software, the qualification changes and the CRA may apply. We can help clarify your situation.
Clarify your situation →