Framework

EU Cyber Resilience Act
essential requirements, vulnerability handling, and incident reporting

Regulation (EU) 2024/2847 raises the cybersecurity baseline for products with digital elements placed on the EU market. Run CRA conformity work, manage essential cybersecurity requirements, handle vulnerabilities across the support period, and produce ENISA-ready incident reports from one workspace.

Get Started Free

No credit card required. Free plan available forever.

The Cyber Resilience Act in context

Regulation (EU) 2024/2847, the Cyber Resilience Act, was adopted in October 2024 and published in the Official Journal in November 2024. It sets a horizontal cybersecurity baseline for products with digital elements (PDE) placed on the EU market. The regulation entered into force in late 2024 and applies fully 36 months later, with selected provisions on incident and vulnerability reporting applying earlier (21 months after entry into force). The vulnerability handling and reporting obligations are the first items most teams need to operationalise; the conformity assessment and CE marking obligations land at full application.

CRA sits alongside other EU cybersecurity instruments without replacing them. The NIS2 Directive governs the cybersecurity risk-management measures of essential and important entities; DORA governs the digital operational resilience of EU financial entities; and GDPR governs personal data protection. CRA addresses a gap none of those filled: the cybersecurity properties of the products themselves. A vendor selling a SIEM into an essential entity may be in scope of CRA as a manufacturer, while the buyer is in scope of NIS2 as an essential entity. The two regimes interlock through supply chain security provisions on the buyer side and product conformity on the seller side.

Product classes: where the conformity route is set

CRA splits PDEs into four classes that determine the conformity assessment route. The product class is the structural feature that drives the cost and the timeline of the conformity work, so classifying each product version correctly before any other CRA work starts is the step that prevents downstream rework.

Default products with digital elements

The baseline class. Self-assessment by the manufacturer is sufficient. Most consumer software, mobile apps, smart accessories, and embedded firmware that does not sit on the Annex III list lands here. The manufacturer applies the essential requirements, runs the vulnerability handling process, prepares the technical documentation, and issues the EU declaration of conformity without involving a notified body.

Important products class I (Annex III)

Higher-risk products listed in Annex III class I, including identity management software, password managers, browsers, antivirus, VPN, network management, SIEM, PKI components, and smart home assistants. Self-assessment is permitted if the manufacturer applies the relevant harmonised standards or European cybersecurity certification scheme; otherwise a third-party conformity assessment is required.

Important products class II (Annex III)

Annex III class II includes hypervisors and container runtimes, firewalls and IDS/IPS for industrial use, hardware tamper-resistant microprocessors and microcontrollers, and similar foundational security components. Third-party conformity assessment is the default route for class II, with assessment performed by a notified body or under an applicable European cybersecurity certification scheme at the relevant assurance level.

Critical products (Annex IV)

Critical products, identified through delegated acts, are products whose failure could cause significant disruption to critical supply chains. The Commission may make European cybersecurity certification under a relevant scheme mandatory for critical products. Manufacturers should track Annex IV evolution because reclassification changes the conformity assessment route.

Annex I Part 1: essential cybersecurity requirements

Annex I Part 1 lists the cybersecurity properties every PDE has to meet on placing on the market. The list below paraphrases the requirements; the authoritative text is the Annex itself. Track each requirement as an open work item against the product version, with the design rationale, the test outcome, and the residual risk recorded so the conformity decision is defensible at market surveillance review.

Made available on the market without known exploitable vulnerabilities, with the SBOM and the vulnerability inventory current at the placing-on-the-market date
Designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks, with security applied throughout the lifecycle
Delivered with a secure-by-default configuration, including the possibility to reset the product to its original state where appropriate
Ensures protection from unauthorised access by appropriate control mechanisms, including authentication, identity, and access management systems
Protects the confidentiality, integrity, and availability of stored, transmitted, or otherwise processed data, personal or otherwise
Processes only data that is adequate, relevant, and limited to what is necessary in relation to the intended use of the product (data minimisation)
Protects the integrity of stored, transmitted, or otherwise processed data, commands, programs, and configuration against any manipulation
Designed to limit attack surfaces, including external interfaces, and provides security through default configurations and the absence of unnecessary features
Designed to mitigate the impact of an incident, including using appropriate exploitation mitigation mechanisms and techniques
Provides security-related information by recording or monitoring relevant internal activity, including the access to or modification of data, services, or functions
Ensures that vulnerabilities can be addressed through security updates, including, where applicable, automatic updates and clear notifications to users

Annex I Part 2: vulnerability handling across the support period

Annex I Part 2 sets the vulnerability handling obligations that apply across the entire support period, not just at placing on the market. This is the operational core of CRA for any product team: the regulation expects a continuous process for identifying, addressing, disclosing, and patching vulnerabilities, with evidence captured against the product version each step of the way.

