ANSWERS
One question, one answer, no hedging.
The questions we are asked most often about the Cyber Resilience Act, system safety and product security — answered in a few sentences each, then explained.
Cyber Resilience Act
- Does the Cyber Resilience Act apply to my product?The CRA applies to any product with digital elements placed on the EU market that has a direct or indirect logical or physical connection to a device or network, whether hardware or software. A small number of categories are excluded because they are already covered by equivalent sector-specific rules, such as certain medical devices, vehicles and aviation equipment.
- When does the Cyber Resilience Act apply?The CRA entered into force on 10 December 2024. Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. The remaining obligations, including essential requirements, conformity assessment and CE marking specific to the CRA, apply from 11 December 2027.
- Are products already on the market affected by the CRA?Products lawfully placed on the market before the relevant obligations apply are generally not required to be redesigned retroactively. However, a substantial modification after the obligations take effect can bring a product back into scope, and ongoing obligations such as vulnerability handling apply based on current supply and support rather than the original placing-on-market date.
- What counts as a substantial modification under the CRA?A substantial modification is a change to a product with digital elements that affects its compliance with the essential cybersecurity requirements or changes its intended use, for example a significant software update that alters functionality or connectivity. A substantial modification after the CRA's obligations apply can bring a previously exempt product back into scope, requiring a fresh conformity assessment.
- What are important and critical products under the CRA?The CRA introduces two categories of higher-risk products with digital elements, listed in its annexes: important and critical. Important products include categories such as operating systems, firewalls and password managers; critical products include hardware security modules and other components where a failure could have a wide security impact. Both categories attract stricter conformity assessment routes than default products.
- What conformity assessment routes exist under the CRA?The CRA sets out different conformity assessment routes depending on a product's classification. Default products generally allow manufacturer self-assessment against the essential requirements. Important products typically require either a documented self-assessment against harmonised standards or third-party involvement, while critical products require third-party conformity assessment by a notified body.
- Is CE marking under the CRA a new marking scheme?No. The CRA uses the existing CE marking framework rather than introducing a separate mark. It adds cybersecurity as a further requirement that a product with digital elements must satisfy, alongside any other applicable EU legislation, before the CE mark can be affixed and the product placed on the EU market.
- What technical documentation does the CRA require?The CRA requires technical documentation that demonstrates conformity with the essential cybersecurity requirements, including a description of the product's design and development, the cybersecurity risk assessment, verification and test results, and the software bill of materials. This documentation must be retained for a defined period after the product is placed on the market.
- What is a software bill of materials (SBOM)?A software bill of materials is a structured, machine-readable inventory of the components, libraries and dependencies used to build a software product, typically including component names, versions and supplier information. Under the CRA, manufacturers must produce an SBOM for products with digital elements in a commonly used format, covering at least top-level dependencies.
- Should an SBOM be generated manually or by the build pipeline?An SBOM should be generated automatically as part of the build pipeline rather than compiled manually at the end of a project. Automated generation keeps the inventory accurate as dependencies change, supports the CRA's requirement for up-to-date documentation, and provides the queryable component data needed to respond quickly when a vulnerability is disclosed in a shared dependency.
- What must a CRA vulnerability handling process include?A CRA-compliant vulnerability handling process must include a published point of contact for reporting, a coordinated disclosure procedure, an internal triage capability to assess severity and exploitation status, and a mechanism to deliver free security updates for the product's defined support period. Reviewers expect evidence that the process is operating, not only documented.
- What are the CRA's vulnerability reporting timelines?From 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents to the relevant authority — typically ENISA and the national CSIRT — within a 24-hour early warning, followed by a fuller notification within 72 hours, and a final report once the issue is resolved. Meeting these windows depends on an accurate component inventory and a rehearsed decision chain.
- What counts as a severe incident under the CRA?The CRA does not set a single numeric threshold for a severe incident. It is generally understood as an incident with a significant negative impact on the availability, confidentiality or integrity of a product with digital elements, or on the services it supports. Manufacturers need documented, consistent triage criteria to make this judgement quickly enough to meet reporting deadlines.
- Does the CRA apply to open-source software?Open-source software developed and supplied outside a commercial activity is generally outside the CRA's scope. Once open-source components are integrated into a commercial product, responsibility shifts to the manufacturer of that product, who must cover those components in the SBOM and risk assessment. The CRA introduces a lighter set of obligations for open-source stewards of widely used projects.
- What obligations does the CRA place on open-source stewards?The CRA defines a narrower category of obligations for open-source software stewards, such as foundations that coordinate widely used projects on a non-commercial basis. These focus on cybersecurity policy, vulnerability handling coordination and cooperation with authorities, and are proportionate to a non-commercial role rather than mirroring full manufacturer obligations.
- Who is responsible for CRA compliance in a supply chain?The manufacturer of the finished product with digital elements carries the primary CRA obligations, including risk assessment, conformity assessment and vulnerability handling. Component suppliers have narrower duties, mainly providing information the manufacturer needs for its own risk assessment and SBOM. Importers and distributors have separate, lighter duties to verify conformity markings and documentation before placing or making a product available.
- What are an importer's obligations under the CRA?Under the CRA, an importer must verify that a manufacturer outside the EU has carried out the appropriate conformity assessment, that CE marking and required documentation are present, and that a point of contact for cybersecurity issues exists. Importers must also ensure storage and transport conditions do not compromise conformity, and must inform the manufacturer or authorities if they identify non-conformity.
- What are a distributor's obligations under the CRA?A distributor's CRA obligations are lighter than a manufacturer's or importer's: before making a product available on the market, a distributor must verify that CE marking, the EU declaration of conformity and required accompanying information are present, and must not make available a product it knows or suspects to be non-conformant. Distributors must also cooperate with market surveillance authorities.
- What are the penalties for CRA non-compliance?The CRA allows national market surveillance authorities to impose administrative fines for non-compliance, with the regulation setting maximum fine levels similar in scale to other EU digital and product legislation, calculated as a percentage of global annual turnover or a fixed amount, whichever is higher. Authorities can also require corrective action, restrict market availability or order a product's withdrawal or recall.
- What do market surveillance authorities check under the CRA?Market surveillance authorities check that technical documentation shows a coherent chain from identified risks to design decisions to verification evidence, and that CE marking and declarations of conformity are correctly in place. They also expect to see evidence that the vulnerability handling process is actually operating, such as intake records and update history, rather than only a written policy.
- What is the CRA's support period?The support period is the length of time, defined by the manufacturer and reflecting the product's expected use, during which security updates must be provided free of charge. It must be documented and communicated to users, and the mechanism for delivering updates to deployed units must be planned and demonstrably capable of reaching the installed base, not merely stated as a policy.
Product security
- What is IEC 62443?IEC 62443 is a series of international standards addressing the cybersecurity of industrial automation and control systems, covering security requirements for asset owners, integrators, product suppliers and the products themselves. It defines security levels, zones and conduits for network segmentation, and secure development lifecycle requirements for products, notably in IEC 62443-4-1.
- What are IEC 62443 security levels?IEC 62443 defines security levels from SL 0 to SL 4, describing the capability of a system or component to resist attacks of increasing sophistication and resources, from no protection at SL 0 through to protection against attacks by resourceful, highly motivated adversaries with extended resources at SL 4. Levels are assigned per zone or component based on a documented risk assessment, not applied uniformly across a system.
- How does IEC 62443 relate to CRA compliance?IEC 62443 is not itself a CRA harmonised standard, but its secure development lifecycle and product security requirements map closely onto several CRA essential requirements, particularly around secure design, vulnerability handling and secure default configuration. Manufacturers already following IEC 62443-4-1 and 4-2 typically have a head start on demonstrating CRA conformity, though a direct evidence mapping is still needed.
- What is ISO/SAE 21434?ISO/SAE 21434 is the international standard for cybersecurity engineering in road vehicles, defining a risk-based approach across the vehicle lifecycle from concept through development, production, operation and decommissioning. It requires a threat analysis and risk assessment (TARA), cybersecurity goals and requirements traceable to those goals, and verification evidence, mirroring the structure of functional safety standards such as ISO 26262.
- What is a threat analysis and risk assessment (TARA)?A threat analysis and risk assessment is a structured method, required by ISO/SAE 21434, for identifying assets, threat scenarios and attack paths for a system, and assessing the resulting risk in terms of impact and attack feasibility. The output determines cybersecurity goals and requirements, which must then be traced through design, implementation and verification.
- How do ISO 26262 and ISO/SAE 21434 relate to each other?ISO 26262 addresses functional safety in road vehicles, focused on risks arising from malfunctioning behaviour, while ISO/SAE 21434 addresses cybersecurity, focused on risks arising from malicious attack. The two standards share a similar lifecycle structure and both rely on hazard or threat analysis followed by traceable requirements and verification, and vehicle programmes typically run safety and security analyses in a coordinated way because a security compromise can create a safety hazard.
- What is the purpose of threat modelling?Threat modelling is a structured exercise, carried out early and revisited through a product's development, to identify how a system could be attacked, which assets and interfaces are exposed, and which mitigations are proportionate. Its purpose is to shift security decisions to the design stage, where they are cheaper to make, rather than discovering weaknesses through testing or after deployment.
- What is a secure development lifecycle (SDL)?A secure development lifecycle is a set of security activities integrated into each phase of software or product development, from requirements and design through implementation, verification and release, rather than security testing bolted on at the end. Typical activities include threat modelling, secure coding standards, static and dynamic analysis, and a vulnerability handling process that continues after release.
Functional safety
- What is ISO 26262?ISO 26262 is the international standard for functional safety of electrical and electronic systems in road vehicles, defining a lifecycle from concept and hazard analysis through system, hardware and software development to production and operation. It introduces Automotive Safety Integrity Levels (ASIL) to grade risk and scale the rigour of development and verification activities accordingly.
- What is an ASIL rating?An Automotive Safety Integrity Level (ASIL) is a risk classification defined by ISO 26262, ranging from ASIL A (lowest) to ASIL D (highest), plus QM for hazards not requiring safety measures. It is derived from an assessment of severity, exposure and controllability for a given hazardous event, and determines the rigour required for the associated development and verification activities.
- What is the difference between SIL and ASIL?Safety Integrity Level (SIL), defined by IEC 61508, and Automotive Safety Integrity Level (ASIL), defined by ISO 26262, are both risk-based classification schemes that scale the rigour of safety engineering to the severity of potential harm. SIL is used across general industrial functional safety applications, while ASIL is specific to road vehicles and is derived using a different risk parameter set tailored to automotive scenarios.
- What is IEC 61508?IEC 61508 is the base international standard for the functional safety of electrical, electronic and programmable electronic safety-related systems, applicable across industries and forming the basis for several sector-specific derivatives such as ISO 26262 for road vehicles and IEC 61511 for process industries. It defines a safety lifecycle, Safety Integrity Levels (SIL) and requirements for hardware and software development.
- What is a hazard analysis and risk assessment?A hazard analysis and risk assessment (HARA) is a structured method for identifying hazardous events a system could cause, and for estimating the associated risk using parameters such as severity, exposure and controllability. Its output is a set of safety goals and an assigned integrity level, such as ASIL or SIL, which then drives the scope and rigour of subsequent design and verification work.
System safety
- What is the purpose of a safety case?A safety case is a structured argument, supported by evidence, that a system is acceptably safe for a specific application and operating context. Its purpose is to make the reasoning behind a safety claim explicit and reviewable, linking hazards, mitigations, design decisions and verification results into a coherent chain rather than leaving safety confidence implicit in scattered documents.
- What evidence supports a safety case?A safety case is typically supported by hazard analysis records, derived safety requirements, design rationale showing how each requirement is met, verification and test results, and records of any residual risk acceptance. Evidence should be traceable end to end, so a reviewer can follow the argument from an identified hazard to the specific mitigation and the proof that it works as intended.
- How do safety and security interact in system design?Safety and security analyses address different causes — unintended malfunction versus deliberate attack — but their consequences can converge, since a successful cyber attack can create a safety hazard in a connected system. Programmes that run safety and security assessments in isolation risk missing these interactions, so coordinated hazard and threat analysis, and shared traceability between safety and security requirements, is increasingly treated as necessary practice.
Engineering practice
- Why is requirements traceability important?Requirements traceability links each requirement to its origin, such as a hazard or stakeholder need, and forward to its design, implementation and verification evidence. It matters because it lets a reviewer confirm that every requirement has been addressed and tested, and that every design decision and test exists for a reason, which is essential evidence in safety cases, security conformity assessments and audits.
- What is the difference between verification and validation?Verification confirms that a system meets its specified requirements, typically answering 'did we build it right', while validation confirms that the system meets the actual needs of its intended use in its operating context, answering 'did we build the right thing'. Both are needed because a system can satisfy every written requirement and still fail to be fit for purpose if the requirements themselves were incomplete or wrong.