EU Cyber Resilience Act compliance and Article 14 reporting readiness

Turn the Cyber Resilience Act into an operating product-security system — from scope and cybersecurity risk assessment to vulnerability handling, conformity evidence and 24-hour reporting.

The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets mandatory lifecycle cybersecurity requirements for hardware and software products with digital elements made available on the EU market. Its Article 14 reporting obligations apply from 11 September 2026, before most other CRA obligations become applicable.

CRA dates that product teams need to act on

Article 14 reporting is not limited to products launched after December 2027. It applies to all in-scope products with digital elements made available on the EU market, including products placed on the market earlier. The reporting duty also continues after a product’s support period has ended.

Does the CRA apply to your product?

The CRA may apply where:

• software or hardware is made available on the EU market in the course of a commercial activity, whether for payment or free of charge;
• its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network;
• a software or hardware component is placed on the market separately;
• a remote data processing solution is designed and developed by the manufacturer, or under its responsibility, and the product would lose one of its functions without that processing;
• a product is marketed under your name or trademark, including where development or manufacturing is outsourced;
• a non-EU manufacturer supplies the product in the EU through an importer, distributor, authorized representative, online marketplace or another channel.

The obligations differ for manufacturers, authorized representative, importers, distributors and open-source software stewards. A manufacturer carries the primary product-security, documentation, conformity and Article 14 reporting duties. Importers and distributors have verification, escalation, cooperation and corrective-action obligations and may become manufacturers if they substantially modify a product or market it under their own name or trademark.

Software, SaaS and remote processing

Downloadable software and software that executes on a user’s device can be products with digital elements. A web application accessed exclusively through a browser is generally not a standalone product with digital elements; however, a cloud or back-end function may be part of a regulated product as its remote data processing solution. Scope therefore depends on product architecture, responsibility, intended purpose and the consequences of removing the remote processing — not on the “SaaS”, “cloud” or “on-premises” label alone.

Free and open-source software

Free and open-source software is not automatically outside the CRA. FOSS supplied for distribution or use in the course of a commercial activity may be in scope. Non-monetized FOSS that is not supplied commercially receives different treatment, while legal persons that provide sustained support and ensure the viability of FOSS intended for commercial activities may qualify as open-source software stewards. Individual contributors are not made responsible merely because they contribute code to a FOSS project that is not under their responsibility.

H-X documents the scope analysis per product, version, component, delivery model and economic-operator role. Where sector-specific EU legislation may exclude or modify CRA application, we record the dependency and coordinate the conclusion with the customer’s legal counsel.

What the CRA requires from manufacturers

Secure products based on a documented risk assessment

Before placing a product on the EU market, the manufacturer must perform and document a cybersecurity risk assessment. It must cover the product’s intended purpose, reasonably foreseeable use, operational environment, assets to be protected, attack paths, external dependencies, integrated components and the time the product is expected to remain in use.

The assessment must drive product design and the implementation of the essential cybersecurity requirements in Annex I. A company’s internal risk appetite, commercial strategy or cost considerations do not by themselves justify leaving a CRA-relevant risk untreated. Residual risk must be sufficiently addressed in light of the product’s intended purpose and reasonably foreseeable use.

Vulnerability handling throughout the support period

Manufacturers need an effective process to:

• identify and document vulnerabilities and product components, including a machine-readable software bill of materials appropriate to the product;
• receive external vulnerability reports through a coordinated vulnerability disclosure process;
• designate an easily identifiable single point of contact through which users can communicate directly and rapidly, without limiting that contact to automated tools;
• monitor vulnerabilities in first-party and third-party components;
• assess applicability, reachability, exploitability, severity and product impact;
• remediate vulnerabilities without delay in relation to the risks posed and provide security updates free of charge, subject to the narrow business-user arrangements that the CRA permits for certain tailor-made products;
• test and review product security effectively and regularly during the support period;
• protect the integrity and authenticity of updates and distribute them securely;
• report vulnerabilities in integrated components upstream to their manufacturer or maintainer;
• publish information about fixed vulnerabilities once a security update is available, while avoiding premature disclosure that would increase risk;
• retain the evidence needed for technical documentation, conformity assessment and market surveillance requests.

