EU Cyber Resilience Act — FAQ for Turkish Manufacturers

Yes — if you place products with digital elements on the EU market, CRA applies to you regardless of where your company is headquartered. "Placing on the market" means making a product available to EU customers for the first time, including through distribution partners, online stores, or resellers operating in the EU.

There is no exemption for non-EU origin. EU Customs Union membership eliminates tariff barriers on goods but does not grant regulatory equivalence — CRA is a product safety regulation, and it follows the product, not the manufacturer's location.

CRA covers any product that contains software or firmware and can connect to a network or another device. For Turkish manufacturers this includes:

• Industrial equipment and automation systems with network connectivity
• IoT devices and connected hardware
• Networking and communications products
• Consumer electronics with connectivity
• Software products sold or licensed to EU customers

Excluded: products covered by sector-specific regulations with equivalent requirements (some medical devices, aviation components, motor vehicles under type-approval).

If you export hardware or software to the EU and it has any network capability, assume it is in scope until proven otherwise.

No. Under CRA, the manufacturer bears primary responsibility for cybersecurity requirements regardless of who handles distribution or CE marking administration. Your EU distributor takes on limited obligations (due diligence checks, not technical compliance) but cannot substitute for the manufacturer's obligations under Articles 13–15.

If your products are non-compliant, market surveillance authorities pursue the manufacturer. Your distributor will be required to cooperate in identifying you.

No — but the Customs Union gives you real practical advantages. CRA is a product safety regulation, not a trade measure. It applies to all products placed on the EU market regardless of country of origin. Customs Union membership does not grant CRA exemption.

However, Turkish manufacturers are better positioned than most non-EU manufacturers to navigate CRA compliance:

• CE marking familiarity: You already understand the conformity assessment process (technical documentation, Declaration of Conformity, CE mark). CRA adds a cybersecurity layer on top of that familiar structure.
• EU market access workflows: Your logistics, distribution, and administrative processes for the EU market are already established. CRA compliance slots into existing product release processes.
• EU notified body relationships: Turkish manufacturers in regulated sectors often have existing relationships with EU notified bodies — an advantage when CRA requires third-party assessment for higher-risk products.

Frame CRA as an extension of the regulatory compliance work you are already doing for EU market access — not a new system to build from scratch.

It depends on your relationship with the EU market:

• If you develop software placed on the EU market as a standalone product (sold, licensed, or distributed to EU end users): yes, CRA applies to you directly as the manufacturer.
• If you develop software as work-for-hire for an EU manufacturer: CRA obligations sit with the manufacturer, not you. However, they will contractually require you to follow CRA-compatible security practices — SBOM generation, secure development lifecycle, vulnerability disclosure — because their compliance depends on it.

Either way, understanding CRA is now a commercial requirement for software companies serving the EU market. Turkish software companies are increasingly receiving CRA-related requirements from EU clients. We help you understand your obligations and build the technical practices that satisfy them.

• September 2026: Vulnerability reporting obligations take effect — 24-hour reporting to ENISA
• December 2027: Full CRA enforcement — all products placed on the EU market must comply

Products already on the market before December 2027 receive a transitional grace period. Products placed on the market for the first time after December 2027 must comply from day one.

The 15-month gap between the two deadlines is significant: your security processes must be operational before your full technical documentation and conformity assessments are complete.

Yes. EU market surveillance authorities have broad enforcement powers:

• Prohibition on placing the product on the market
• Mandatory withdrawal from the EU market
• Mandatory product recall from end users
• Financial penalties up to €15 million or 2.5% of global annual turnover (whichever is higher)

Enforcement is coordinated at EU level — a decision in one member state applies across all 27.

Products placed on the EU market before December 2027 benefit from transitional provisions. However:

• If you continue selling the same product after December 2027, it must comply
• If you release a significant software or firmware update, you may trigger full compliance obligations
• Vulnerability reporting obligations (September 2026) apply to products already in use

We recommend starting the compliance assessment now for your highest-volume EU products.

An SBOM (Software Bill of Materials) is a complete inventory of every software component, library, and dependency in your product — including open-source components, third-party libraries, and their versions.

CRA requires manufacturers to:

• Generate and maintain an SBOM per product
• Track known vulnerabilities in each component
• Disclose the SBOM to regulators on request
• Use it as the operational foundation for vulnerability management

SBOMs must be updated with each release. Most manufacturers have never systematically tracked their software components. We start every engagement with an SBOM audit.

ISO 27001 covers organisational information security management — it does not cover product-level cybersecurity requirements.

CRA requires cybersecurity to be built into the product itself:

• SBOM generation at each product release
• Vulnerability management built into firmware and software
• ENISA reporting obligations (24h/72h/14-day timelines)
• CE marking under CRA
• EU Declaration of Conformity

