Cyber Resilience Act (CRA) Compliance Consulting

What Is the CRA (Cyber Resilience Act)?

The Cyber Resilience Act (CRA) is the European Union’s first horizontal cybersecurity regulation for products with digital elements, covering both hardware and software. Regulation (EU) 2024/2847, which entered into force on 10 December 2024, makes security mandatory across the entire planning, design, development and maintenance lifecycle of products and extends these obligations to every link in the value chain.

The core principle of the CRA is that digital products must be developed according to security by design, must not be placed on the market with known exploitable vulnerabilities, and must be supported with security updates throughout their expected lifetime — as a rule, at least five years. Conformity is shown by the CE marking and supervised by market surveillance authorities.

The CRA covers almost every product that can connect to the internet directly or indirectly: IoT devices, smart home appliances and white goods, smart TVs and consumer electronics, network equipment, commercial software and mobile apps, automotive electronics components and their remote data processing solutions (including cloud back-ends under the manufacturer’s responsibility). The regulation does not replace existing CE directives; it adds a cybersecurity layer on top of them.

Who Is in Scope?

The most important feature of the CRA is that its scope depends on whether a product is made available on the EU market, not on where it is manufactured. This gives the regulation global reach: any company selling products in the EU must comply, wherever it is headquartered. The Regulation allocates obligations according to the role of each economic operator.

Out of Scope

The CRA excludes products covered by their own sectoral regimes: medical devices (MDR/IVDR), motor vehicles subject to type-approval legislation, marine equipment, civil aviation products and products developed exclusively for national security or defence purposes. Spare parts made solely to replace identical components and open-source software not supplied in the course of a commercial activity are also out of scope; a lighter regime applies to commercialised open source. Being out of scope does not remove supply-chain pressure: a supplier selling components to a vehicle manufacturer may still have to provide similar evidence contractually because of the buyer’s own regulatory obligations.

What the CRA Means for Exporters in Türkiye

Organisations in Türkiye encounter the CRA through two separate channels.

Direct Export Obligations

Every Turkish manufacturer selling products with digital elements on the EU market is a manufacturer under the CRA. TSE, BTK and USOM processes relate to Türkiye’s domestic market and national cybersecurity regime; the CRA, by contrast, is a separate EU regulation added to the CE conformity of products placed on the EU market. Your existing test reports and technical documents can be used as evidence, but ENISA reporting, the SBOM and the CRA Annex VII technical file must be managed separately.

Supply-Chain Obligations

EU buyers are making CRA compliance a contractual requirement in 2026–2027. If you supply components or software to an EU manufacturer, you will be expected to provide your SBOM data and vulnerability information in time for your buyer to meet its own CRA obligations. Being unprepared creates the risk of lost orders and removal from the supply chain even before any fine.

Customs Union and National Alignment

Under the Customs Union, Türkiye is required to transpose EU technical legislation into national law. Coordinated by the Ministry of Trade’s Directorate General for Product Safety and Inspection, a TAIEX workshop on Türkiye’s alignment with the CRA was held on 13–14 November 2025 with experts from Italy, Spain and Romania. Once alignment is complete, digital products placed on Türkiye’s domestic market will also fall within scope — a process similar to how KVKK followed the GDPR.

Key Timeline and Penalties

The CRA entered into force on 10 December 2024 and its provisions apply in stages. Three operationally binding dates are clear:

• 11 June 2026 Chapter IV on the notification of conformity assessment bodies started to apply. The notified body ecosystem is being established.
• 11 September 2026 The Article 14 reporting obligation started to apply. The 24-hour / 72-hour / final report deadlines for actively exploited vulnerabilities and severe incidents are in force. Legacy products on the EU market are included.
• 11 December 2027 All essential obligations apply in full: security by design, vulnerability management, SBOM, technical file, conformity assessment and CE marking.

Penalties

In addition to fines, market surveillance authorities may require products to be recalled or withdrawn from the market; in practice, the fastest-acting sanction is the EU buyer’s contractual audit.

Article 14: Incident and Vulnerability Reporting Obligations

Article 14 is the first CRA provision to apply and the one that creates the most concrete workflow. When a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of its product, it must meet the following deadlines.

Reporting goes through a single entry point: notifications are submitted via ENISA’s Single Reporting Platform to the coordinator CSIRT of the relevant Member State and shared simultaneously with ENISA. For manufacturers not established in the EU, the recipient is, as a rule, the CSIRT of the Member State where the authorised representative is located — which makes the choice of authorised representative an operational decision. The 24-hour window cannot be met without a process set up in advance. Nesil Teknoloji sets up this process and supports it with an on-call reporting service when needed. For the setup scope, SRP registration and reporting drills, see our CRA Article 14 Reporting Obligations page.

Annex I: Essential Cybersecurity Requirements

CRA Annex I defines the essential requirements a product must meet under two headings: product properties and vulnerability handling. The main requirements are:

• Placing on the market without known exploitable vulnerabilities, with a secure-by-default configuration.
• Protection against unauthorised access, including authentication and access management.
• Confidentiality and integrity of transmitted and stored data, including appropriate mechanisms such as encryption.
• Minimising the attack surface and limiting the impact of incidents.
• Recording and monitoring of security-relevant events.
• A secure and timely update mechanism; automatic security updates where possible.
• Identifying and documenting vulnerabilities and components (including the SBOM).
• A coordinated vulnerability disclosure (CVD) policy and a vulnerability reporting channel.
• Security support throughout the expected product lifetime — as a rule, at least five years.

Product Classification and Conformity Routes

Not every product follows the same conformity route. The CRA groups products into categories by risk level, and the category determines the conformity assessment procedure to follow.

