Key Takeaways
- CRA compliance goes beyond patching. Teams need a record of who accessed each device and what changed.
- Mixed IT and OT teams and rotating integrators make that record hard to assemble, so build it centrally rather than site by site when an auditor asks.
- A self-hosted operational control plane like Portainer centralizes access control and keeps one consistent audit record across edge sites, supporting CRA readiness.
The EU Cyber Resilience Act's reporting obligations took effect in September this year. Now, if a manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting a product with digital elements, it has 24 hours to file an early warning and 72 hours to file a full notification. The penalties for getting it wrong? Up to €15 million or 2.5% of global turnover, whichever is higher.
Most commentary around the deadline has focused on the reporting window, when the harder question is who’s actually accountable for the device once something goes wrong.
This isn't a wait-and-see problem for those outside of Europe, either. Regulators in markets like India are already leaning into the EU's template and the U.S. has a framework taking shape as well.
The Accountability Gap the Regulation Just Exposed
Over years of service, a connected device rarely stays exactly as the original manufacturer built it. Operations teams integrate it with other systems and run their own software on it. Under the CRA, that matters more than most industrial buyers might realize. Now, a party that substantially modifies a product, or integrates components into a new product placed on the market, is treated as the manufacturer for regulatory purposes, potentially shifting the same reporting obligations to themselves rather than the original builder.
The rule itself isn't new. What's new is the reporting clock that started in September, which turned an abstract legal definition into a hard deadline, making it impossible to ignore.
Security Stops Being a Patch and Becomes a Paper Trail
Recent IoT Now reporting on the CRA rollout in practice breaks the obligation into six parts:
- Lifecycle security accountability
- Update management
- Vulnerability handling and disclosure
- Attack surface limitation
- Incident containment
- Security logging and monitoring
Six items that together create one requirement: prove who could touch a system, when, and what happened while they were there.
That's a governance capability, and a different problem than what most OT security programs were built to solve.
What Proof Looks Like Across a Fleet
A team running containerized workloads across dozens or hundreds of sites has to produce proof on demand. Documentation needs to show who had access to any given device on any day, as well as what changed, and whether the vendor on-site stuck to the one task they came to do.
Yet visibility rarely exists by default in an environment with mixed IT and OT teams, third-party integrators cycling through on service contracts, and equipment that predates the software running on it. Teams have to build it into the platform centrally, instead of rebuilding it site by site when an auditor asks for it.
While an unpatched device is a real risk, so is a device that nobody can account for. That’s the one regulators just started asking about directly.
What to have on hand before an auditor asks
- A current software and firmware version inventory across every device in the fleet (and not reconstructed after the ask).
- The record of who has access to each device, with evidence that access follows least privilege rather than standing admin rights for every vendor.
- An audit log that lives on the management plane, not on the device itself, so the person being recorded can't edit the record.
- A tested OTA rollback path, so a failed patch doesn't become a second incident to report.
- Documentation of vendor and integrator visits: what task they came to do, and whether they stayed within it.
- A named point of contact and process for filing the 24-hour early warning, so you know who to call if the clock starts ticking.
Where a Control Plane Fits
As a self-hosted operational control plane for container platforms in industrial and IoT environments, that’s what Portainer changes. A question about last Tuesday's substation access doesn't send an engineer digging through a spreadsheet or calling the vendor to ask. A single set of role-based permissions already decided who could touch that device. The running record already shows what went in, when, and who put it there.
That same policy holds whether the site is a factory floor, a fleet vehicle, or a single edge box, without requiring you to tear out any of your equipment that's already running.
But a control plane doesn’t alone make an organization CRA-compliant. It puts the operational evidence a compliance conversation requires, like centralized access control and a consistent audit record, within reach on-demand instead of scattering it across a dozen sites and a handful of vendors.
Start Where the Evidence Is
Nobody closes a governance gap overnight, any more than anyone modernizes a factory overnight. But your practical starting point is the same: know what's running and who can touch it, then close the gap between what your organization can currently show and what the CRA now requires you to prove.
That's what good operations already looks like. The CRA just made it non-negotiable.
The reporting clock is just the first deadline. On December, 11, 2027, the CRA becomes fully applicable. Every remaining requirement will take effect, including security by design, full conformity assessment, and CE marking that covers cybersecurity. The access and change records teams build now to meet the reporting window are the same foundation they’ll rely on when those requirements arrive.
How exposed is your current environment? The Portainer OT Security Readiness Scorecard is a self-scoring diagnostic covering patch management readiness, audit and access posture, and regulatory exposure, including CRA and NIS2 requirements.
FAQ
What counts as "substantially modifying" a device under the CRA?
Under Article 3 of the CRA, a modification is "substantial" when it changes the product's compliance with the essential cybersecurity requirements, or changes the purpose the product was originally assessed for. That obligation is triggered specifically by placing the modified product on the market. If you integrate third-party hardware into your own offering, add your own software layer, or change what a device does after it left the original manufacturer, and then sell or distribute that modified product, you may be taking on manufacturer obligations for it, even if you didn't build it. An operator that only modifies equipment for internal use and never resells it isn't triggering this rule the same way.
Does this apply to us if we don't sell directly into the EU?
The obligations attach to products placed on the EU market, regardless of where the manufacturer is based. So, if none of your products reach the EU market, directly or through a distributor, the CRA itself doesn't apply to you yet. Two things are worth considering, however. Your hardware or software can end up in scope indirectly if a customer integrates it into something they sell into the EU, and the EU's framework is functioning as the template other regulators are working from.
Sources: IoT For All / Transforma Insights, "The EU Cyber Resilience Act: What IoT Vendors Need to Know", EE Times, "Which IoT Regulator Will the Rest of the World Follow?"
What's the difference between the 24-hour early warning and the 72-hour notification?
They're two stages of the same clock, not two separate deadlines. Once you become aware of an actively exploited vulnerability or a severe incident, you have 24 hours to file an initial early warning with ENISA, then 72 hours from that same starting point to file a fuller notification. A final report follows in 14 days after a fix is available for a vulnerability, or within a month of the 72-hour notification for an incident. It all goes through the CRA's Single Reporting Platform to your national CSIRT and ENISA, not multiple separate filings.
Source: European Commission, "Cyber Resilience Act — Reporting obligations"
What happens on December 11, 2027?
That's when the CRA's remaining obligations become fully enforceable, and not just the reporting clock that started in September 2026. From that date, products with digital elements need a completed conformity assessment, cybersecurity-specific CE marking, and security built in by design (rather than retrofitted). The access and audit records you build now to meet the reporting deadline are the same evidence you'll need for that assessment.
Source: IoT For All / Transforma Insights, "The EU Cyber Resilience Act: What IoT Vendors Need to Know"
What actually counts as proof of who accessed a device and what changed?
Reporting on the rollout breaks the obligation into six practical requirements: lifecycle security accountability, update management, vulnerability handling and disclosure, attack surface limitation, incident containment, and security logging and monitoring. In plain terms: for any device, on any date, you need to show who had access, what they changed, and whether the log of that activity could have been altered by the person it's recording. A log stored on the device itself, editable by whoever accessed it, doesn't clear that bar.
Source: IoT Now, "EU Cyber Resilience Act: IoT device security governance"