A justified support period — not a universal five-year default

The support period must reflect the time the product is expected to be in use. It is at least five years, unless the expected use time is demonstrably shorter. Products reasonably expected to remain in use for longer than five years require a correspondingly longer support period.

The decision should consider reasonable user expectations, the nature and intended purpose of the product, relevant EU law, comparable products, the availability of the operating environment, the support periods of third-party components providing core functions and relevant regulatory guidance. The end date — at least month and year — must be communicated clearly at the time of purchase.

A substantial modification requires the support-period criteria to be reassessed, but does not automatically restart or extend the period. The decisive question is whether the modification changes the factors that originally determined the product’s expected use time.

Technical documentation, conformity assessment and CE marking

The manufacturer must create technical documentation, demonstrate compliance with the applicable essential requirements, complete the appropriate conformity assessment, issue the EU declaration of conformity and affix the CE marking before placing the product on the market.

The technical documentation and EU declaration of conformity must remain available to market surveillance authorities for at least ten years after the product is placed on the market or for the support period, whichever is longer.

Most products can use internal control, or self-assessment, under module A. Different routes apply where a product’s core functionality makes it an important class I, important class II or critical product:

• important class I products may use internal control only where the applicable harmonized standards, common specifications or permitted cybersecurity certification scheme have been fully applied; otherwise, third-party assessment is required;
• important class II and critical products generally require a notified-body assessment or an applicable European cybersecurity certification scheme where the CRA permits one;
• specific rules apply to important free and open-source software.

H-X is not a notified body and does not sell a fictitious “CRA certificate”. We prepare the product, processes, testing evidence and technical file for the applicable conformity route and support interaction with a notified body where one is required.

CRA Exploited Vulnerability & Incident Reporting Readiness

From 11 September 2026, a product team may have only 24 hours to move from a verified security event to a regulatory early warning. A policy document or an annual CRA audit cannot provide that capability. The manufacturer needs a live workflow that connects Product Security, PSIRT, SOC, engineering, support, management, communications and legal counsel.

H-X implements and tests the complete operational chain:

Detection → exploit-status verification → regulatory classification → 24-hour early warning → 72-hour and subsequent notifications → remediation evidence

What must be reported?

Article 14 requires manufacturers to report:

1. An actively exploited vulnerability contained in the product. This means there is reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission.
2. A severe incident having an impact on the security of the product. The severity test includes whether the incident negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or whether it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user’s network and information systems.

Not every CVE, scanner alert or exploitable component vulnerability is a mandatory Article 14 report. The team must establish whether the vulnerable component and version are present, the vulnerable path is reachable or otherwise applicable, the vulnerability is contained in the product and there is reliable evidence of active exploitation affecting the product. Where the CRA vulnerability-handling requirements apply, the underlying vulnerability still requires assessment and remediation even if Article 14 mandatory reporting is not triggered.

When does the clock start?

A raw alert does not automatically establish awareness, and a manufacturer cannot postpone the clock until the entire investigation is complete. According to the Commission’s July 2026 guidance, the manufacturer becomes aware when an immediate initial assessment provides a reasonable degree of certainty that:

• a vulnerability contained in the product is being actively exploited; or
• a severe incident has occurred and compromised the security of the product.

We establish a defensible awareness timestamp, preserve the underlying evidence and record why the reporting threshold was or was not met.

Article 14 reporting timeline

Manufacturers submit once through the ENISA CRA Single Reporting Platform. The notification is routed to the CSIRT designated as coordinator and, except in particularly exceptional circumstances, is made available simultaneously to ENISA. The workflow must also identify the Member States in which the affected product has been made available and ensure appropriate handling of sensitive information.

The operational workflow we implement

1. Detect and open a controlled case

We connect or map relevant inputs: product telemetry, SOC/SIEM/EDR and cloud alerts, customer support, a published security contact, coordinated vulnerability disclosure, researcher reports, engineering findings, SAST/SCA/DAST, penetration tests, EUVD/CVE and vendor advisories, threat intelligence and credible public reporting.