The technical descriptions of the important and critical categories have been clarified by Commission Implementing Regulation (EU) 2025/2392. The category a product falls into is determined using the lists in CRA Annex III and Annex IV. The route decision, its rationale and the supporting standard/certification evidence should be kept in the technical file. For the route decision and coordination with notified bodies and the EU authorised representative, see our CRA Conformity Assessment and Notified Body Preparation page.

SBOM and Vulnerability Management

The CRA requires a software bill of materials (SBOM) in a machine-readable format covering at least the top-level dependencies. The SBOM is also a technical prerequisite for the reporting obligation: you can only assess whether a vulnerability affects your product if you know which components it contains.

Processes to Put in Place

• Integrating SBOM generation and maintenance into the build pipeline.
• Checking vulnerability databases (including CVE) before every release, plus continuous monitoring.
• Static and dynamic application security testing (SAST/DAST) in the build pipeline.
• A vulnerability reporting channel, security.txt and a coordinated vulnerability disclosure (CVD) policy.
• PSIRT (product security incident response team) operations and a reporting deadline timer.
• Update distribution and tracking of support-period commitments.

Technical File, EU Declaration of Conformity and CE

By the full-application date, a CRA Annex VII technical file must be ready for every product. Your existing CE process already covers part of this; the missing piece is cybersecurity evidence.

• A general description of the product and its intended purpose; security-relevant software versions.
• A description of design, development and production; a description of the system architecture and the SBOM.
• A cybersecurity risk assessment showing how the Annex I essential requirements are met.
• Harmonised standards applied and conformity assessment evidence.
• User instructions and security information.
• The EU Declaration of Conformity and the CE marking.

The new Product Liability Directive, which treats software as a “product”, also strengthens the legal dimension of the technical file and contractual framework. Nesil Teknoloji carries out technical file work together with its technical and legal teams and, where required, coordinates with notified bodies and authorised representatives in the EU.

Service Scope and Deliverables

Our CRA consulting goes beyond preparing documents; it combines product security testing, process implementation and ongoing compliance management.

Methodology

A typical CRA compliance project runs in six phases. Durations vary with product complexity, number of products and current maturity.

Managing CRA Together with Law No. 7545, ISO 27001 and KVKK

The CRA works best when positioned alongside a company’s other obligations rather than on its own. Your existing certifications feed the CRA evidence base.

CRA and Turkish Cybersecurity Law No. 7545

Law No. 7545 concerns Türkiye’s domestic market and national cybersecurity regime; cybersecurity audit authority passed to the Cybersecurity Directorate (Siber Güvenlik Başkanlığı) on 18 September 2025, and the full compliance date was set as 19 March 2026. The CRA, by contrast, concerns products placed on the EU market. The two regimes overlap on shared technical foundations such as product penetration testing and vulnerability management; a single technical engagement can be designed to serve both obligations.

CRA and ISO/IEC 27001:2022

ISO/IEC 27001 provides management system certification at the organisational level, whereas the CRA introduces cybersecurity conformity at the product level. Your existing ISO 27001 processes (risk management, secure development, incident response) support a significant part of the CRA Annex I requirements and can be used as evidence. For control implementation, technical control libraries such as the NIST SP 800 series can serve as a reference for making Annex I requirements concrete.

CRA and KVKK

KVKK (Türkiye’s Personal Data Protection Law) focuses on personal data protection, while the CRA focuses on product cybersecurity. The two regimes intersect where personal data is processed on the product; measures such as data inventory, encryption and access control can be managed through a single evidence set when handled together.

Sector Applications

White Goods and Consumer Electronics

For manufacturers of smart TVs, smart home appliances and connected white goods, the mobile app, update server and cloud back-end are assessed as a whole. If all three are under the manufacturer’s responsibility, they are part of the product and CRA obligations apply to the entire package.

IoT and Smart Devices

Connected cameras, sensors and smart devices are tested against ETSI EN 303 645 and EN 18031. Since 1 August 2025, the RED Delegated Act has made cybersecurity a CE requirement for internet-connected radio equipment; the CRA builds on this.

Software and SaaS

Commercial software is directly in scope. Remote data processing components (cloud back-ends under the manufacturer’s responsibility) are assessed together with the product; third-party analytics SaaS, however, is not considered part of the product and carries its own NIS2 obligations.

Automotive Electronics

Vehicles subject to type approval are outside CRA scope; however, because of aftermarket components and supply-chain evidence requests, Tier 1/2 suppliers with UN R155 and ISO/SAE 21434 experience are the group that adapts fastest to CRA readiness. An evidence base is built by cross-mapping existing processes to CRA Annex I.

Importers and Distributors

For companies bringing digital products into or distributing them in the EU, we set up processes to verify manufacturer conformity, check the CE marking and EU Declaration of Conformity, and keep conformity records.

Cost Advantage Through Government Support

Testing and certification costs required for CRA compliance may be eligible under the Turkish Ministry of Trade’s Market Entry Certification Support programme. Costs of test/analysis reports obtained from accredited institutions that are mandatory for, or give an advantage in, market entry are supported at 50%, within an annual cap per company.

Frequently Asked Questions

Official Sources

• Regulation (EU) 2024/2847 — Official Text (EUR-Lex)
• European Commission — Cyber Resilience Act
• CRA — Article 14 Reporting Obligations and the Single Reporting Platform
• Implementing Regulation (EU) 2025/2392 — Technical Descriptions of Important and Critical Products
• Republic of Türkiye Ministry of Trade — Directorate General for Product Safety and Inspection
• ENISA — European Union Agency for Cybersecurity