Identify and document the vulnerabilities and the components contained in the product, including by drawing up a software bill of materials covering the top-level dependencies
Address and remediate vulnerabilities without delay, in particular by providing security updates, taking into account the risk and the technical complexity
Apply effective and regular tests and reviews of the security of the product across the support period
Once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description, the affected products, the impact, the severity, and clear and accessible information allowing users to remediate
Put in place and enforce a coordinated vulnerability disclosure policy with a single point of contact and a clear process for receiving, evaluating, and responding to reports
Take measures to facilitate the sharing of information about potential vulnerabilities, including a public mechanism for reporting
Provide for mechanisms to securely distribute updates to ensure that exploitable vulnerabilities are fixed in a timely manner, free of charge, and accompanied by advisory messages

The regular tests and reviews requirement is where penetration testing, vulnerability scanning, and code review feed directly into CRA evidence. The penetration testing workflow keeps engagement scope, findings, and remediation tied to the product version, and the continuous penetration testing workflow covers the cadence model that fits CRA support-period expectations rather than a single annual snapshot. For the inbound side of the disclosure policy, the vulnerability disclosure program management workflow covers triage, acknowledgement, and the closed-loop disclosure record that CRA expects. For the international standard the CRA disclosure obligation reads against, the ISO/IEC 29147 vulnerability disclosure framework page covers the five-phase disclosure lifecycle and the audit-grade evidence pack manufacturers produce against the CRA requirement.

Reporting clocks: actively exploited vulnerabilities and severe incidents

CRA introduces a structured reporting timeline through the ENISA single reporting platform. Manufacturers must notify the relevant CSIRT and ENISA when they become aware of an actively exploited vulnerability contained in their product or a severe incident having an impact on the security of the product. The clocks below run from the moment of awareness, not from the moment of confirmation, so the trigger needs to be operational rather than a debate at incident time.

Early warning: 24 hours after the manufacturer becomes aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product, submitted via the ENISA single reporting platform with the basic facts known at the time
Incident notification: 72 hours after awareness, updating the early warning with the corrective or mitigating measures taken or under consideration and the available indicators of compromise
Final report: within 14 days after the corrective or mitigating measures have been deployed, covering a description, the severity and impact, where available the type of malicious actor, and the security updates or mitigations supplied
Manufacturers must also inform users of an actively exploited vulnerability or a severe incident in a timely manner and, where applicable, provide instructions on the corrective measures the user can deploy

The structural risk in CRA reporting is the gap between the engineering team that detects the vulnerability and the legal or regulatory team that submits the report. Driving the timeline from the same workspace that holds the vulnerability triage and the incident record closes that gap because the early warning, the notification, and the final report all reference the same underlying record. The aging pentest findings research covers the broader operational pattern of how unpatched findings turn into the regulatory risk CRA is designed to surface.

Annex II: technical documentation and the SBOM

Annex II prescribes the technical documentation pack the manufacturer prepares and retains for at least ten years from placing on the market. The pack supports the EU declaration of conformity and is the body of evidence market surveillance authorities review when they check conformity. The list below is the working set of artefacts a CRA documentation pack commonly contains; the exact contents vary by product class and conformity route.

General description of the product, including the intended use and a description of the variants, versions, and configurations covered by the documentation
Risk assessment, identifying the cybersecurity risks and the mitigating measures applied, with the rationale for the assumptions and the controls chosen
Description of the design and development process, the cybersecurity assurance activities, and the chosen conformity assessment route with reference to the harmonised standards or schemes applied
Software bill of materials covering the top-level dependencies, refreshed across the support period, with each component identified by name, version, and supplier where available
Test reports for the cybersecurity assurance activities, including penetration test reports, code review outcomes, vulnerability scan output, and the remediation evidence for any findings raised
Vulnerability handling policy, the coordinated vulnerability disclosure policy, the security update mechanism, and the process used to refresh the SBOM across the support period
EU declaration of conformity covering the relevant Union legislation applied to the product, with the issuing manufacturer and the date and place of issue recorded
Where applicable, the certificate or notified body opinion supporting the conformity route, with the certificate identifier and the validity period referenced from the documentation pack

The SBOM is the documentation item most teams underestimate. CRA expects a software bill of materials covering the top-level dependencies, kept current across the support period, and tied to the vulnerability handling process so a new disclosure against a listed component triggers the right downstream actions. The vulnerable dependencies guide covers the detection and triage discipline that pairs with SBOM maintenance, and the hardcoded secrets guide covers a related class of finding that surfaces during code review and secret scanning across the support period.

Supply chain roles: who owns what under CRA

CRA assigns differentiated obligations across the supply chain. The most common misalignment is treating the regulation as a manufacturer-only problem: importers and distributors carry verification duties that turn into liabilities if a non-conformant product is placed on the market through them. Mapping the supply chain relationship per product makes the obligation lines visible.