Each potential event receives a case owner, initial timestamp, affected-product hypothesis, preservation instructions and escalation priority. A ticket alone is not enough: the case must preserve who knew what, when, and on what evidence.

2. Verify exploit status and product applicability

H-X helps the response team verify:

• affected product, model, version, build and distribution channel;
• component and dependency presence using SBOM and build evidence;
• vulnerable-code reachability, configuration, exposure and compensating controls;
• proof-of-concept relevance versus reliable evidence of malicious exploitation;
• indicators of compromise, product telemetry, customer evidence and trusted external intelligence;
• affected users, deployments and EU Member States;
• whether the vulnerability is contained in the product, including through an integrated third-party component.

The output is an evidence-backed exploit-status decision, not a severity score used as a substitute for legal classification.

3. Perform regulatory classification

We run the event through a documented CRA decision tree and prepare a decision record covering:

• product scope and the reporting entity’s role;
• actively exploited vulnerability criteria;
• severe-incident criteria;
• awareness time and supporting evidence;
• affected product versions and territories;
• information sensitivity and possible dissemination concerns;
• user-notification requirements;
• overlapping notification duties under NIS2, GDPR, DORA, sector rules or contractual commitments;
• the escalation and approval route, including customer legal counsel where a legal opinion is required.

The manufacturer retains responsibility for the regulatory decision and submission. H-X supplies cybersecurity, incident-response and compliance evidence and can support an authorized filer under an agreed mandate.

4. Prepare the 24-hour early warning

We maintain a pre-approved minimum-data template aligned with the ENISA SRP fields, current product inventory, reporting contacts, coordinator-CSIRT routing logic and an approval matrix. During an event, we prepare the early warning using confirmed information and clearly distinguish facts, assumptions and unknowns.

5. Manage the 72-hour notification, user communication and final report

As the investigation progresses, we update the event record and prepare:

• the general nature of the vulnerability and exploit, or the incident;
• detection and occurrence times;
• initial severity and impact assessment;
• corrective and mitigating measures already taken;
• actions available to users;
• the sensitivity classification;
• the final vulnerability or incident description, impact and root cause;
• security-update and remediation details;
• proportionate communications to impacted users and, where appropriate, all users.

6. Build remediation evidence and close the case

The final evidence pack may include:

• incident timeline and decision log;
• vulnerability, exploit and root-cause analysis;
• affected-version and distribution matrix;
• SBOM, VEX or equivalent applicability records;
• code commits, change approvals and build records;
• signed package identifiers, hashes and release evidence;
• security-test, regression-test and retest results;
• deployment or update-coverage evidence;
• security advisory and user communications;
• SRP submission receipts and correspondence;
• residual-risk decision and lessons learned.

This evidence supports the final Article 14 report, the technical documentation, management review and future market surveillance enquiries.

Readiness deliverables

The readiness engagement produces working assets, not only an assessment report:

• reporting-scope and product-portfolio register;
• Article 14 decision tree and classification worksheet;
• awareness-time and evidence rules;
• PSIRT/SOC/engineering/legal/management RACI and escalation matrix;
• 24-hour, 72-hour, final-report and user-notification templates;
• mapping to the current ENISA SRP data fields;
• secure case record and evidence-retention structure;
• SBOM and vulnerability-intelligence input map;
• regulatory overlap matrix;
• contact and approval playbook;
• tabletop exercise scenario, timed drill and improvement report;
• prioritised implementation backlog and optional post-remediation verification.

Complete CRA implementation service

The Article 14 workflow can be ordered separately or as part of a complete CRA programme.

1. Scope, role and product classification

We identify regulated products and components, remote data processing solutions, commercial FOSS, economic-operator roles, exclusions, product families, core functionality and default, important class I, important class II or critical classification.

2. CRA gap assessment and implementation plan

We map Annex I and Annex II requirements to product architecture, development, vulnerability handling, support, user information and existing controls. The result is an evidence-based gap register with owners, priorities and acceptance criteria.

3. Cybersecurity risk assessment and architecture

