The AI Act is usually described as a governance law, and most of it is. But it contains the first binding definition of AI security obligations, and the Cyber Resilience Act, which applies to software and devices with digital elements regardless of whether they use AI, supplies the vulnerability handling and reporting machinery the AI Act leans on. Security teams should read the two together, because that is how the European legislator wrote them.
Article 15: the attack classes are named
For high-risk systems the AI Act requires an appropriate level of accuracy, robustness and cybersecurity across the lifecycle. Article 15(5) is specific: systems must be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system-specific vulnerabilities, and the measures must include, where appropriate, prevention, detection, response, resolution and control for data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws. That is a control catalogue: for each named class, a provider must be able to show a threat assessment, tested controls and monitoring. NIST AI 100-2 and ETSI TS 104 223 give the vocabulary and the provisions; the CEN/CENELEC cybersecurity specification will eventually give a presumption of conformity. The Digital Omnibus moved the deadline for Annex III systems to 2 December 2027 and Annex I to 2 August 2028; it did not change the substance.
The CRA link
Article 15 also says that a high-risk AI system that is a product with digital elements under the Cyber Resilience Act and satisfies the CRA's essential cybersecurity requirements is deemed to meet the AI Act's cybersecurity requirement. In practice, then, the CRA's Annex I is the working baseline for AI product security: secure-by-default configuration, no known exploitable vulnerabilities at release, attack surface minimisation, protection of data confidentiality and integrity, and a vulnerability handling process with coordinated disclosure, an SBOM and timely security updates for the support period. Model weights, inference servers, agent frameworks, IDE extensions and MCP servers shipped to EU customers are products with digital elements. Their support-period patching duty covers vulnerabilities in the model-serving stack, and their reporting duty applies when an injection or agent vulnerability is actively exploited.
Three reporting clocks
One incident can trigger three reporting regimes. Under the CRA, from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform: early warning within 24 hours, notification within 72 hours, final report within 14 days for vulnerabilities and one month for incidents. Under the AI Act's Article 73, providers of high-risk systems must report serious incidents to the market surveillance authority immediately and no later than 15 days, shortened to two days for widespread infringements or critical infrastructure and ten days for a death; providers of systemic-risk GPAI models report to the AI Office under Article 55 and the code of practice. Under NIS2, essential and important entities report significant incidents to their national authority with a 24-hour early warning, 72-hour notification and one-month final report. Add GDPR's 72-hour personal data breach rule where personal data is involved. The definitions differ, the authorities differ and the clocks differ, so the incident response plan needs a decision tree that classifies an event against all of them at once.
Systemic-risk GPAI models
Providers of models above the 10^25 FLOP presumption or designated by the Commission must, under Article 55, perform state-of-the-art evaluation including adversarial testing, assess and mitigate systemic risks, track and report serious incidents, and ensure an adequate level of cybersecurity for the model and its physical infrastructure. The General-Purpose AI Code of Practice's Safety and Security chapter turns this into a framework: risk taxonomy, evaluations with independent external testing, model weight protection calibrated to the RAND security levels including insiders, incident reporting with two-day timelines for the most serious cases, and a Model Report. The AI Office's enforcement powers became exercisable on 2 August 2026, and it now has exclusive competence over AI systems built on GPAI models by the same provider. Enterprise buyers can use signatory status and the published Model Reports as due diligence.
Article 50 and provenance
Since 2 August 2026, providers of generative systems must mark synthetic audio, image, video and text output in a machine-readable, detectable format, and deployers must disclose deepfakes and AI-generated public-interest text; chatbots must disclose that they are AI. Systems already on the market have until 2 December 2026 for the marking duty. The Code of Practice on marking and labelling, finalised in June 2026, expects a combination of metadata (C2PA-style credentials), imperceptible watermarking and detection interfaces, because metadata alone is stripped by re-encoding. From 2 December 2026 the Act also prohibits systems designed to generate non-consensual intimate imagery or child sexual abuse material.
What to do now
- Inventory AI systems and products, classify against Annex III and the CRA, and assign provider, deployer and manufacturer roles per product.
- Build the Article 15 control catalogue: for poisoning, evasion, confidentiality attacks and model flaws, document the threat model, the tested controls and the monitoring, using ETSI TS 104 223 and NIST AI 100-2 now and mapping to the harmonised standards later.
- Implement CRA vulnerability handling: coordinated disclosure policy, SBOM (and AIBOM) generation, security update capability for the support period, and the ENISA reporting workflow, live now.
- Write the multi-regime incident decision tree and rehearse it against the 24-hour and two-day clocks.
- If you supply or deploy a systemic-risk model, align red teaming, incident tracking and weight security with the code of practice and obtain the Model Report.
- Implement machine-readable marking and detection for generated content before the December 2026 legacy deadline.
- Keep logs: the AI Act's automatic logging and the DPDP-style retention expectations mean agent and model logs must be retained and attributable.
The AI Act's dates moved; the CRA's did not. Between them they make AI security in Europe a matter of demonstrable controls and reportable failures, which is what a security team would want it to be.
