Question 1

Does my product fall under the CRA?

Accepted Answer

The CRA applies to virtually all products with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Exempt are sectors for which equivalent cybersecurity rules already exist:

• Medical devices (Regulation (EU) 2017/745 and 2017/746)
• Motor vehicles (Regulation (EU) 2019/2144)
• Civil aviation (Regulation (EU) 2018/1139)
• Marine equipment (Directive 2014/90/EU)

Important: Generic components that can be used in both exempt and non-exempt products still fall under the CRA.

(Art. 2(1), Art. 2(2))

Question 2

When must CRA requirements be met?

Accepted Answer

CRA requirements enter into force in two stages:

1. From 11 September 2026: Reporting obligations for actively exploited vulnerabilities and serious security incidents apply to all products already on the market (Art. 14).
2. From 11 December 2027: The regulation becomes fully applicable. All products placed on the market from this date onwards must meet the full CRA requirements.

Products placed on the market before 11 December 2027 are generally not subject to the requirements — unless a substantial modification is made.

(Art. 69, Art. 71(2), Art. 14)

Question 3

When is my software product considered "placed on the market" under the CRA?

Accepted Answer

A standalone software product is placed on the market when its manufacturing phase is complete and it is first supplied for distribution or use on the EU market in the course of commercial activity. The manufacturer places a virtually unlimited number of copies on the market simultaneously. Subsequent downloads of the same version constitute "making available" - not new placing on the market.

Practical example: On 1 January 2028, Company A releases version 1.0.0 of its software. On 15 January, version 1.0.1 is released (not a substantial modification). Both versions are considered placed on the market on 1 January 2028.

(Art. 3(21), Art. 3(22), Art. 3(30))

Question 4

When do hardware and software together constitute a single product?

Accepted Answer

Whether software forms part of a product is determined not by delivery method, but by whether the software is necessary for the product to perform its intended functions. Where hardware is designed to operate with specific software, they form a single product with digital elements - even if drivers, apps, or firmware are supplied through different channels.

Practical example: A fitness wearable measures heart rate and activity. The companion smartphone app displays measurements and configures the device. Although downloaded separately from an app store, the wearable and app constitute a single product.

(Art. 3(1))

Question 5

Is source code within the scope of the CRA?

Accepted Answer

Whether code is uncompiled, compiled, or interpreted is irrelevant. Where a manufacturer provides customers with computer code as part of commercial activity, it is placed on the market. However, code shared on public repositories as FOSS, unfinished development code, or sample/demo code in tutorials is not placed on the market.

Practical example: Company A licenses source code to Company B for a customizable internal platform. Company A is responsible for the licensed code. Subsequent adaptations by Company B are Company B's responsibility.

(Art. 3(4))

Question 6

What constitutes a "data connection" under the CRA?

Accepted Answer

A data connection requires a sender deliberately generating digital symbols and a receiver capable of interpreting them as data. Simply switching outputs on/off does not constitute a data connection if not intended to represent information.

Practical example: A basic thermostat using a bimetallic strip has no data connection. A programmable thermostat communicating temperature setpoints via digital bus protocol (e.g., Modbus) to a building management system has a data connection and falls within CRA scope.

(Art. 2(1))

Question 7

How does the CRA apply to complex systems with multiple components?

Accepted Answer

Complex systems of multiple hardware and software elements fall within scope when placed on the market as a single product. The CRA's risk-based approach allows different compliance demonstration methods. Where certain requirements cannot be fully met (e.g., interoperability with legacy protocols), manufacturers must document constraints and implement compensatory measures.

Practical example: An industrial gateway bridges legacy OT networks (Modbus TCP) with modern IT networks. The legacy protocol lacks encryption. The manufacturer documents this and implements network segmentation and access control as compensatory measures.

(Art. 13(2), Art. 13(3), Recital 55)

Question 8

What role does the intended purpose play in the CRA?

Accepted Answer

The intended purpose is one of the central concepts of the CRA and influences virtually every compliance decision:

