EU regulation · Exporters
The CRA and the AI Act: what an Israeli exporter has to do
Both regulations apply according to the market a product is sold into, not according to where the company is registered. For an Israeli manufacturer selling into Europe, this is a European requirement handled from Israel.
Part of it is already in force, and the next major date is December 2027 - for both.
Why it reaches you
Both regulations rest on the same principle: what matters is the market, not the address.
The Cyber Resilience Act applies to any economic operator that places a product with digital elements on the EU market, irrespective of where it is established. The definition is broad and covers hardware and software alike. A distributor or importer can also become the manufacturer, if it markets the product under its own name or substantially modifies it.
The AI Act applies to providers that place a system on the EU market or put it into service there, and also to providers and deployers outside the Union where the output of the system is used inside the Union. An Israeli company can therefore be in scope with no European entity and without selling the system in Europe at all, if its output lands there.
What this means in practice
The question is not whether you have a European company. It is which products are sold there, and where the output of your AI systems arrives. Both questions are answered by mapping, and mapping is always the first step.
Cyber Resilience Act: what already applies
This is the common mistake. Many treat the CRA as something that begins in 2027. Part of it already applies.
| Date | What applies |
|---|---|
| 11 September 2026 | Reporting obligations. A manufacturer must report actively exploited vulnerabilities and severe security incidents through the dedicated platform operated by ENISA. The duty covers products already on the market |
| 11 December 2027 | The main obligations: product security requirements, vulnerability handling across the lifecycle, technical documentation, conformity assessment and CE marking |
The reporting clock is staged and fast: early warning within 24 hours, full notification within 72 hours, and a final report within 14 days for an actively exploited vulnerability or one month for a severe incident.
This is where organizations discover that the gap is not a document. Twenty-four hours is not a writing deadline but a process: who decides that a vulnerability is actively exploited, who is authorized to report on behalf of the company, and what happens when it lands as the weekend starts. A process that has never been rehearsed will not hold.
AI Act: the timeline after the Omnibus
The high-risk deadlines moved in 2026. The rest did not.
| Date | What applies |
|---|---|
| 2 February 2025 | Prohibitions on unacceptable-risk uses, and the AI literacy requirement for staff |
| 2 August 2025 | Obligations on providers of general-purpose AI models (GPAI) |
| 2 August 2026 | Transparency obligations: people must know they are interacting with an AI system, and generated content must be marked. Systems already on the market were given until 2 December 2026 for part of the marking requirements |
| 2 December 2027 | High-risk systems under Annex III - stand-alone systems in areas such as recruitment, credit and education |
| 2 August 2028 | High-risk systems under Annex I - AI embedded in products already regulated under EU law |
The postponement came through the Digital Omnibus, approved by the European Parliament in June 2026. It is worth reading correctly: it bought time for high-risk systems only. Everything above them already applies.
Provider or deployer: the distinction that sets the workload
Under the AI Act most obligations fall on the provider. Most companies are both.
A provider of a high-risk system carries the heavy requirements: risk management, data governance, technical documentation, logging, instructions for use, design for human oversight, accuracy and robustness, a quality management system, conformity assessment, CE marking and registration in the EU database.
A professional deployer carries fewer obligations, but not none. The confusion is common because the same company is usually the provider of its own product and a deployer of other people's tools at the same time, and each role has a different set of duties.
Note one item on that list: a quality management system. That is not a metaphor. It is exactly what the words say, and exactly what ISO 42001 is built to provide.
What to do over the next year
- Scope mapping. Which products are sold into the EU, which carry digital elements, and which AI systems are involved in them or in processes serving European customers.
- Classification. For each product and system: what you are - manufacturer, distributor, provider or deployer - and which risk category it falls into.
- Gap analysis against what exists. In most companies holding ISO 27001 a large share of the controls is already in place, and the work is adaptation rather than construction.
- The reporting process, rehearsed. This is the one obligation already in force, and the only one measured in hours.
- Technical documentation and conformity assessment. The heavy part, and the reason to start in 2026 rather than 2027.
Counting back from December 2027 leaves roughly fourteen months, and a significant share of that is work with suppliers and third parties who are not under your control.
What the engagement covers
- Scoping review: which products and which AI systems fall under each regulation
- Role and risk classification for every item, as the basis for everything that follows
- Gap analysis against the existing management systems - ISO 27001, ISO 42001, and ISO 22301 where it is held
- Building the reporting process and its clock, including a rehearsal against a scenario
- Vulnerability handling across the product lifecycle
- Building the required technical documentation and preparing for conformity assessment
- Folding all of it into the existing management review and internal audit cycle, rather than running a separate track
A note on scope: an organization with a functioning information security management system arrives with much of the infrastructure. The gap is usually not in the controls but in the proof - documentation, version history, and the ability to show what was done and when.
Common questions
We are an Israeli company with no EU entity. Does the CRA apply to us?
Yes, if you place a product with digital elements on the EU market. The regulation applies to the economic operator regardless of where it is established. A distributor or importer can also be treated as the manufacturer if it markets the product under its own name or substantially modifies it.
We only use AI tools, we do not build them. Does the AI Act still apply?
Possibly. The Act distinguishes between providers and professional deployers, and deployers carry fewer obligations, but not none. It also reaches providers and deployers outside the EU where the output of the AI system is used inside the Union. The first question to answer is what you are in relation to each system: provider, deployer, or both in different contexts.
What exactly started in September 2026?
The CRA reporting obligations. A manufacturer must report actively exploited vulnerabilities and severe security incidents on a staged clock: early warning within 24 hours, full notification within 72 hours, and a final report within 14 days for a vulnerability or one month for an incident. Reports go through the dedicated platform operated by ENISA, and the duty covers products already on the market.
Did the AI Act dates change?
Yes. The Digital Omnibus, approved by the European Parliament in June 2026, moved the high-risk deadlines: Annex III to 2 December 2027 and Annex I to 2 August 2028. Other obligations were not postponed. The prohibitions have applied since February 2025, the GPAI model obligations since August 2025, and the transparency obligations since August 2026.
We hold ISO 27001. Does that help with the CRA?
Considerably, but it is not enough on its own. The management infrastructure is already there: asset management, change management, vulnerability handling, incident response and internal audit. What the CRA adds is a focus on the product itself across its lifecycle, and a reporting clock measured in hours. That is usually where the gap sits.
Where do we start?
With mapping. Which products are sold into the EU, which of them carry digital elements, and which AI systems are involved in them or in processes serving EU customers. Without that map there is no way to tell whether this is two months of work or a year.
The official texts
Before deciding anything, read the binding text rather than a summary of it:
- Regulation (EU) 2024/2847 - Cyber Resilience Act
- Regulation (EU) 2024/1689 - Artificial Intelligence Act
Both links point to the official EU law database. The AI Act page also carries a consolidated version that folds in the amendments made since publication, and that is the text to work from.
This page is a professional overview and not legal advice. The dates reflect the texts published up to October 2026; verify them against the official text and with legal counsel before acting on them.
Start with a scoping review
The first step is a short review that establishes what actually applies to you. It already shows whether this is two months of work or a year.