Secure Product Design and Vulnerability Response under the EU Cyber Resilience Act (CRA)
1. Overview
A. Definition and background
The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, which sets cybersecurity duties for manufacturers of products with digital elements placed on the EU market, from design, development, and production through vulnerability handling and security updates.
Network-connected products now range from operating systems and applications to sensors, routers, smart appliances, industrial controllers, and development tools. A vulnerability in one product can cross the supplier boundary and provide an intrusion path into user devices, enterprise networks, cloud services, and the broader supply chain. Previously, support periods and vulnerability-handling practices varied by manufacturer, making it difficult for buyers to assess security status and end-of-support risk consistently.
The CRA links pre-market conformity with post-market vulnerability management in one framework. Manufacturers must design products securely, define support periods, receive and handle vulnerability reports, and distribute security updates. It is therefore more than a CE-marking or product-certification rule: it reshapes product-security lifecycles and manufacturer accountability.
B. Scope and objectives
The CRA covers products whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Scope includes software and hardware products, certain remote data-processing solutions for which the manufacturer is responsible, and software or hardware components placed on the market separately. Products supplied in the course of commercial activity may be covered whether sold for payment or provided free of charge; being free or open source does not automatically create an exemption.
Medical devices, in vitro diagnostic devices, products under vehicle type-approval rules, certified civil-aviation products, and marine equipment are among the excluded or separately regulated areas. There are also exceptions for products developed exclusively for national-security or defence purposes and for products specifically designed to process classified information. Where another EU law addresses the same cybersecurity risks, applicability may be adjusted under the Regulation's conditions. Scope must therefore be determined from product function, connectivity, method of supply, manufacturer responsibility, and other applicable legislation—not from a product label or industry alone.
The CRA aims to raise baseline security for products on the market and help users understand security status and support end dates. Product security does not end with pre-release testing; it must be maintained throughout use as new component vulnerabilities and attack techniques emerge. Distinguishing the roles of manufacturers, importers, distributors, and open-source software stewards helps close accountability gaps in the product ecosystem.
2. Regulatory structure and product lifecycle
CRA implementation is not a matter of assigning clauses to departments. It is lifecycle management that traces product risks to requirements, design decisions, test results, and updates. Manufacturers assess cybersecurity risks against intended purpose and reasonably foreseeable use, then reflect the results in product design and technical documentation. After release, they continue updating the assessment through vulnerability monitoring, remediation, user notices, security updates, and end-of-support planning.
flowchart LR
A["Determine product and market scope"] --> B["Cybersecurity risk assessment"]
B --> C["Security requirements and design"]
C --> D["Development, component checks, testing"]
D --> E["Conformity, technical file, CE marking"]
E --> F["Market release and user information"]
F --> G["Vulnerability intake and coordinated disclosure"]
G --> H["Security fix and safe update"]
H --> I["End of support and retirement guidance"]
G --> B
Risk assessment is not a document written once during design and then archived. When product functions, external interfaces, use environments, stored data, remote-management features, or newly discovered vulnerabilities change, the organization revisits risks and controls. For example, adding remote account recovery to a video camera requires reassessing authentication, privilege escalation, and privacy exposure, then adjusting security tests.
A. Responsibilities across the supply chain
The CRA places its primary duties on the manufacturer that makes a product available under its own name or trademark. Even if design and production are outsourced, a company that launches the product under its brand cannot avoid manufacturer accountability; it must control risk assessment and evidence of conformity. The manufacturer prepares technical documentation, the EU declaration of conformity, user instructions, the security support period, and vulnerability-handling processes.
Before first making a product available in the EU, an importer checks that the manufacturer completed conformity assessment and provided required documentation, CE marking, and contact details. If a product appears non-compliant or presents a significant risk, the importer restricts distribution until corrective action is taken and cooperates with competent authorities. A distributor checks that storage and transport do not undermine compliance and that product identification, contact details, and required instructions are provided.
An organization should not stop at adding “CRA compliant” to a procurement contract. It should link supplier conformity declarations, product versions, end-of-support dates, vulnerability disclosure channels, update policies, and component information to procurement and asset records. Without this information, a customer may struggle to identify affected devices and available support when a vulnerability is discovered.
B. Essential cybersecurity requirements
The essential requirements in Annex I apply in proportion to product risk. Manufacturers must design, develop, and produce products securely by default. At market placement, products must not have known exploitable vulnerabilities; they must provide appropriate secure default settings, access controls, and protection for data confidentiality, integrity, and availability. Products must reduce their attack surface, record relevant security activities, and, where appropriate, let users securely delete data or reset a device.
The appropriate controls depend on product functionality and threat model. Strong default authentication and secure remote updates may be central for a network camera, while tamper resistance, key lifecycle management, and secure key destruction may dominate for a cryptographic key device. Manufacturers should not apply one checklist mechanically to every product; their risk assessment should explain whether requirements apply and justify any exceptions.
Vulnerability handling spans report intake, validation, prioritization, remediation, user communication, update distribution, and post-fix verification. Manufacturers operate a coordinated vulnerability disclosure policy and reporting channel so researchers and customers can report issues safely. Vulnerabilities in third-party components are also a supply-chain risk for the final-product manufacturer; an open-source origin does not transfer the manufacturer's responsibility elsewhere.
A software bill of materials (SBOM) is a foundation for understanding components and dependencies. The CRA vulnerability-handling requirements specify an SBOM covering at least top-level dependencies, but an SBOM alone does not prove a product is secure. Component version, vulnerability impact, reachability in the product, exploitation status, mitigation, and release status must be connected for the SBOM to support response.
C. Support period and security updates
Manufacturers determine and document the vulnerability-handling support period by considering product nature, purpose, expected use, and reasonable user expectations. The period is at least five years in principle; where a product is expected to be used for less than five years, the reasonably expected period of use may be used. The manufacturer clearly states the end date at least by month and year and, where technically feasible, notifies users when support ends.
During the support period, manufacturers handle vulnerabilities without delay and provide necessary security updates. Updates are distributed securely and, where technically feasible, separately from functionality updates so that users can identify security fixes. Security updates are provided free of charge unless otherwise agreed, and notices explain relevant information and actions users need to take.
Each security update must remain available for at least ten years after issuance or for the remainder of the support period, whichever is longer. This is not merely a requirement to leave a file on a website; product identification, integrity, distribution paths, and end-of-support policies must be managed. For example, a security fix for a product with a seven-year support period must remain available for ten years after issuance; longer-lived products require planning against their support period.
A product may remain in use longer than its manufacturer's support period, so buyers need a plan to isolate or replace unsupported equipment. Manufacturers should transparently explain safe use after support ends and available risk-reduction options. The support period is not marketing copy; it is an operational basis for procurement, asset management, vulnerability response, and budgeting.
3. Vulnerability and severe-incident reporting, and conformity
The CRA requires manufacturers to report actively exploited vulnerabilities and severe incidents affecting product security once they become aware of them. The reporting model must connect security monitoring, product engineering, customer support, and supplier contacts so that the moment of awareness is not missed. Reportability is not identical to an enterprise-wide breach; the decision is based on the event's effect on product security and users' networks.
sequenceDiagram
participant R as Researcher, customer, or monitoring
participant M as Manufacturer security response
participant E as ENISA Single Reporting Platform
participant C as Designated coordinating CSIRT
participant U as Affected users
R->>M: Report vulnerability or product incident
M->>M: Validate, assess impact, record awareness time
M->>E: Early warning within 24 hours
E->>C: Share with competent coordinating CSIRT
M->>E: Detailed notification within 72 hours
M->>U: Mitigation, fix, and user guidance
M->>M: Prepare, distribute, and verify fix
M->>E: Vulnerability final report within 14 days after fix is available
M->>E: Incident final report within one month of notification
A. The 24-hour, 72-hour, and final-report sequence
For an actively exploited vulnerability, the manufacturer submits an early warning without undue delay and no later than 24 hours after becoming aware. Generally, within 72 hours it submits a vulnerability notification with available product and vulnerability information and mitigation or corrective measures. The final report is due no later than 14 days after a corrective or mitigating measure becomes available.
Severe incidents affecting product security also require an early warning within 24 hours and a notification within 72 hours. The final report for a severe incident is due within one month after submission of the incident notification. Where facts are not yet confirmed at the early stage, the organization states the uncertainty and updates the record as the investigation progresses.
The manufacturer notifies the designated coordinating CSIRT and ENISA through the Single Reporting Platform established by ENISA. Reporting automation records awareness time, product list, EU countries of availability, event classification, user impact, mitigation, and owner to support deadlines and evidence retention. At the same time, the organization controls information sensitivity and coordinated disclosure so that initial reporting does not expose vulnerability details prematurely.
B. Conformity assessment and product classes
The CRA varies conformity-assessment intensity according to product importance and cybersecurity risk. For ordinary products, manufacturers can use internal production control, EU-type examination followed by conformity to type, full quality assurance, or an available EU cybersecurity certification route. For important Class I products, a third-party conformity procedure may be required if applicable harmonised standards, common specifications, or certification schemes are unavailable or only partly applied.
Important Class II products face stronger evaluation through type examination and production control, full quality assurance, or a European cybersecurity certificate at the required assurance level. Important products can include operating systems, network-management and security tools, browsers, and cryptographic or authentication products. Examples of Class II products include hypervisors and container-runtime systems, firewalls and intrusion detection or prevention systems, and tamper-resistant microprocessors or microcontrollers.
Critical products listed in Annex IV use an EU cybersecurity certification scheme or a Class II assessment route specified by the Regulation. Product teams should therefore determine applicable annexes, assessment modules, and need for a notified body during initial classification—not after implementation. Incorrect classification can delay launch, increase testing costs, and weaken the basis for the declaration of conformity.
| Area | CRA focus | Practical evidence |
|---|---|---|
| Product classification | Ordinary, important Class I, important Class II, or critical product | Scope and class rationale |
| Risk assessment | Risk analysis proportionate to purpose, connectivity, threats, and impact | Assessment and control traceability |
| Conformity assessment | Internal or third-party route based on class and standards | Test report, certificate, declaration |
| Vulnerability operations | Intake, analysis, fix, reporting, and disclosure during support | CVD policy, incident record, updates |
| User information | Explain security features, support period, and safe use | Label, instructions, end-of-support notice |
The table summarizes traceability; it is not a checklist of document names. For example, if a product is classified as Class II, the organization should explain the annex criteria behind that decision, the selected assessment module, and how design requirements connect to test evidence. Technical documentation is not only a regulatory deliverable; it records product-design and verification decisions.
4. Comparison with related rules and industry cases
The CRA focuses on the product itself and the manufacturer's lifecycle responsibilities. NIS2 addresses cybersecurity risk management and incident response for essential and important entities; the GDPR governs personal-data processing; and the EU AI Act regulates AI-system risk, transparency, and governance. One product or company may be subject to several regimes, so organizations should map obligations to shared risk, asset, incident, and evidence data rather than build disconnected documentation sets.
| Dimension | CRA | NIS2 | GDPR |
|---|---|---|---|
| Main subject | Digital products and their manufacturers | Essential and important entities and their supply chains | Personal-data processing and data-subject rights |
| Main controls | Product design, vulnerability handling, updates, conformity | Organizational risk management, operations security, incidents | Lawfulness, minimization, security, breach notification |
| Primary lens | Product lifecycle before and after market placement | Cyber risk and continuity of organizational services | Rights and duties in personal-data processing |
| Intersection | A product vulnerability can compromise a customer entity | Product supply chain is an organizational dependency | Applies alongside CRA when the product processes personal data |
The first case is a manufacturer selling a connected home camera in Europe. Product classification covers the camera, app, remote storage, default credentials, update server, and components. Risk assessment identifies the path from a stolen account to video access and drives controls such as eliminating default accounts, secure pairing, administrative access controls, encryption, and update-integrity checks.
After release, a library in the camera app is found to have an actively exploited vulnerability. The manufacturer uses the SBOM and product-version data to identify affected devices. It records awareness time, prepares the 24-hour warning, 72-hour notification, and final report within 14 days after a fix is available, while notifying users and securely distributing an update. It maintains product and customer contact records because reporting may also affect legacy products.
The second case is a smart-meter gateway manufacturer proposing only a two-year security-update period. If the equipment is expected to remain installed in power infrastructure for more than ten years, such a short period may not align with product nature and reasonable user expectations. The manufacturer documents expected use, contractual and regulatory needs, and component support, then includes update costs, key management, and field-replacement planning in the product business model.
The third case involves a manufacturer integrating a foundational open-source library and a nonprofit foundation that provides sustained support for it. The manufacturer retains responsibility for final-product conformity and risk assessment while tracking the foundation's security policy, intake process, component version, and remediation releases. If the foundation qualifies as an open-source software steward under the CRA, it may have separate policy, developer-support, and cooperation duties; these do not replace the manufacturer's obligations.
5. Advanced topic: phased application and supply-chain execution in 2026
The CRA entered into force on 10 December 2024; the general product obligations apply from 11 December 2027. Chapter IV on notification of conformity-assessment bodies has applied since 11 June 2026, while manufacturers' vulnerability and severe-incident reporting duties have applied since 11 September 2026. Reporting also reaches in-scope products made available before full application in December 2027, so existing product inventories and customer-support systems must already be in scope.
The phased timeline changes the order of preparation. First, classify the portfolio and document manufacturer or importer roles and EU distribution routes. Second, activate vulnerability intake, awareness escalation, and submission through ENISA's Single Reporting Platform to meet the 24-hour deadline. Third, embed risk assessment, technical documentation, support periods, updates, and conformity assessment in product development before the 2027 general application date.
Cloud services require a function-by-function scope review. Remote data processing can form part of a product when it is designed or developed by, or under the responsibility of, the manufacturer and the product cannot perform one of its functions without it. It should not be assumed that every standalone general cloud service automatically becomes a CRA product; the product-service relationship and statutory definition need to be examined.
In open-source ecosystems, distinguish ordinary contributors from stewards that systematically provide sustained support. The CRA does not treat every volunteer contributor to free software as a manufacturer, but it imposes separate policy and cooperation duties on organizations that sustain products used in commercial activities. The final-product manufacturer performs due diligence on external code and designs reporting and remediation paths that fit both supply contracts and community operations.
6. Considerations and implications
A. Implement product security through traceability
Declaring security principles alone is insufficient evidence of conformity. Trace threat scenarios to requirements, design controls, test cases, unresolved defects, and release approval, with a clear owner for each decision.
B. Operate vulnerability response as a service
The 24-hour and 72-hour deadlines are easy to miss when product and security organizations are disconnected. Maintain a continuous contact path and deputies across product security, customer support, legal, supplier management, and EU reporting, then measure actual submission times through exercises.
C. Improve SBOM and product-identity quality
An inaccurate or stale SBOM can misidentify affected products and delay remediation. Link releases, customers, and component versions; interpret scanner matches together with reachability, exploitability, and mitigation status.
D. Align support periods with the business model
Long-term support requires security staff, signing keys, reproducible builds, distribution infrastructure, and field-update funding. Manufacturers should include support costs in product pricing and service agreements and fund operations through component end-of-life, cloud shutdown, and key rotation.
E. Classify products early
Discovering an important-product class or third-party assessment need at the end of development can cause redesign and launch delays. Review product scope, applicable standards, assessment bodies, and technical-document owners during product planning and architecture approval; reassess when functions or remote processing change.
F. Reuse controls across regimes
CRA, NIS2, GDPR, and AI rules differ in scope and legal duties but share controls such as risk assessment, asset inventories, incident response, access control, and evidence management. Use a common control library while keeping product-conformity, organizational-operation, and personal-data-breach responsibilities and deadlines distinct.
G. Prepare Korean firms for the EU market
Korean manufacturers supplying digital products to the EU may be affected based on market placement and their role in the supply chain. Manage product documentation, support periods, vulnerability channels, update policies, and contact owners at both contract and portfolio levels. Technical consultants should translate legal review into an execution roadmap integrating DevSecOps, SBOM, PSIRT, product lifecycle management, procurement, and customer support.
References
- EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act): https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
- European Commission, The Cyber Resilience Act — Summary of the legislative text: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- European Commission, Cyber Resilience Act — Reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- European Commission, Cyber Resilience Act policy page: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
In one line: The CRA embeds manufacturer accountability into the product lifecycle: build secure digital products, handle vulnerabilities throughout support, meet reporting duties from 2026, and prepare for general application in 2027.