The EU Cyber Resilience Act (CRA) is now in force, but many organizations are still unsure how to operationalize it – especially when they build or operate complex AI, edge, and cloud-native products.
First, let’s clarify the key CRA deadlines ahead:
- 11 June 2026 – Designation and provisioning of conformity assessment bodies starts.
- 11 September 2026 – Reporting obligations for actively exploited vulnerabilities and severe incidents apply.
- 11 December 2027 – Full compliance with the Cyber Resilience Act is required.
Treating CRA as a multi-year program, not a last-minute project, is essential. A pragmatic 12–24 month roadmap typically includes four phases:
1. Understand applicability and inventory your “products with digital elements”
- Map which hardware, software, and AI-powered systems are being used, including 3rd party sources.
- Identify where they are deployed: cloud, on-prem, edge, sovereign or air-gapped environments.
- Clarify ownership: who is responsible for security, updates, and incident handling for each product line.
- Determine the required level of compliance based on the risk category of each product.
2. Align manufacturing processes with CRA security requirements - Implement SBOM generation and maintenance across your software supply chain.
- Introduce continuous vulnerability scanning and risk-based prioritization.
- Align vulnerability handling processes with CRA expectations on remediation and communication.
- Review the development lifecycle and make changes necessary to include security by design and by default.
- Prepare documentation for each product – Declaration of Conformity and CE marking, technical documentation and user manuals.
- Integrate risk assessment into the development cycle.
- If the product falls into an Important or Critical risk category, schedule the appropriate conformity assessment.
- Plan for increased development cycles and support costs, including security patches and documentation maintenance for up to 10 years (depending on product category and CRA obligations).
3. Add autonomous runtime monitoring and incident response This is where many organizations currently have the largest gap. - Deploy runtime security that can inspect network traffic and workload behavior in real time.
- Ensure protection works in constrained and offline environments (edge sites, sovereign clouds, air-gapped deployments).
- Capture detailed telemetry and incident timelines that can be reused as CRA evidence.
- Prepare incident response plans that cover prompt remediation of discovered vulnerabilities and a clear release process for security patches.
- Ensure alignment on incident handling and patching processes with all relevant third‑party partners and suppliers.
4. Build a reusable evidence and reporting layer - Centralize security and compliance evidence: detections, responses, vulnerabilities, and configuration changes.
- Automate generation of CRA-relevant reports (and reuse them for NIS2, DORA, and sectoral frameworks).
- Regularly test and refine your incident handling and reporting workflows and do a risk assessment.
For software products relying on AI and edge workloads, the hardest part is usually phase 3: achieving continuous runtime visibility and response without impacting performance or depending on constant cloud connectivity.
This is exactly where autonomous, AI-native runtime security platforms – with a single lightweight agent, sub-millisecond inline detection, and offline operation – can accelerate CRA readiness while preserving GPU and edge performance.
If you are designing your CRA roadmap for AI or edge-heavy environments and need to understand what “good” runtime evidence looks like in practice, we are here to help you.
