CRA Compliance Checklist: Edge Computing Devices & Gateways
Annex III Class I for most industrial edge gateways — Default for consumer edge devices; Class II if processing critical infrastructure data
Edge computing devices and gateways — including industrial IoT gateways, edge AI inference nodes, fog computing appliances, and protocol converters — sit at the boundary between operational technology and IT networks. They often aggregate sensitive data from many downstream devices and may have elevated privileges in industrial environments. Most industrial edge gateways are Annex III Class I; those processing critical infrastructure data may be Class II.
1. Scope & Classification
Confirm all edge gateways and edge computing appliances with network connectivity are in CRA scope
Every edge device with a network interface and updateable software is a product with digital elements. Map all product types in your portfolio.
Assess Annex III Class I for industrial edge gateways that aggregate data from operational technology environments
Industrial edge gateways that bridge OT and IT networks are important products. Their compromise could enable lateral movement from IT into OT environments. Class I is likely.
Assess Class II if the edge device processes data from or controls critical infrastructure systems
Edge gateways in energy, water, transport, or other critical infrastructure control loops may be Class II. Assess based on the downstream systems the gateway connects to.
Compile SBOM for edge device OS (typically embedded Linux or RTOS), runtime environment, containerisation layer, and all application modules
Edge devices increasingly run containerised workloads. The SBOM must cover the host OS, container runtime (Docker, containerd), and all deployed container images.
2. Product Security (Annex I Part I)
Implement hardware-backed secure boot and trusted execution environment for sensitive key material and edge AI models
Edge devices are deployed in physically accessible locations. Hardware-backed secure boot and TEE (ARM TrustZone, Intel TDX) protect against physical attacks.
Enforce mutual TLS authentication for all communications between edge devices, cloud orchestration platforms, and downstream IoT devices
Edge-to-cloud and edge-to-device communications must be mutually authenticated and encrypted. Implement certificate-based identity for all devices.
Isolate edge workloads in containers or VMs — prevent workload breakout to host OS or cross-workload data access
Edge devices running multiple workloads (e.g. inference, data aggregation, VPN) must isolate each workload. A compromised container must not be able to access other workloads or the host OS.
Implement remote attestation to allow operators to verify edge device integrity before trusting its outputs
Remote attestation (using TPM or hardware attestation services) allows operators to cryptographically verify that an edge device is running untampered firmware. Increasingly important for critical edge deployments.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy with a dedicated security contact for edge device and gateway vulnerabilities
Edge devices are increasingly targeted as IT/OT bridge points. A CVD policy with OT and IoT security expertise is essential.
Provide OTA update capability with support for scheduled maintenance windows and zero-downtime updates for critical edge deployments
Industrial edge gateways often cannot be taken offline for updates. Provide A/B update mechanisms supporting hitless updates with automatic rollback on failure.
Define security support lifecycle appropriate to industrial deployment — minimum 10 years for industrial edge gateways
Industrial edge devices are capital investments with long lifecycles. Use LTS Linux kernels and commit to 10-year minimum security support for industrial products.
4. Article 14 Incident Reporting
Define Article 14 triggers for edge device incidents — focus on exploitation enabling OT network access, data exfiltration, or edge AI model poisoning
An actively exploited edge gateway vulnerability that enables lateral movement into OT networks is a high-severity Article 14 trigger.
Prepare and test the Article 14 notification procedure with named owners at each milestone
Pre-prepare notification templates covering edge-specific incidents. Use the CVD Portal Article 14 timeline tool to plan your process.
5. CE Marking & Technical Documentation
Prepare technical file documenting edge security architecture, container isolation, attestation capability, and SBOM
Edge device technical files should include architecture diagrams showing the IT/OT boundary, container isolation model, and remote attestation design.
Issue EU Declaration of Conformity referencing the CRA for all edge computing products
DoC must reference the CRA. For Class I industrial products, conduct thorough internal assessment. For Class II, engage a Notified Body.
Track your Edge Computing Devices & Gateways 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 edge gateway runs third-party applications from customers — who is responsible for the security of those applications?+
You, as the platform manufacturer, are responsible for the security of the edge platform itself — the OS, runtime environment, and container isolation. Customers deploying their own applications on your platform are responsible for those applications. However, you must ensure your platform provides adequate isolation so a compromised application cannot escape to the host or other applications. Document your platform security model clearly.
We supply edge gateways to industrial OEMs who integrate them into their products — who holds CRA obligations?+
As the gateway manufacturer, you hold CRA obligations for the gateway as a standalone product. The OEM who integrates your gateway into their product and places it on the market takes on manufacturer obligations for the integrated product. Both parties have distinct obligations. Provide the OEM with your CRA technical documentation and SBOM to support their compliance.
Our edge AI model is updated frequently — does each model update trigger CRA obligations?+
AI model updates that do not change the firmware or software architecture are not typically considered new product placements under the CRA. However, if a model update introduces new capabilities, new data processing, or changes the security architecture, this should be assessed against your existing CRA compliance. If the update represents a substantial modification, the technical documentation and DoC should be reviewed and updated.
Need a CVD policy for Edge Computing Devices & Gateways?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.