Manufacturer

Carries the primary load: design and development under the essential requirements, conformity assessment, vulnerability handling, technical documentation, EU declaration of conformity, CE marking, security updates across the support period, and incident and actively exploited vulnerability reporting. Manufacturers based outside the EU appoint an authorised representative established in the Union to act on their behalf.

Importer

Verifies before placing the product on the market that the manufacturer has carried out the conformity assessment, that the technical documentation and the EU declaration of conformity are available, and that the CE marking is affixed. When an importer has reason to believe that a product is not in conformity, it shall not place the product on the market until conformity is brought back, and informs the manufacturer and market surveillance authorities where appropriate.

Distributor

Acts with due care in respect of CRA requirements when making a product available on the market: verifies the CE marking, the EU declaration of conformity, the user instructions, and the language requirements. When a distributor has reason to believe a product is not in conformity, it shall not make the product available until conformity is brought back, and informs the manufacturer or importer.

Open-source software steward

CRA introduces a lighter regime for open-source software stewards: a legal person other than a manufacturer that supports on a sustained basis the development of free and open-source software products with digital elements intended for commercial activities. Stewards have a tailored set of cybersecurity-related obligations rather than the full manufacturer load, with guidance focused on documentation, vulnerability handling, and cooperation with market surveillance.

How SecPortal aligns to CRA work

SecPortal is built for security service providers and internal security teams running regulated assessment cycles. CRA fits the platform model directly: the product classification drives the engagement, the assessor walks the essential requirements on the workspace, the SBOM and findings sit on the product record, and the technical documentation reflects what the workspace already says.

Compliance tracking that maps Annex I essential requirements, Annex II documentation, vulnerability handling obligations, and reporting clocks to the product version on a single workspace
Engagement management dedicated to CRA work: conformity assessment, periodic security testing across the support period, third-party assessor coordination, and the renewal cycle
Findings management with CVSS 3.1 scoring, 300+ templates, and explicit mapping of vulnerability findings to the affected product version and the relevant essential requirement
AI report generation that turns assessor notes, vulnerability triage records, and remediation evidence into the CRA technical documentation pack and the EU declaration of conformity narrative
External and authenticated scanning to feed the regular tests and reviews requirement under Annex I Part 2, with scheduled scans across the support period
Code scanning (SAST and SCA) to support the SBOM obligation, identify component vulnerabilities, and feed the vulnerability handling process across the support period
Continuous monitoring with scheduled scans and findings audit trail so the support-period evidence is durable rather than reconstructed at audit time

For teams running CRA work alongside other EU obligations, the NIS2 framework page covers the buyer-side risk-management measures and the supply chain security clauses CRA is the natural counterpart to. The DORA framework page covers the financial-sector operational resilience regime that overlaps CRA when a financial entity buys a regulated PDE. The CRA vulnerability handling guide walks through Articles 13 and 14 in operational detail, including the seven Article 13 manufacturer obligations, the 24-hour, 72-hour, and 14-day Article 14 reporting cascade, and the supporting evidence stack a market surveillance authority reads against. For the broader pentest evidence pattern that feeds the CRA testing requirement, the pentest evidence management workflow covers how to keep test artefacts durable across the support period without losing the audit trail.

Practical sequencing: a CRA programme across the product lifecycle

CRA is a lifecycle regulation, not an audit-time event. The sequencing below is the pattern that holds across most PDE manufacturers: classification first, conformity at placing on the market, and continuous obligations across the support period. Treating CRA as a one-time conformity step misses where most of the work actually lives.

Pre-launch: classify each product version (default, important class I, important class II, critical), lock in the conformity route, run the design-time risk assessment, generate the initial SBOM, and complete the security testing under the chosen route
Placing on the market: confirm no known exploitable vulnerabilities are present, finalise the technical documentation pack, issue the EU declaration of conformity, affix the CE marking, and publish the support period and the coordinated vulnerability disclosure policy
Across the support period: run scheduled vulnerability scans, accept inbound vulnerability reports through the disclosure policy, triage and patch under SLA, refresh the SBOM, and publish security advisories with each fix release
On a severe incident or actively exploited vulnerability: trigger the 24-hour early warning, the 72-hour incident notification, and the 14-day final report through the ENISA single reporting platform, and inform users where required by the regulation
On end-of-support: communicate the end-of-support date, publish the migration path for users, and retain the technical documentation and conformity evidence for at least ten years from placing on the market

Common deviation patterns and how to record them

Most product teams entering their first CRA cycle carry a small number of gaps against the essential requirements. The defensible position is not zero gaps; it is documented gaps with a rationale, a mitigating control, an owner, a remediation plan, and a re-evaluation date. The pattern below is what a market surveillance review reads as a mature programme.