None of these are within ISO 27001 scope.

For companies with BTK (Bilgi Teknolojileri ve İletişim Kurumu) cybersecurity obligations, there is some overlap with CRA for connected products in telecoms and ICT. TSE standards provide a local certification frame that is familiar but not equivalent to CRA conformity assessment requirements.

Think of ISO 27001 as your internal security management system — it tells the market your organisation manages security well. CRA is the external product certification layer — it tells the market your products are secure.

We run a structured gap analysis to map exactly what your existing certifications cover and what CRA adds on top.

CRA compliance is not a one-time audit — it requires ongoing processes embedded in your development workflow:

• SBOM generation: automated at build time (CycloneDX or SPDX format), integrated into CI/CD
• Dependency vulnerability scanning: continuous monitoring against NVD/GHSA/ENISA EUVD
• Vulnerability triage and response: documented process with defined timelines, linked to SBOM
• Security testing in CI: SAST, dependency audits, container scanning as pipeline gates
• Release documentation: automated changelogs linked to CVE remediation records

We design and implement these workflows directly in GitHub Actions, GitLab CI, Jenkins, or similar systems. We do not hand you a checklist.

CRA Article 14 — timelines are non-negotiable and apply from the moment you become aware of active exploitation:

• 24 hours: Notify ENISA of any actively exploited vulnerability in your product
• 72 hours: Initial vulnerability report with preliminary assessment
• 14 days: Detailed technical report

Most manufacturers have no vulnerability disclosure process mapped to these timelines. This is the highest-risk gap: September 2026 enforcement arrives before full CRA enforcement in December 2027.

We help you design a CVD (Coordinated Vulnerability Disclosure) policy, set up the internal triage process, and prepare your team to operate within these timelines.

A typical engagement works in four stages:

1. Assessment: Audit current products, development process, and existing certifications (ISO 27001, CE marking documentation, BTK compliance records). Map against CRA requirements. Produce written gap analysis with priorities.
2. Workflow integration: Design and implement SBOM generation, vulnerability tracking, and CI/CD pipeline changes — turning CRA into an operational workflow, not a documentation exercise.
3. Documentation and legal: Prepare the technical documentation CRA requires, work alongside your legal team (or connect you with EU lawyers we work with), handle translation of technical documents for EU market requirements.
4. Ongoing support: Vulnerability monitoring, annual reviews, support for new product releases, help responding to market surveillance inquiries.

We work remotely. Timezone-friendly scheduling for Turkish engagements.

KVKK (Kişisel Verilerin Korunması Kanunu) and CRA are different in scope: KVKK covers data protection and personal data processing, while CRA covers product cybersecurity. They are not the same regulation.

However, they share the same EU regulatory DNA:

• Documented processes and defined obligations
• Enforcement with real penalties
• The need to demonstrate compliance rather than just claim it
• Ongoing obligations, not one-time certification

If your company navigated KVKK successfully, you already have the compliance infrastructure and mindset that CRA requires. You understand how to set up documented processes, assign responsibilities, and operate under a regulatory framework with teeth.

The technical content is different — product security, SBOM generation, vulnerability management — but the compliance management approach transfers directly. Turkish companies with strong KVKK programmes typically adapt to CRA faster than counterparts in markets without comparable regulatory experience.

CRA compliance has two sides: technical and legal. Most companies need both.

We work alongside EU-qualified lawyers who specialise in product safety and CE marking. We handle the technical translation (turning engineering reality into the documentation lawyers need) and coordinate between both sides so you are not managing two separate tracks.

CRA technical documentation must be available in the official language(s) of each EU member state where your product is sold. We handle translation of technical documentation, Declaration of Conformity, and user-facing security information.

We also help you appoint an EU Authorised Representative if you have no EU establishment — a CRA requirement for all non-EU manufacturers, including Turkish companies.

CRA does not replace CE marking requirements — it adds mandatory cybersecurity obligations on top of them.

Your existing CE marking familiarity is a direct practical advantage for the CRA conformity assessment workflow: the structure (technical documentation, Declaration of Conformity, CE mark) is the same. CRA adds a cybersecurity risk assessment and ongoing obligations; it does not replace the familiar conformity assessment process.

• Radio Equipment Directive (RED): Cybersecurity requirements under Article 3.3(d)(e)(f) effective August 2025. For wireless products, RED and CRA overlap significantly — a single technical assessment can satisfy both.
• Machinery Regulation: New regulation (effective January 2027) includes cybersecurity requirements for safety-related control functions. IEC 62443 is referenced. CRA applies to software components separately.

If your products fall under multiple EU regulations, we map the overlap at the start of the engagement to avoid duplicating compliance work.