CRA Compliance Checklist: Embedded Linux Devices
Default to Annex III Class I depending on deployment — embedded Linux devices span a wide range; industrial or infrastructure use may attract Class I or Class II
Embedded Linux devices span a vast range — from network gateways and industrial HMIs to set-top boxes and smart displays. All are products with digital elements subject to the CRA. The open-source nature of Linux creates specific obligations around SBOM completeness and CVE monitoring. Classification ranges from Default for consumer devices to Annex III Class I or II for industrial or infrastructure applications.
1. Scope & Classification
Confirm all embedded Linux devices with network connectivity are products with digital elements in CRA scope
Any embedded Linux device that connects to a network — regardless of the Linux distribution or variant — is in scope for the CRA.
Assess classification based on deployment context — Default for consumer, Class I for industrial, Class II for critical infrastructure
The same embedded Linux platform may be Default when deployed in a consumer product but Class I or II when deployed in industrial or critical infrastructure contexts. Document intended use carefully.
Compile a comprehensive SBOM covering the Linux kernel version, all system packages, init system, network services, and application layer
Embedded Linux devices include hundreds of packages. Use automated tools (Yocto SBOM generation, Buildroot manifests, Trivy, Syft) to generate and maintain the SBOM.
Subscribe to Linux kernel security advisories and upstream package CVE feeds for all SBOM components
The Linux kernel and major packages (OpenSSL, BusyBox, glibc, dnsmasq) have active CVE streams. Establish automated monitoring against your SBOM.
2. Product Security (Annex I Part I)
Disable all default accounts, shell services (SSH, Telnet), and debugging interfaces before production deployment
Embedded Linux devices often ship with developer-facing services enabled. Audit and disable all services not required for production function before shipment.
Implement verified secure boot using a hardware root of trust (e.g. TPM, secure element, or SoC secure boot fuses)
Secure boot prevents booting of unauthorised firmware. Use the SoC's native secure boot mechanism with manufacturer-controlled signing keys.
Apply kernel hardening measures — enable ASLR, stack protector, SELinux or AppArmor, and disable unnecessary kernel modules
Linux kernel hardening significantly raises the cost of exploitation. Enable all appropriate security features for your kernel configuration. Use the Kernel Self Protection Project (KSPP) recommendations.
Implement cryptographically signed OTA updates with rollback protection
Use A/B partition OTA updates with signed images and rollback protection. RAUC, Mender, or SWUpdate are common frameworks for embedded Linux OTA.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy and security.txt for vulnerability reports related to your embedded Linux product
Embedded Linux devices attract significant security research. A clear CVD policy and responsive security team are required.
Establish a process to track and remediate CVEs in all SBOM components — prioritise CVSS 7.0+ kernel and network stack CVEs
Use automated SBOM scanning (Grype, Trivy, Dependency-Track) to continuously monitor for new CVEs. Define remediation SLAs by CVSS severity.
Define and publish a security support period appropriate to product deployment lifecycle — industrial devices warrant 10+ years
Consumer embedded Linux products may support 3–5 years. Industrial products warrant 10+ years. Use a long-term support (LTS) Linux kernel for products with extended support commitments.
4. Article 14 Incident Reporting
Monitor for active exploitation of embedded Linux vulnerabilities — kernel exploits and network service vulnerabilities are common attack vectors
Embedded Linux devices are frequent targets. Monitor CVE exploitation status (CISA KEV, ENISA threat intel) for all SBOM components.
Prepare and test Article 14 notification procedure — 24h, 72h, 14-day milestones with named responsible owners
Use the CVD Portal Article 14 timeline tool to plan your process. Assign named owners for each reporting milestone.
5. CE Marking & Technical Documentation
Prepare technical file including Linux security configuration, SBOM, kernel hardening evidence, and CVD policy
Document your Linux security configuration choices. Include evidence of secure boot implementation, disabled services, and kernel hardening measures.
Issue EU Declaration of Conformity referencing the CRA — update it when major firmware versions are released
The DoC should be reviewed with each major firmware release. If the security architecture changes materially, update the DoC and technical file.
Track your Embedded Linux Devices compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
Our device uses a mainline Linux kernel — does using upstream kernel LTS versions help with CRA compliance?+
Yes. Using a mainline LTS Linux kernel (currently 6.1 LTS or 6.6 LTS) ensures you receive security patches directly from the kernel security team for the LTS support window (typically 6 years). This significantly reduces the burden of backporting security fixes. Staying on LTS kernels and applying upstream patches promptly is strongly recommended for CRA compliance.
We use Yocto to build our embedded Linux — how does that affect our SBOM obligations?+
Yocto Project supports SBOM generation natively (via meta-spdxscanner and CVE checking layers). Enabling SPDX SBOM generation in your Yocto build is a practical way to produce the SBOM required by CRA Article 10(6). You should also enable the CVE checking layer to automatically flag known vulnerabilities in your recipe versions as part of the build process.
Our embedded Linux device has no display or user interface — how do we publish our CVD policy?+
The CVD policy does not need to be on the device itself. It should be published on your company website and referenced in the product documentation. A security.txt file on your company domain at /.well-known/security.txt is the primary mechanism. Include the CVD policy URL in product manuals and packaging inserts.
Need a CVD policy for Embedded Linux Devices?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.