Gap reason recorded against the essential requirement with the design or operational context, in plain language tied to the product version
Mitigating control identified and tied to the gap, with the evidence the mitigation is implemented and operating across the support period
Risk acceptance signed by the accountable owner, with the date and the duration of the acceptance bounded against the next product release or the remediation deadline
Remediation plan attached to the gap with owners, deadlines, and the explicit retest condition that closes the gap when met
Re-evaluation date on the gap so the next product release does not silently inherit the acceptance without a fresh review of the underlying conditions

Scope and limitations

The Cyber Resilience Act is the regulation operated by the European Union and enforced by national market surveillance authorities. SecPortal is the workspace that holds the engagement, the controls, the evidence, and the audit trail. Submission to the ENISA single reporting platform and engagement with notified bodies remain actions the manufacturer takes through the relevant authority interfaces; SecPortal holds the supporting record so the submission and the conformity decision are grounded in the evidence pack rather than reconstructed from email and shared drives.

The dates of application, the in-force product class lists, the harmonised standards referenced, and the implementing acts are published by the European Commission and evolve over time. This page describes the structure of the regulation and how a workspace-driven programme plays against it; the authoritative reference for the in-force obligations and the implementation guidance remains the published text of Regulation (EU) 2024/2847 and the Commission acts that follow it.

Key control areas

SecPortal helps you track and manage compliance across these domains.

Products with digital elements and the CRA scope

CRA applies to products with digital elements (PDE) made available on the EU market: software, firmware, hardware, and the data processing solutions and remote data processing solutions intended to be connected. Capture each product as a structured record with the SKU, the version line, the support period commitment, the importer and distributor relationships, and the conformity route so the regulation maps to a real catalogue rather than a marketing description.

Annex I essential cybersecurity requirements

Annex I of the CRA sets the essential cybersecurity requirements every PDE must meet: security by design, no known exploitable vulnerabilities at placing on the market, secure default configuration, protection against unauthorised access, confidentiality, integrity, availability, data minimisation, resilience, attack surface reduction, mitigation of impact, and security update mechanisms. Track each requirement as an open work item against the product version with the design evidence, the test outcome, and the residual risk.

Annex I Part 2 vulnerability handling requirements

CRA mandates a vulnerability handling process across the support period: identify and document components, address and remediate vulnerabilities without delay, apply effective and regular tests, share information about fixed vulnerabilities, enforce a coordinated vulnerability disclosure policy, and provide security update mechanisms. Hold the policy, the triage workflow, the patch SLA, and the disclosure record on one platform so the manufacturer obligation is provable rather than asserted.

Annex II technical documentation and SBOM

Annex II requires technical documentation covering risk assessment, the design and development process, the chosen conformity route, the list of relevant standards applied, an explanation of how the product meets the essential requirements, and the software bill of materials covering the top-level dependencies. Generate the SBOM, attach it to the product version, refresh it across the support period, and keep the documentation pack ready for market surveillance authorities.

Conformity assessment and the product class split

CRA splits PDEs into default products, important products class I, important products class II, and critical products. Default products use self-assessment. Important class I products may use self-assessment if harmonised standards are applied; otherwise a third-party conformity assessment is required. Important class II and critical products require third-party assessment. Map the product to the right class, lock in the assessment route, and capture the conformity declaration with the supporting evidence.

Actively exploited vulnerability and severe incident reporting

Manufacturers must notify the relevant CSIRT and ENISA via the ENISA single reporting platform on a 24-hour early warning, a 72-hour incident notification, and a final report within 14 days for actively exploited vulnerabilities, with parallel obligations for severe incidents that have an impact on the security of the product. Drive notifications from the same workspace that holds the vulnerability triage and the incident record so the timeline reflects the reality.

Support period, security updates, and end-of-support

Manufacturers determine and publish the support period during which security updates are provided, with a presumption of at least five years unless the lifetime of the product is shorter. Track the support period per product version, the security update cadence, the end-of-support date, and the migration path for users. CRA expects the support period and the update commitments to be communicated clearly at the point of sale.

Manufacturer, importer, and distributor obligations

CRA assigns specific obligations to manufacturers, importers, and distributors. Manufacturers carry the conformity, vulnerability handling, and incident reporting load. Importers verify that the manufacturer has done the work and may need to act when a non-conformity is found. Distributors verify the CE marking and the documentation. Map the supply chain relationship per product so the regulation lands on the correct entity rather than getting passed downstream.

Related features

Compliance tracking without a full GRC platform

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

AI-powered reports in seconds, not days

Test web apps behind the login

Vulnerability scanning tools that map your attack surface

Find vulnerabilities before they ship

Run a defensible CRA programme without document sprawl

Bring essential requirements, vulnerability handling, SBOM evidence, and incident reporting into one workflow. Start free.