by Shawn Chang The EU Cyber Resilience Act (CRA) - Regulation (EU) 2024/2847 - entered into force on December 10, 2024. It is the EU’s first horizontal law that legally mandates secure-by-design for every “product with digital elements” placed on the European market. Manufacturers must now demonstrate compliance with a set of essential cybersecurity requirements throughout the entire product lifecycle, backed by enforceable penalties and market surveillance. The CRA’s essential requirements are structured in two parts of Annex I, and are being translated into harmonized standards by three project teams under CEN-CENELEC: PT1 (EN 40000-1-2) – Principles for cyber resilience. A process-oriented “catch-all” standard ensuring products are developed and maintained using a risk-based approach, covering secure development lifecycles, threat modeling, and security testing. PT2 (EN 40000-1-4) – Generic security requirements. A product-oriented standard mapping the CRA’s 13 essential security requirements (Annex I, Part 1, points a–m) to a catalog of technical controls. These cover: shipping without known exploitable vulnerabilities (a), secure-by-default configuration (b), automatic security updates (c), access control and authentication (d), encryption of data at rest and in transit (e), integrity protection (f), data minimization (g), resilience and availability (h), limiting attack surfaces (i), exploitation mitigation mechanisms (k), security logging and monitoring (l), and secure data deletion (m). PT3 (EN 40000-1-3) – Vulnerability handling requirements. A process standard mapping to Annex I, Part 2, requiring manufacturers to identify and document vulnerabilities (including SBOM), remediate without delay, conduct regular security tests, publicly disclose fixed vulnerabilities, maintain a coordinated vulnerability disclosure policy, and distribute security updates free of charge and without delay. The harmonized standards for PT1 and PT2 will make modern mitigations – CFI (PaX RAP, PAC/BTI, Intel CET), DFI (PaX KERNSEAL/AUTOSLAB, ARM MTE, VED), and capability-based approaches (CHERI, FIL-C) – the de facto baseline for compliance. But PT3 demands something harder: proper tracking of active exploits and potentially exploitable vulnerabilities across your entire product lifecycle. For the Linux kernel, this is a problem that no one has solved at scale. The Problem: A Broken Chain When a kernel vulnerability is discovered and fixed upstream, the fix doesn’t magically reach every device. It must travel through a long chain: Upstream fix → Stable branch backports → Distribution backports → End users At each step, backports can be partial, delayed, or missed entirely. Only a few GNU/Linux distro has full-time kernel maintainers while Only PaX/GRsecurity consistently provides high-quality backports across the board based on risk. Embedded vendors – automotive, industrial control systems, IoT devices built on Yocto/AOSP – are especially exposed. Many lack dedicated security teams, have no process for security audits or backport review, and simply don’t know which CVEs remain unfixed in their deployed kernels. Meanwhile, the CVE flood continues. Since the Linux kernel became a CNA, the volume of assigned CVE numbers has grown dramatically, making manual tracking impractical. The Risk Model Has Changed CVE-based risk analysis is no longer sufficient. The traditional approach — prioritizing fixes based on whether a public PoC or exploit exists — assumed that writing a working exploit required significant expertise and effort. AI (especially Claude Opus at the moment) has changed that equation. Large language models can now assist attackers in developing exploits for vulnerabilities that previously had no known proof-of-concept, dramatically lowering the barrier to weaponization. CVE-2026-4747 is just a beginning. A CVE without a public exploit does not mean low risk. It means the exploit hasn’t been published yet. This may affect how CRA enforce of vulnerability handling in the future. This is why the industry must shift from CVE-centric risk scoring to attack surface and exploit vector analysis. What matters is not whether someone has already written an exploit, but whether the vulnerable code path is reachable, what primitives it exposes, and what mitigations stand between an attacker and successful exploitation. This is exactly why the CRA’s PT2 emphasizes exploitation mitigation mechanisms (k) and limiting attack surfaces (i) — and why defense-in-depth matters more than ever. What We Built Kernel Backport Checker is a command-line tool that answers a simple question: which kernel CVEs are actually fixed in my kernel, and which are still open? It works by: Scanning NVD for CVEs affecting your specific kernel version using CPE matching Filtering by .config – if a vulnerable subsystem is disabled, the CVE is marked not applicable Extracting fix commits from NVD references and git log (upstream + stable repos) Verifying f...