• Scope: Whether a product falls under the CRA depends on whether its intended purpose or reasonably foreseeable use includes a data connection (Art. 2(1)).
• Risk assessment: The cybersecurity risk assessment must analyse risks taking into account the intended purpose and foreseeable conditions of use (Art. 13(2), Art. 13(3)).
• Product classification: Whether a product is classified as Default, Important, or Critical is determined by its core functionality — i.e., what the product does according to its intended purpose (Art. 7(1)).
• Support period: The manufacturer determines the support period based on the expected product lifetime, which derives from the intended purpose (Art. 13(8)).
• Substantial modification: A change to the intended purpose after placing on the market constitutes a substantial modification and makes the modifier the new manufacturer (Art. 3(30)).
• Data minimisation: The product may only process data that is necessary for its intended purpose (Annex I Part I Section 3(e)).

The intended purpose must be clearly defined in the technical documentation and runs through the entire compliance process.

(Art. 2(1), Art. 3(30), Art. 7(1), Art. 13(2), Art. 13(8), Annex I Part I)

Question 9

Do products designed before the CRA require redesign?

Accepted Answer

Not necessarily. The manufacturer must perform a cybersecurity risk assessment demonstrating that the product already incorporates appropriate security measures. However, the manufacturer must complete the conformity assessment, draw up the EU declaration of conformity, affix CE marking, and comply with vulnerability handling requirements.

Practical example: A microcontroller designed in 2024 demonstrates through risk assessment that it already includes secure boot, encrypted firmware updates, and role-based access control. No redesign needed - only documentation and vulnerability management.

(Art. 13(2), Art. 13(3), Annex I)

Question 10

When is FOSS considered "placed on the market" under CRA?

Accepted Answer

FOSS is placed on the market when supplied in the course of commercial activity. The CRA recognizes that non-monetized FOSS should not be considered commercial. The determination depends on whether the publisher: (a) charges a price, (b) monetizes other services through it, (c) requires personal data processing beyond security purposes, or (d) receives donations functioning as access conditions.

Key criteria: Source code must be openly shared (publicly available) and under a free and open-source license.

(Art. 3(48), Recital 15)

Question 11

When does charging a price make FOSS subject to CRA?

Accepted Answer

Where a FOSS supplier charges a price for its use, they are placing a product on the market and are a manufacturer under CRA. Paid and community versions are different products - the paid version is placed on the market, the community version is not (unless otherwise monetized).

Practical example: A company offers a free community edition and a paid enterprise edition of an open-source database. Only the enterprise edition is placed on the market.

(Art. 3(14), Art. 3(22), Recital 15)

Question 12

When does monetization of other services trigger CRA obligations?

Accepted Answer

A FOSS is placed on the market where it provides a platform through which the publisher monetizes other products or services, or where it requires personal data processing beyond security purposes as a condition for use.

Practical example: A free and open-source VPN allows users to pay for additional servers or dedicated IPs. Since the app monetizes other services through it, it is placed on the market in commercial activity.

(Recital 15)

Question 13

When do support services trigger CRA obligations for FOSS?

Accepted Answer

The mere offering of optional support services around freely available FOSS does not make it placed on the market. The decisive factor is whether FOSS access itself is conditioned on remuneration. Where FOSS can be freely downloaded and users optionally purchase support separately, it is not placed on the market.

Practical example: A free CLI tool with optional consultancy services is not subject to CRA. An operating system with a paid version including support is.

(Recital 15, Recital 18)

Question 14

When do donations trigger CRA obligations for FOSS?

Accepted Answer

FOSS supported through voluntary donations is generally not placed on the market. However, FOSS is placed on the market where donations are de facto equivalent to charging a price - e.g., where access is conditioned on donation or donations are linked to contractual benefits.

Practical example: A FOSS tool with a "Buy me a coffee" link where all updates are freely available is not subject to CRA. If downloadable releases and security updates are available only to donors, this constitutes charging a price.

(Recital 15)

Question 15

How are not-for-profit entities treated under CRA?

Accepted Answer

Where a not-for-profit organization uses all earnings after costs for not-for-profit objectives, the FOSS it publishes is not placed on the market - even if monetized. If the entity meets the steward definition, it is subject to steward obligations under Art. 24.

