IEC 62443 Gets You Partway to CRA-Ready. Here's the Gap
If your team has spent the last year running an IEC 62443-4-1 secure-development program, you've done real work. You have a documented lifecycle, security requirements baked into the device, maybe even a 4-2 evaluation underway on the hardware itself. It's reasonable to feel like the EU Cyber Resilience Act (CRA) is mostly a formality from here.
It isn't — and the reason has nothing to do with how well you did the work. It's about where IEC 62443 stops looking.
The scope IEC 62443 was never built to cover
IEC 62443 is a standard for Industrial Automation and Control System (IACS) components — the device, its firmware, the technical security requirements a lab can evaluate against a Security Level. That's exactly what it says on description, and it's why it's become the de-facto expectation across industrial and OT tenders: without certified products, it is increasingly difficult to close business.
The CRA draws its boundary somewhere else entirely. Under the CRA's own product-boundary model, a manufacturer carries full compliance responsibility not just for the device, but for "remote data processing solutions built and operated to support product functions" — in plain language, the cloud backend your device talks to. Add in the companion mobile, desktop or web app that configures the device, receives its data, or triggers a firmware update, and you have two entire categories of "your product" that a 62443 program was never scoped to touch.
Put differently: a device that passes IEC 62443-4-2 can still ship with an unauthenticated API, a companion app with a hardcoded key, or a cloud service holding customer data or controlling the product with no vulnerability handling process — and every one of those is squarely inside CRA's scope, even though none of them were ever in your 62443 assessment.
| IEC 62443 | CRA | |
|---|---|---|
| Covers | IACS device, firmware, hardware components | Device and backend/cloud services and companion apps — the whole "product with digital elements" |
| Evaluates against | Security Levels (technical capability) | Essential requirements (Annex I) + lifecycle vulnerability handling |
| Who checks | Assesment in-house or third-party, audit by third-party, on request | Self-assessment or notified body, depending on classification tier |
| Reporting clock | None | 24hr / 72hr / final report for actively exploited vulnerabilities and severe incidents — anywhere in the product, not just the device |
That last row is the one with a deadline attached.
September 11 Marked a Turning Point for Compliance
CRA's reporting obligations under Article 14 took effect this week. From now on, if there's reliable evidence a vulnerability in your product is being actively exploited — or a severe incident affects it — you have 24 hours to file an early warning, 72 hours for a full notification, and 14–30 days for a final report, through ENISA's new Single Reporting Platform. Weekends don't pause the clock.
Here is what often surprises teams familiar with IEC 62443: "your product" is determined by the scope of the CRA, rather than by IEC 62443. If a vulnerability shows up in the cloud service behind your device, or in the companion app, the 24-hour clock is running whether or not anyone on your team is watching that part of the stack.
Extend your existing foundation — no need to start from scratch
The good news is that the 62443-4-1 discipline you've built is a good basis for CRA compliance. The secure-development lifecycle, the requirements traceability, the evidence habit — that's exactly the muscle CRA's Annex I Part I (security by design) asks for. The work doesn't need repeating; it needs a wider architecture to apply to.
That's the gap Test of Things is built to close:
Map the whole system, not just the device. Test of Things' Build stage creates a digital model of your product where hardware, cloud services, and mobile apps are all mapped as entities on one canvas — so the backend and companion app your 62443 assessment never touched become visible, in-scope components from day one.
Get the delta, not a restart. Select CRA alongside your existing IEC 62443 work and Test of Things's platform generates the additional tasks your architecture needs — scoped to what's new, not a re-run of what you already have evidence for (in case your managing both compliances on our platform).
One reporting clock, one place to watch it. Continuous monitoring and zero-day portfolio search run across the full product portfolio — device, backend, and app together — so a vulnerability disclosure anywhere in the stack surfaces in the same place, instead of depending on someone remembering to check the cloud team's backlog.
One audit trail for the whole product. When it's time for the Declaration of Conformity, the evidence for the device and the evidence for the backend/app live in the same release-anchored record, not two separate binders from two separate teams.
The question worth asking this week
In our conversations with manufacturers, the same pattern pops up regardless of company size: compliance responsibility for the device sits with one team, and responsibility for the backend or app sits with another — or with no one in particular. If you can't immediately answer "who owns the 24-hour reporting clock for our cloud service," that's the gap to close first, and it's worth closing before it closes itself on you.
Your IEC 62443 program is a good investment indeed, helps to sell your products confidently. It just wasn't the whole picture. IEC 62443 is being updated as we speak with expected release in late 2027 or early 2028, and CRA will have an impact on the outcome as IEC 62443-4-1 and 4-2 are going to be part of harmonised standards of CRA.
Test of Things helps connected-product manufacturers extend existing IEC 62443 work into full CRA readiness — device, backend, and app in one place. If you want to see where your current scope ends and CRA's begins, get in touch for a walkthrough.
