IN Brief:
- The European Commission has set out an AI and cybersecurity action plan covering advanced model risks, testing capability, and critical-sector deployment.
- The plan links the AI Act, Cyber Resilience Act, NIS2, DORA, and wider European cyber legislation.
- Connected product manufacturers face growing pressure to build software security, AI assurance, and vulnerability handling into early design work.
The European Commission has set out an AI and cybersecurity action plan intended to strengthen Europe’s ability to assess advanced artificial intelligence systems, secure critical deployments, and use AI tools more effectively in cyber defence.
The plan brings together work under the AI Act, Cyber Resilience Act, NIS2 Directive, Digital Operational Resilience Act, Cyber Solidarity Act, and related EU security activity. Its central concern is the dual role of advanced AI models: the same capability that can accelerate vulnerability detection and defensive automation can also increase the speed, scale, and sophistication of cyber attacks.
A dedicated EU evaluation capability focused on cybersecurity is planned for launch in 2027. The facility is expected to support the AI Office by assessing advanced AI model capabilities and associated risks before systems reach wider European deployment. The Commission is also working with ENISA on a blueprint for structured access to advanced AI models, giving public and private organisations a clearer route to use leading systems for cybersecurity tasks.
Alongside model evaluation, ENISA and the Commission’s Joint Research Centre are developing a secure testing platform for AI systems. Simulated environments will be used to evaluate systems before deployment in critical sectors including energy, finance, healthcare, transport, and public administration. Electronic systems serving those sectors will increasingly need software behaviour, model behaviour, update handling, and resilience evidence to sit inside the product compliance file rather than beside it.
Requirements under the AI Act for advanced model providers are due to begin applying on 2 August 2026, while the Cyber Resilience Act becomes applicable by the end of 2027. That regulatory sequence gives electronics manufacturers a narrowing period in which to align product development with a regime that treats cybersecurity as a lifecycle obligation.
The same engineering pressure is already visible in device-level security. Microchip’s recent work around CRA-ready device security placed secure provisioning, authenticated updates, and key lifecycle control inside the design discussion, while SYSGO’s hardened ELinOS 8 industrial Linux platform added SBOM generation and broader security functions for long-lifecycle embedded deployments.
The Commission’s plan widens that discussion from product hardening to AI-enabled risk. As connected equipment becomes more software-defined, the attack surface is no longer limited to exposed ports, weak credentials, or outdated firmware. Model-assisted vulnerability discovery, automated exploit generation, insecure update chains, open-source dependency risks, and AI components embedded into operating workflows all alter the security case.
Development teams using AI both inside products and throughout engineering processes will need a more disciplined assurance route. Edge AI systems, robotics platforms, medical devices, industrial controllers, gateways, and smart infrastructure products may have to demonstrate not only conventional cybersecurity measures, but also how AI functions are tested, bounded, monitored, and updated.
Security-by-design will still depend on familiar foundations: hardware roots of trust, signed firmware, vulnerability disclosure processes, software bills of materials, secure update governance, and long-term support commitments. AI now sits inside the same assurance conversation, with testing infrastructure and regulatory expectations beginning to catch up with deployment.
Connected electronics will need cybersecurity, AI behaviour, and compliance evidence to be designed together. Products built around that assumption will move through qualification more cleanly than those that treat resilience as a documentation exercise after the hardware is finished.