Practical example: A foundation publishes an open-source browser monetized via search engine partnerships. Since all earnings go to not-for-profit objectives, the browser is not placed on the market.

(Recital 18, Art. 3(14), Art. 24)

Question 16

What is an open-source software steward?

Accepted Answer

A steward is a legal person (not a natural person, not a manufacturer) that systematically provides sustained support for FOSS intended for commercial activities. Stewards are subject to obligations under Art. 24. A legal person can be both a manufacturer for one FOSS and a steward for another.

Practical example: A tech company publishes an open-source ML framework for free and uses it internally. Other companies integrate it. The framework is not placed on the market - the company is its steward.

(Art. 3(14), Art. 24)

Question 17

How does the CRA treat integrated FOSS components (e.g., Embedded Linux)?

Accepted Answer

When a manufacturer integrates FOSS components into their product (e.g., Embedded Linux), they must exercise due diligence per Art. 13(5): identify integrated FOSS components, assess their cybersecurity requirements, and maintain SBOMs (Software Bill of Materials) for all integrated components.

Practical example: An industrial gateway uses a Yocto-based Linux distribution. The Linux kernel is FOSS, not placed on the market by the manufacturer. The manufacturer must still identify and assess all FOSS components.

(Art. 13(5))

Question 18

What is a "substantial modification" under CRA?

Accepted Answer

A substantial modification is a change to a product after placing on the market that either: (a) affects compliance with essential cybersecurity requirements, or (b) changes the intended purpose for which the product was assessed. The person making a substantial modification becomes the manufacturer of the modified product.

(Art. 3(30), Recital 39)

Question 19

Do physical repairs and maintenance constitute substantial modifications?

Accepted Answer

Not necessarily - case-by-case assessment is required. Replacing defective components with more capable ones is not inherently a trigger. Only if the change affects compliance with essential requirements or changes the intended purpose.

Practical example: A server receives newer, more capable RAM as replacement. The server functions better but within its intended use. No substantial modification. If the replacement causes a significant behavioral change not considered in the original risk assessment, it is a substantial modification.

(Art. 3(30), Recital 42)

Question 20

How are spare parts treated under CRA?

Accepted Answer

Identical spare parts (same specifications) are exempt from CRA. Non-identical spare parts are separate products subject to CRA. However, the repair itself does not constitute a substantial modification if the intended purpose remains unchanged.

Practical example: A communication module in an industrial controller fails. An identical replacement is exempt per Art. 2(6). A newer chip with equivalent functionality but different design is a separate CRA product - but the repair itself is still not a substantial modification.

(Art. 2(6))

Question 21

When do software updates constitute substantial modifications?

Accepted Answer

Whether a software update is a substantial modification depends on whether it affects compliance with cybersecurity requirements or changes the intended purpose.

Examples OF substantial modifications:
• Dashboard from read-only to operational control
• Information organization to automated decision-making
• Adding persistent login with local tokens (new risks)
• Removing local encryption in favor of a remote service
• Adding cloud synchronization (new attack surface)

Examples NOT substantial modifications:
• Group chat already planned in original risk assessment
• Activating previously assessed but dormant features
• Security patches and bug fixes
• Hardening existing security configurations
• Updating encryption algorithm within configurable framework

(Art. 3(30), Recital 39)

Question 22

How long must you provide support for your product?

Accepted Answer

At least 5 years - unless the product is expected to be used for less than 5 years. Important: 5 years is not the standard. Products with longer expected useful life must have extended support periods. The end date (month/year) must be specified at the point of purchase.

Practical example: Connected industrial sensors with an expected 10-year lifespan in factory environments must have a 10-year support period. The manufacturer may focus on the latest firmware version but must maintain coordinated disclosure for all versions throughout the entire period.

(Art. 13(8), Art. 13(10), Annex I Part II)

Question 23

What determines if your product is "important" or "critical"?

Accepted Answer

Product classification depends on "core functionality" - the main features without which the product cannot fulfill its intended purpose. If core functionality matches a category in Annex III (important) or Annex IV (critical), the product is classified accordingly. Simply integrating an important/critical component does not automatically make the integrating product important/critical.

