The consultation nobody read
Every major device manufacturer in Europe filed comments on the EU Commission’s draft CRA implementation guidance before the March 31 deadline. Siemens. Bosch. Continental. NXP. Philips. Thales. Arm. STMicroelectronics. Sony. Ericsson. Nokia. Axis Communications. All of them.
The Commission collected 114 responses.[1] The public consultation portal lists them all. It would seem that almost no one outside Brussels has read them.
I pulled the full dataset and read every submission. Here is what stood out.
The pattern
The surface-level story is that industry hates the 24-hour incident reporting requirement. That is true — 26% of respondents flagged it,[2] and the opposition is near-universal. Nobody defended it. Telecom operators, semiconductor manufacturers, enterprise software companies, individual security researchers — all filed variations of the same argument: no responsible security team can characterize an incident within 24 hours. The standard proposal is 24 hours to acknowledge awareness, 72 hours for a preliminary report, 30 days for the final analysis. This aligns with NIST and CISA frameworks.[3] The Commission will likely revise this before finalization.
The less-reported story is what companies said they actually need to comply.
Hardware security infrastructure, named explicitly
Three companies in the semiconductor and defense space named PKI, HSMs, and hardware-rooted trust by name as the mechanisms they believe satisfy CRA requirements — and asked the Commission to say so explicitly in the final guidance.
Thales called out “encryption and PKI as means of satisfying CRA requirements for confidentiality and integrity” and specifically flagged “encryption key management, secure boot chains” as requiring specialized infrastructure that takes time to deploy.[4] STMicroelectronics asked the Commission to recognize “hardware security features — secure boot, hardware security modules, trusted execution environments” as satisfying specific CRA essential requirements.[5] Arm made a similar argument for TrustZone and CCA architectures.[6]
These are not lobbying generalizations. They are specific, named technical controls that these companies believe map to CRA obligations.
“The guidance should explicitly recognize hardware security architectures as satisfying relevant CRA requirements.” — Arm Ltd submission, March 2026[6]
The supply chain attribution problem
NXP Semiconductors put it plainly: their chips are integrated into thousands of downstream products by customers. They cannot be held responsible for vulnerabilities introduced by product integrators. Arm made the same argument for IP licensing. Continental described automotive ECUs with dozens of third-party software layers where vulnerability attribution is genuinely unclear.
This is not a whine about liability. It is a recognition that the current guidance lacks a workable model for multi-tier supply chain accountability. The technical solution that makes this tractable is a cryptographic chain of custody — component identity rooted in hardware, with verifiable attestation at each integration layer. The guidance does not mention this. The companies asking for it do not describe it in those terms. But that is the architecture they are asking for.
The SBOM gap
NXP, Cisco, and the Linux Foundation all flagged that SBOM requirements for hardware components lack practical implementation guidance. Generating a software bill of materials for firmware is relatively well-understood. Generating one for a complex SoC with proprietary IP from multiple vendors, and making it cryptographically verifiable, is not a solved problem in the guidance. Linux Foundation specifically asked the Commission to fund open-source security tooling to help projects comply.
IoT lifecycle management at scale
Axis Communications — a network camera manufacturer — noted that IP cameras and network video products have operational continuity constraints that complicate update deployment. Teltonika, Lithuania’s largest IoT device manufacturer, raised the same concern about deployed fleet management. EmbedIT, a small Slovak embedded software company, described the gap between what CRA implies and what a 20-person firmware shop can actually implement.
The underlying problem in all three submissions is the same: managing certificate and credential lifecycle across a large deployed device fleet, with heterogeneous hardware, limited compute, and operational uptime requirements.
The Belgian Centre for Cybersecurity — the only national authority to file a public comment[9] — identified this as the single most critical implementation dependency. The SRP must be live before September to give manufacturers time to integrate their reporting pipelines. ENISA is building it now.
For device manufacturers, September 2026 means having detection infrastructure operational — not just documented. You need to know when one of your deployed devices is running an actively exploited vulnerability. That requires telemetry, device identity, and a reporting pipeline. Most OEMs do not have this today.
What I take from this
The consultation responses collectively describe a device security infrastructure gap that the companies themselves recognize they need to close. The gap has a consistent shape: hardware-rooted identity, verifiable component provenance, scalable credential lifecycle management across deployed fleets, and automated detection and reporting for exploited vulnerabilities.
The guidance does not tell companies to buy PKI infrastructure. But the companies filing the most sophisticated responses — Thales, NXP, STMicro, Arm, Continental — are describing exactly the capabilities that PKI-backed device identity provides, and asking the Commission to recognize them as satisfying CRA requirements.
Five months is not much runway to build this from scratch. For the OEMs that have not started, the September reporting deadline is not a hypothetical. It is a forcing function.
The companies that treat CRA as a compliance checkbox will build documentation. The ones that read these submissions carefully will build infrastructure.
I created summary of all 114 responses in PDF file. Here is LinkedIn URL to download and review: https://www.linkedin.com/smart-links/AQH8eNlD93bLnw
Source: All 113 submissions retrieved directly from the EU Commission Have Your Say portal, Initiative 16959, publication ID 22440. Consultation period: March 3 to March 31, 2026.
Sources & Notes
EU Commission Have Your Say portal, Initiative 16959, publication ID 22440. All 114 responses retrieved via public API endpoint. Consultation period: March 3 to March 31, 2026. Available: ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/16959
Author’s analysis. Topic codes applied independently across all 114 submissions. “24-hour reporting infeasible” was the most common concern, raised by 30 of 114 respondents (26%). Full dataset available at source [1].
NIST SP 800-61 Rev. 3 (August 2024), Section 3.2 — recommends initial incident reporting within 72 hours of detection. CISA 72-hour reporting rule (CIRCIA, 6 USC § 681b) requires covered entities to report significant cyber incidents within 72 hours. Both frameworks allow 30 days for final incident reports.
Thales Group submission, EU Have Your Say Initiative 16959, March 2026. Submission retrievable at source [1] by filtering Organization = “Thales”.
STMicroelectronics submission, EU Have Your Say Initiative 16959, March 2026.
Arm Ltd submission, EU Have Your Say Initiative 16959, March 2026.
Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 — vulnerability and incident notification obligations apply from September 11, 2026. Official Journal of the EU, L 2024/2847, November 20, 2024.
Regulation (EU) 2024/2847, Article 71 — full application from December 11, 2027.
Author’s analysis. Of 114 submissions, one was classified PUBLIC_AUTHORITY in the consultation dataset: Centre for Cybersecurity Belgium (CCB / Centre pour la Cybersécurité Belgique). All other submissions were from companies, trade associations, NGOs, academic institutions, or private citizens.
Tim McAllister is Field CTO at DigiCert, where he leads customer-facing technical strategy on device identity, post-quantum cryptography, and EU regulatory compliance (CRA and RED) for OEM and IoT manufacturers. He is an active participant in NIST, SAE EVPKI, Matter, PSWG, CharIN, and SEMI standards bodies. He writes about device trust, AI security, and the intersection of regulation and infrastructure. Follow on LinkedIn or subscribe for future issues.