The CRA makes cybersecurity a condition of the CE mark. Rizzqo builds the proof into how you ship.
The Cyber Resilience Act holds every product with digital elements to essential requirements — secure by design, no known exploitable vulnerabilities, and vulnerability handling across a defined support period. Rizzqo turns those requirements into conformity you can prove, kept ready as you build — not reconstructed before assessment.
Products with digital elements
The CRA applies to products with digital elements — any hardware or software placed on the EU market whose intended use includes a data connection. Conformity effort scales with risk: most products self-assess, while important and critical products face third-party assessment. Select a class to see what it means for you.
Important & critical products
Third-party assessment or certification
Products whose core function is security-relevant — listed in Annex III (important, Class I and II) and Annex IV (critical). The higher the class, the more independent the conformity assessment.
- Password managers, VPNs, firewalls, network and identity management
- Class II and critical products need a notified body or certification
- Smart meter gateways, hardware security modules and smartcards are critical
- Held to the same essential requirements, verified with more assurance
Default products
Manufacturer self-assessment
The large majority of products with digital elements. The manufacturer assesses conformity itself, draws up the technical documentation and affixes the CE marking.
- Most connected consumer and business products and software
- Self-assessment against the Annex I essential requirements
- Technical documentation, SBOM and an EU declaration of conformity
- CE marking once the essential requirements are met and evidenced
Products covered
The CRA reads more clearly in two buckets. Default products self-assess against the essential requirements; important and critical products meet the same bar but with independent conformity assessment or certification. Products already governed by sectoral rules — medical devices, cars, aviation — are carved out.
Default products
The majority — self-assessed against the essential requirements.
Important & critical products
Security-relevant products with independent assessment or certification.
What secure by design has to mean
Annex I sets essential requirements: product security properties in Part I and vulnerability handling in Part II. Every product must be delivered and maintained against them. With Rizzqo, conformity to each is something you can evidence, not assert.
Secure by design & default
Products are designed, developed and delivered with an appropriate level of cybersecurity and a secure-by-default configuration.
No known exploitable flaws
Products are placed on the market without known exploitable vulnerabilities, with a secure state to fall back on.
Confidentiality & encryption
Protect the confidentiality of stored, transmitted and processed data, using state-of-the-art encryption where relevant.
Integrity protection
Protect the integrity of stored, transmitted and processed data, commands, configuration and the product’s own code.
Data minimisation
Process only the data that is adequate, relevant and limited to what the product’s intended use requires.
Availability & resilience
Protect availability of essential functions and resilience against denial-of-service, including for connected devices.
Minimised attack surface
Limit attack surfaces, including external interfaces, and design in mitigations to reduce the impact of an incident.
Security logging
Record and monitor relevant internal activity, including access to and modification of data and functions.
Secure updates
Provide security updates, where possible automatically, that can be installed promptly across the support period.
Vulnerability handling
Maintain an SBOM, a coordinated disclosure policy and timely, free security updates throughout the support period.
An actively exploited flaw starts a 24-hour clock to ENISA
For an actively exploited vulnerability or a severe incident, the CRA sets a staged notification to the coordinating CSIRT and ENISA. Rizzqo keeps you ready to hit every stage on time, with the affected products and evidence already to hand.
Detect & confirm
Become aware of an actively exploited vulnerability in the product, or a severe incident affecting its security, and confirm the impact.
Early warning
Within 24 hours of becoming aware, an early warning to the coordinating CSIRT and ENISA via the single reporting platform.
Vulnerability notification
Within 72 hours, a fuller notification with the nature of the flaw, its severity and any corrective or mitigating measures taken.
Final report
Once a corrective measure is available, and no later than 14 days after, a final report describing the vulnerability and the fix.
On the products and components you ship
The essential requirements belong on the product, not in a binder. Rizzqo keeps each one owned, tracked and evidenced as engineering happens — so the conformity file builds itself as you build.
Requirements linked to real products
The CRA lands on the products and components you actually ship — not a generic checklist — so your scope reflects your real product, not a paper exercise.
- Grounded in your real products
- A scope you can defend, not a checklist
- Risk priced in real money, not a heat-map colour
Clear ownership, evidence for the file
Every requirement has a clear owner and evidence that accrues as teams build — so the technical documentation stays conformity-ready instead of being reconstructed the week before assessment.
- Clear ownership, nothing unassigned
- Evidence that stays current, not stale
- Technical documentation and SBOM ready for assessment
A reporting workflow against the clock
When a vulnerability is actively exploited, the Article 14 clock starts. Rizzqo keeps the 24-hour, 72-hour and 14-day stages and the affected products in view — so each report is assembled from what you already have, not improvised under pressure.
- 24h, 72h and 14-day deadlines never missed
- Affected products in view from the start
- Every stage assembled, not improvised
The secure-development work you already do, counted
Secure development, access control, encryption, vulnerability management — the CRA leans on practices an ISO 27001 ISMS already asks of you. Rizzqo counts that work toward the CRA on the same assets, so only the genuinely product-specific duties remain: secure-by-default delivery, an SBOM, support-period updates and CE conformity.
Ship it CRA-conformant, with the proof built in.
Turn the Annex I essential requirements into conformity you can prove on your real products — and be ready for the Article 14 clock before it starts.
CRA questions, answered
The CRA applies to products with digital elements — hardware and software placed on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection. That covers most connected devices and software, from consumer IoT to business applications and operating systems. Products already covered by sectoral rules — medical devices, in-vitro diagnostics, motor vehicles, civil aviation and marine equipment — are carved out, as is non-commercial open-source software. Rizzqo helps you map your products to the regulation so scope is settled by evidence, not guesswork.
All products meet the same Annex I essential requirements; the difference is how conformity is checked. Default products — the large majority — are self-assessed by the manufacturer. Important products in Annex III (Class I and II) involve harmonised standards or a notified body, and critical products in Annex IV can require European cybersecurity certification. Rizzqo tracks the requirements the same way for every class and simply raises the evidence bar where independent assessment applies.
For an actively exploited vulnerability or a severe incident affecting a product’s security, Article 14 sets a staged notification to the coordinating CSIRT and ENISA through a single reporting platform: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report once a corrective measure is available and no later than 14 days after. Rizzqo keeps you ready to meet each stage on time, with the affected products and evidence already to hand.
The CRA entered into force in December 2024, and its obligations phase in. The vulnerability and incident reporting duties under Article 14 apply from 11 September 2026, and the full set of obligations — essential requirements, conformity assessment and CE marking — applies from 11 December 2027. Rizzqo lets you stand the framework up now and track progress against those dates, so the deadlines are met with evidence rather than a scramble.
Yes. The CRA leans on practices ISO 27001 already asks of you — secure development, access control, cryptography and vulnerability management — so an information-security management system covers a real share of the ground. In Rizzqo both frameworks run on the same assets, so a control you proved for ISO 27001 counts toward the CRA immediately, leaving the genuinely product-specific requirements — secure-by-default delivery, SBOM, support-period updates and CE conformity — to close.