Practical example: A smartphone integrates an operating system (important class). However, the smartphone's core functionality is communication and running apps - not OS functionality. The smartphone is not classified as "important" merely because it contains an OS.

(Art. 7(1), Implementing Regulation (EU) 2025/2392)

Question 24

How does conformity assessment work for important and critical products?

Accepted Answer

Standard products: Self-assessment (Module A) always permitted.

Important Class I: Third-party assessment required UNLESS fully relevant harmonized standards have been applied (referenced in OJEU) covering at least core functionality.

Important Class II & Critical: Mandatory third-party assessment.

Exception: FOSS products of any class can follow standard category procedures.

Practical example: An antivirus applying a harmonized standard covering core and additional functionality - self-assessment permitted. A router with harmonized standard for router and firewall functionality - also self-assessment permitted.

(Art. 32, Implementing Regulation (EU) 2025/2392)

Question 25

Can the manufacturer self-declare conformity?

Accepted Answer

This depends on the product category:

• Default products: The manufacturer can carry out an internal control procedure (Module A) and self-declare conformity.
• Important products (Class I): Self-assessment is only permissible if harmonised standards or European cybersecurity certification schemes are applied in full. Otherwise, assessment by a notified body is mandatory.
• Important products (Class II) and critical products: Assessment by a notified body is always mandatory.

Practical example: A smart home plug without security functionality (default) can be self-assessed. A firewall (Class II) always requires a notified body.

(Art. 32, Annex VIII)

Question 26

How should you conduct a cybersecurity risk assessment?

Accepted Answer

Under CRA, residual risk is assessed against a regulatory threshold - not internal risk appetite. The product must provide an appropriate cybersecurity level based on risks, considering the intended purpose and reasonably foreseeable use. Cost considerations or commercial strategy are not relevant. The CRA does not permit transferring cybersecurity risks to users.

(Art. 13(2), Art. 13(3), Annex I Part I)

Question 27

How is due diligence applied to integrated components?

Accepted Answer

The CRA establishes two complementary obligations: (1) cybersecurity risk assessment for the product itself, and (2) due diligence for integrated third-party components. The manufacturer must identify what the product requires of its components, verify that components meet these requirements, and ensure components do not undermine compliance.

Evidence may include component documentation, security specifications, or conformity documentation.

(Art. 13(5), Annex I Part I)

Question 28

Can you use one risk assessment for multiple product variants?

Accepted Answer

Yes. If product variants share the same architecture, security-relevant design, and intended purpose, a single risk assessment can be used. Variations not affecting cybersecurity (color, shape) require no separate assessments. Variations affecting cybersecurity (different interfaces, update mechanisms) must be documented.

(Art. 13(2), Annex I Part I)

Question 29

What qualifies as a Remote Data Processing Service (RDPS)?

Accepted Answer

RDPS is the software component for remote data processing that: (1) is designed and developed by the manufacturer or under their responsibility, and (2) without which the product cannot perform one of its functions. RDPS does not include underlying hardware infrastructure. Internal systems (HR, CRM) are not RDPS.

Key questions: Is the processing remote? Would the product lose a function without it? Was the software developed by the manufacturer? If all yes: RDPS.

(Art. 3(2), Art. 13(2))

Question 30

How do cloud service models relate to RDPS?

Accepted Answer

IaaS: The manufacturer's software on third-party infrastructure - software may be RDPS, infrastructure is not.

PaaS: The manufacturer's application with third-party execution environment - application may be RDPS, platform is not.

SaaS: Fully developed application by third party - NOT RDPS (not designed by manufacturer). Should be treated as third-party component; due diligence required.

(Art. 3(2), Art. 13(2), Art. 13(5))

Question 31

What are practical examples of remote data processing?

Accepted Answer

Banking application: Banking API layer (self-hosted, developed by financial entity) - IS RDPS. Third-party SaaS customer support chat - NOT RDPS.

Smart thermostat: Remote data processing (manufacturer-developed, third-party IaaS) for mobile app - IS RDPS.

e-Reader: Third-party SaaS storage for books - NOT RDPS (not developed by manufacturer).

Industrial robot: Camera feed analysis on remote server (manufacturer-developed) - IS RDPS.