We build or improve the product-level risk assessment, threat model, abuse cases, security architecture and traceability from risk to requirement, control, test and evidence. We assess external dependencies and perform risk-based due diligence on integrated components.

4. Secure development and supply-chain controls

We integrate CRA requirements into your secure development lifecycle, product and DevOps security, release governance, SBOM/VEX process, coordinated vulnerability disclosure, update mechanism and supplier requirements.

5. Product security verification

Depending on the product and risk, we provide a source-code security audit, penetration testing, architecture and configuration review, dependency analysis, update-mechanism testing, remediation support and independent retesting.

6. Technical documentation and conformity readiness

We prepare the CRA evidence structure, risk assessment, essential-requirements matrix, product and architecture descriptions, test evidence, vulnerability-handling documentation, support-period rationale, user instructions, EU declaration inputs and conformity-assessment package. Where a notified body is required, we help resolve findings and maintain the evidence trail.

7. Ongoing product-security operations

CRA compliance continues after release. H-X can provide ongoing threat intelligence, SOC as a Service, incident investigation and forensics, vulnerability triage, reporting support, evidence maintenance, periodic exercises and security experts or a virtual CISO.

Substantial modifications: decide before release

A post-market change is a substantial modification where it affects compliance with the essential cybersecurity requirements in Part I of Annex I or changes the intended purpose for which the product was assessed.

A feature’s size is not the decisive factor. A small change can be substantial if it introduces a new threat vector, attack scenario or material change in likelihood or impact that the existing risk assessment did not address. Security updates are generally not substantial modifications where they reduce risk without changing intended purpose or introducing new risks. A security-driven update can still be substantial if it materially changes product boundaries, data flows, external interfaces or dependencies.

We add a release-gate assessment that records:

• whether intended purpose or core functionality changes;
• whether new interfaces, execution environments, communication channels or dependencies appear;
• whether attack scenarios, likelihood or impact change;
• whether the existing risk assessment and controls cover the change;
• whether a new conformity assessment, technical-file update, declaration or support-period reassessment is required.

Enforcement and penalties

National market surveillance authorities can request technical documentation and information, require corrective measures, restrict or prohibit a product, or order withdrawal or recall. CRA maximum administrative-fine tiers include:

• up to EUR 15 million or 2.5% of total worldwide annual turnover for breaches of the essential cybersecurity requirements and specified manufacturer obligations, including Articles 13 and 14, whichever is higher for an undertaking;
• up to EUR 10 million or 2% for breaches of other CRA obligations;
• up to EUR 5 million or 1% for supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities.

Actual penalties are determined under Member State law and the circumstances of the infringement. Microenterprises and small enterprises are not subject to administrative fines for missing the Article 14 24-hour deadline, and open-source software stewards are not subject to CRA administrative fines. These exceptions do not remove the underlying duties, corrective powers or operational need to respond.

Why H-X Technologies

CRA sits at the intersection of product engineering, offensive security, incident response and compliance. H-X brings these disciplines into one delivery team. We can move from a legal requirement to architecture, code, cloud, build pipeline, product telemetry, vulnerability triage, testing and audit-ready evidence without handing the customer a disconnected set of recommendations.

You can use H-X for a focused Article 14 readiness project, full CRA implementation, an independent security compliance audit, remediation testing or ongoing managed product-security operations.

Start with the deadline that arrives first

If your products are available in the EU, prepare the Article 14 workflow before the first reportable event starts the 24-hour clock. We can begin with one product and one timed scenario, then scale the process across the portfolio.

Official resources: Cyber Resilience Act legal text · European Commission CRA overview · Commission guidance of 27 July 2026 · CRA reporting obligations · ENISA Single Reporting Platform

Legal note: this page provides general information and describes cybersecurity and compliance services. It is not a legal opinion. Product-specific legal conclusions should be confirmed with qualified counsel.

Learn more about our comprehensive offers on cybersecurity auditing, testing, and enhancement solutions to ensure your products meet the new standards and remain competitive. Contact us today to learn more.

Submit the form below to request CRA implementation services.