5G mobile network: Only a communication channel - NOT RDPS.

(EU Commission Guidance, Sections 8.3.1-8.3.5)

Question 32

When must you report vulnerabilities and incidents?

Accepted Answer

A manufacturer must report when they have reasonable certainty after initial assessment that a vulnerability is actively exploited or a serious incident has occurred.

Reporting timeline:
• Early warning: within 24 hours
• 72-hour notification: within 72 hours
• Complete report: within 14 days after a corrective measure is available (vulnerabilities) or 1 month after the 72-hour notification (incidents)

(Art. 14(1), Art. 14(3))

Question 33

What are upstream vulnerability reporting obligations?

Accepted Answer

Manufacturers must report vulnerabilities in integrated components to the component manufacturer or maintainer (upstream reporting, Art. 13(6)). This applies only to the integrated component version. Manufacturers must also share security fixes in machine-readable format compatible with the component license. There is no obligation that fixes be accepted by the maintainer.

(Art. 13(6))

Question 34

What are "known exploitable vulnerabilities"?

Accepted Answer

An exploitable vulnerability has the potential to be effectively exploited by an adversary under practical conditions. Products must be placed on the market without known exploitable vulnerabilities.

A vulnerability is "known" when:
• Listed in public databases (CVE, European Vulnerability Database)
• Disclosed to the manufacturer through coordinated disclosure
• Publicly reported in reliable media

(Art. 3(37), Annex I Part II)

Question 35

Who is affected by the CRA (personal scope)?

Accepted Answer

The CRA addresses three groups of economic operators:

• Manufacturers: Bear primary responsibility for the design, development, production, and conformity of products. They must comply with essential cybersecurity requirements.
• Importers: Must ensure only compliant products are placed on the EU market. They verify whether the manufacturer has conducted the conformity assessment procedure.
• Distributors: Must verify with due diligence that CE marking and documentation are present before making products available on the market.

(Art. 13, Art. 19, Art. 20, Art. 21)

Question 36

What are the key obligations of manufacturers?

Accepted Answer

Manufacturers must:

• Conduct and document a cybersecurity risk assessment (Art. 13(2))
• Design and develop the product in accordance with essential requirements in Annex I (security by design)
• Create technical documentation including an SBOM (Software Bill of Materials)
• Carry out the conformity assessment procedure (self-assessment or third-party audit depending on product category)
• Draw up the EU declaration of conformity and affix CE marking
• Actively manage vulnerabilities and provide security updates (minimum 5 years)
• Report actively exploited vulnerabilities to ENISA within 24 hours

(Art. 13, Annex I, Annex VII)

Question 37

What are the obligations of importers?

Accepted Answer

Before placing products on the market, importers must ensure that:

• The manufacturer has carried out the conformity assessment procedure
• Technical documentation has been drawn up
• The product bears the CE marking
• The EU declaration of conformity is available
• The importer's contact details are indicated on the product or packaging

Where an importer suspects non-compliance, they shall not place the product on the market and must inform the manufacturer and market surveillance authorities.

(Art. 19)

Question 38

What are the obligations of distributors?

Accepted Answer

Distributors must verify with due diligence:

• Presence of the CE marking
• Availability of the EU declaration of conformity
• Correct identification of manufacturer and importer
• Compliance with storage and transport conditions

Where a distributor suspects non-compliance, they shall not make the product available and must inform the market surveillance authority. Distributors who place a product on the market under their own name are considered manufacturers.

(Art. 20, Art. 21)

Question 39

Does the CRA apply at the time of component procurement or only when placing the product on the market?

Accepted Answer

What matters is the point in time when the finished product is first placed on the market (Art. 3(21)) – not when individual components were purchased. If components with digital elements are procured today for integration into products placed on the market only after 11 December 2027, those products must be CRA-compliant at the time of market introduction.

Important: CRA requirements should be integrated into the procurement process early. Suppliers should be required to provide the necessary documentation – vulnerability handling information (Annex I Part II), security updates, and Software Bills of Materials (SBOMs). If a supplier cannot provide this evidence, compliance must be verified independently, which significantly increases the effort.

(Art. 13(1), Art. 71(2), Annex I Part II)

Question 40

What due diligence obligations apply when integrating non-CRA-compliant third-party components?

Accepted Answer

Where components are integrated for which the supplier cannot provide CRA compliance evidence, the verification responsibility shifts entirely to the manufacturer of the final product. The following rules apply:

• Overall responsibility: The manufacturer bears sole responsibility for ensuring that the final product as a whole meets the essential cybersecurity requirements (Art. 13(1)).
• Due diligence: When integrating third-party components, due diligence must be exercised. As explained in Recital 35, this applies in particular to components produced before the regulation’s date of application (Art. 13(5)).
• Documentation: The results of these assessments must be included in the technical documentation of the final product (Annex VII, point 3).
• Reporting obligation: Where a vulnerability is discovered in a third-party component, the manufacturer is required to report it to the original manufacturer or the open-source community and to remediate it in the own product (Art. 13(6)).

(Art. 13(1), Art. 13(5), Art. 13(6), Recital 35, Annex VII)

Question 41

What product exemptions exist under the CRA?

Accepted Answer

The following products are exempt from the CRA:

• Medical devices (Regulation (EU) 2017/745 and 2017/746)
• Motor vehicles (Regulation (EU) 2019/2144) and L-category vehicles (168/2013)
• Aviation products (Regulation (EU) 2018/1139)
• Marine equipment (Directive 2014/90/EU)
• Products developed exclusively for national security or defence purposes
• Products intended for processing classified information

Important: Generic components that can be used in both exempted and non-exempted products still fall under the CRA.

(Art. 2(2)-(6))

Question 42

Are there exceptions for existing products (legacy products)?

Accepted Answer

Products placed on the market before 11 December 2027 are generally not subject to CRA requirements - provided no substantial modification is made.

However: From 11 September 2026, reporting obligations (Art. 14) apply to ALL products already on the market. Manufacturers must therefore be able to report actively exploited vulnerabilities within 24 hours by that date at the latest.

A software update constituting a substantial modification turns the product into a new product under the CRA.

(Art. 69, Art. 14, Recital 45)

Question 43

Does the CRA affect existing corporate IT?

Accepted Answer

The CRA applies to products with digital elements placed on the market in the course of commercial activity. Internally developed software used exclusively for the company's own operations and not supplied to third parties does not fall under the CRA.

However, if a company provides software to subsidiaries, partners, or customers - even free of charge as part of a business relationship - this may constitute placing on the market.

Internal IT infrastructure (servers, networks) as such does not fall under the CRA, but products with digital elements deployed on them do, if they were placed on the market.

(Art. 3(21), Art. 3(22), Recital 15)

Question 44

Does the CRA apply to standalone software and mobile apps?

Accepted Answer

Yes. The CRA explicitly applies to standalone software placed on the market as a product with digital elements. This includes:

• Desktop applications
• Mobile apps
• Firmware
• Operating systems

Pure SaaS solutions (without downloadable components) do not fall directly under the CRA but may be affected as Remote Data Processing Services (RDPS) of a product.

Software as a Medical Device (SaMD) is subject to the Medical Devices Regulation and exempt from the CRA.

(Art. 3(1), Art. 3(4), Recital 12)

Question 45

What are the consequences of CRA non-compliance?

Accepted Answer

The CRA provides for graduated sanctions:

• Violation of essential requirements (Annex I & II): up to EUR 15 million or 2.5% of global annual turnover
• Violation of other obligations: up to EUR 10 million or 2% of turnover
• False/incomplete information to authorities: up to EUR 5 million or 1% of turnover

Additionally, market surveillance authorities may:
• Order product recalls
• Prohibit placing on the market
• Require destruction of non-compliant products

(Art. 64, Art. 54-58)

Question 46

What should companies do now?

Accepted Answer

Recommended steps for CRA preparation:

1. Inventory: Identify all products with digital elements in your portfolio
2. Product classification: Determine whether your products are classified as Default, Important (Class I/II), or Critical
3. Gap analysis: Compare your current state with CRA requirements (Annex I)
4. SBOM process: Establish automated software bill of materials generation (CycloneDX/SPDX)
5. Vulnerability management: Implement a process for continuous vulnerability monitoring
6. Reporting channels: Prepare the 24h/72h reporting infrastructure (by September 2026 at the latest)
7. Supplier contracts: Adapt contracts to ensure CRA requirements along the supply chain
8. Documentation: Begin technical documentation per Annex VII

Kunnus supports you in all these steps with an all-in-one platform.

Question 47

How does the CRA fit within the EU regulatory framework (NIS-2, DORA, etc.)?

Accepted Answer

The CRA complements existing EU cybersecurity legislation:

• NIS-2 Directive (2022/2555): Regulates cybersecurity of operators of essential services and infrastructures. The CRA focuses on the products themselves. NIS-2 obligated companies benefit from CRA-compliant products.
• DORA (2022/2554): Regulates digital operational resilience in the financial sector. CRA-compliant products facilitate DORA compliance for financial undertakings.
• Machinery Regulation (2023/1230): Contains its own cybersecurity requirements. Where requirements overlap: meeting CRA requirements also satisfies the Machinery Regulation.
• Radio Equipment Directive (2014/53/EU): CRA conformity replaces the delegated acts on cybersecurity (Art. 3(3)(d)-(f)).

The CRA follows the principle of 'comply once, comply everywhere' - CRA compliance largely covers cybersecurity requirements of other sectoral legislation.

(Art. 8-11, Recitals 24-32)

Question 48

Is the CRA just another bureaucratic documentation exercise?

Accepted Answer

No. Unlike pure management system approaches (e.g., an ISMS per ISO 27001, which can look excellent on paper but be ineffective in practice), the CRA requires actual security capabilities in the product. Manufacturers must demonstrate concrete measures: free security patches, public security advisories, incident reporting, and a coordinated disclosure policy. Documentation alone is not enough — customers, competitors, and security researchers can all file non-compliance complaints, and market surveillance evaluates actual product security.

(Art. 13, Annex I Part II)

Question 49

Will the CRA make products more expensive?

Accepted Answer

The CRA levels the playing field. Until now, manufacturers could offer insecure products at lower prices because cybersecurity was optional. The CRA makes security the default and removes the cheaper, insecure option from the market. While the transition requires short-term investment, manufacturers and customers benefit long-term: the follow-on costs of security incidents — product recalls, reputational damage, liability claims — decrease dramatically.

(Recitals 2, 10)

Question 50

Is the CRA only about encryption?

Accepted Answer

No. The CRA defines 13 essential cybersecurity requirements in Annex I Part I. Encryption (confidentiality) is just one of them. Others include: secure default configuration, authentication and access control, data and software integrity protection, data minimisation, availability and resilience, attack surface reduction and hardening, logging and monitoring. On top of that, Part II covers vulnerability handling requirements (SBOM, coordinated disclosure, free patches).

(Annex I Part I, Annex I Part II)

Question 51

Does the CRA only apply to EU manufacturers?

Accepted Answer

No. The CRA applies to all products with digital elements placed on the EU single market — regardless of the manufacturer's location. US, Asian, and all other non-EU manufacturers must meet the requirements if they want to sell in the EU. In practice, the CRA functions as a global standard: most international manufacturers will not maintain separate, less secure product lines for non-EU markets.

(Art. 2(1), Recital 15)

Question 52

Do all 13 requirements apply to every product?

Accepted Answer

No. The CRA follows a risk-based approach. Manufacturers conduct a cybersecurity risk assessment and determine which of the 13 essential requirements are applicable to their specific product. A simple temperature sensor has different requirements than a router or a password manager. The risk assessment must be documented and updated throughout the entire support period.

(Art. 13(2), Art. 13(3))

Question 53

What exactly does vulnerability handling under the CRA entail?

Accepted Answer

The CRA requires a complete vulnerability lifecycle in Annex I Part II:

• Identification: Systematically identify and document all vulnerabilities, including in third-party components
• Testing: Regular and effective security testing of the product
• Remediation: Provide security updates without undue delay
• Disclosure: Coordinated vulnerability disclosure with a clear policy
• Communication: Public security advisories for remediated vulnerabilities
• Transparency: Maintain an SBOM in machine-readable format

This process must be maintained throughout the entire support period (minimum 5 years).

(Annex I Part II, Art. 13(8))

Question 54

What are the CRA requirements for the SBOM?

Accepted Answer

The CRA requires a Software Bill of Materials as part of the technical documentation:

• Format: Machine-readable, in a commonly used standard (e.g., CycloneDX, SPDX, or SWID)
• Scope: At least the top-level dependencies of the product
• Publication: Not required — but the SBOM must be available to market surveillance authorities upon request
• Currency: Must be updated when changes are made to the product

The SBOM is not an end in itself but enables systematic vulnerability identification across the entire supply chain.

(Annex VII Section 2(b), Recital 78)

Question 55

How must security updates be delivered?

Accepted Answer

The CRA sets clear requirements for the delivery of security updates:

• Speed: Without undue delay after becoming aware of a vulnerability
• Channel: Via a secure and reliable distribution channel
• Cost: Free of charge for the user
• Automation: Offered as automatic updates with a user-friendly opt-out mechanism
• Accompanying information: Each update must be accompanied by a public security advisory
• Duration: For the entire support period (minimum 5 years from placing on the market)

Security updates must be deliverable separately from functional updates.

(Annex I Part I Section 2(c), Annex I Part II Section 8)

Question 56

What does Coordinated Disclosure mean under the CRA?

Accepted Answer

The CRA obliges every manufacturer to establish a Coordinated Vulnerability Disclosure (CVD) policy. Specifically, this means:

• A publicly accessible contact point for vulnerability reports
• A documented process for handling reported vulnerabilities
• Cooperation with the reporting researcher/discoverer
• Timely remediation and coordinated publication
• Entry into the European Vulnerability Database (after remediation or 90 days after report)

Companies already implementing ISO/IEC 29147 (Vulnerability Disclosure) or ISO/IEC 30111 (Vulnerability Handling) have a strong starting point.

(Art. 13(6), Annex I Part II Sections 5-6, Art. 16)

Question 57

What must be included in the technical documentation under the CRA?

Accepted Answer

The technical documentation must contain all information required to demonstrate CRA conformity, as specified in Annex VII:

• General product description: Intended purpose, versions, security-relevant hardware components
• Software Bill of Materials (SBOM): In machine-readable format, at least top-level dependencies
• Cybersecurity risk assessment: Full documentation of identified risks and measures taken
• Vulnerability handling information: Processes, contact point, coordinated disclosure policy
• Test reports: Evidence that essential requirements (Annex I) are met
• EU declaration of conformity: Declaration that all applicable requirements are complied with

The documentation must be retained for the support period plus 10 years and made available to market surveillance authorities upon request.

(Annex VII, Art. 31, Art. 13(12))

Question 58

How does the CRA interact with vehicle regulations?

Accepted Answer

Products subject to Regulation (EU) 2019/2144 (motor vehicles) or Regulation (EU) No. 168/2013 (L-category vehicles) are exempt from CRA. Components designed solely for integration into such vehicles are also exempt. However, generic components that can be integrated into different product types are subject to CRA.

(Art. 2(5), Art. 2(6))

Question 59

How do existing EU type approval certificates affect CRA?

Accepted Answer

EU type approval certificates issued under other EU harmonization legislation regarding cybersecurity (e.g., Radio Equipment Directive, Machinery Regulation) remain valid until 11 June 2028. Manufacturers may rely on these for already covered risks but must still conduct a comprehensive CRA risk assessment and address additional risks.

(Art. 13(2), Art. 13(3), Recital 66)

Cyber Resilience Act FAQ

At a Glance: Essential CRA Facts

Scope & Placing on the Market

Free and Open-Source Software (FOSS)

Substantial Modifications & Spare Parts

Support Period

Product Classification & Conformity Assessment

Cybersecurity Risk Assessment

Remote Data Processing Services (RDPS) & Cloud

Vulnerability Reporting & Incident Handling

Obligations of Economic Operators

Exemptions & Existing Products

Consequences & Recommendations

Common Misconceptions

Vulnerability Handling in Detail

Interaction with Other Legislation

Legal References

Ready for CRA Compliance?