EU CRA vs NIS2 vs IEC 62443: Compliance Mapping for IoT and OT Vendors
A controller vendor ships one firmware image to a water utility in Germany, a food plant in Poland and a system integrator in Ohio. That single image now sits under three overlapping compliance regimes, each written by a different body, for a different legal subject, with a different clock. The Cyber Resilience Act NIS2 IEC 62443 triangle is the most common source of confusion we see in vendor roadmaps, because teams treat the three as competing checklists when they are really three layers of one evidence chain.
It matters now because the CRA’s vulnerability and incident reporting duty started on 11 September 2026, the rest of the regulation bites on 11 December 2027, and NIS2 is already pushing your customers to ask for evidence you may not be producing. The expensive mistake is building three parallel programmes.
This post gives you a precise map: who each instrument binds, what it demands, where the obligations meet, and how to build one control set and one evidence pack that answers all three. It is analysis, not legal advice.
What this covers: the legal subject and scope of each regime, the CRA and NIS2 timelines as of October 2026, a control-by-control mapping table, a decision matrix by company role, failure modes, and a recommended 12-month plan.
Disclaimer: This article is technical and regulatory analysis for engineers and product-security leads. It is not legal advice. Confirm scope and classification with qualified EU counsel before relying on any reading here.
Context and Background
Start with the legal subject, because it explains everything else. The Cyber Resilience Act, Regulation (EU) 2024/2847, regulates products with digital elements: hardware and software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Its addressee is the manufacturer (plus importers and distributors), and its enforcement tool is market access: no CE marking, no sale in the EU. It is product law, in the same family as the Machinery Regulation and the Radio Equipment Directive.
NIS2, Directive (EU) 2022/2555, regulates entities: organisations in listed sectors (energy, transport, water, health, digital infrastructure, manufacturing of certain goods, and more) classed as essential or important based on sector and size. It demands risk-management measures, incident reporting and management accountability from the operating organisation. Because it is a directive, it only has effect through national transposition laws, which is why its status differs by country.
IEC 62443 is neither. It is a series of consensus industrial standards from the IEC, developed largely from ISA work, covering the whole OT security ecosystem: asset owners (2-x), integrators and system design (3-x), and component and product-development requirements (4-x). Nothing in it is legally binding by itself. Its force comes from contracts, procurement specifications, certification schemes such as ISASecure and IECEE, and, increasingly, from being the technical backbone that regulators point to. Our IEC 62443 zones and conduits primer covers the network-architecture side in depth; here we focus on how it plugs into the two EU instruments.
Put the three on one line and the roles become clear. The CRA asks whether the product is secure by design and supported over its life. NIS2 asks whether the operator manages cyber risk, including the risk that arrives through suppliers. IEC 62443 supplies the engineering language that lets a vendor prove the first and an operator do the second.
Two cautions up front. First, the three do not share a vocabulary: the CRA’s “manufacturer” can be your supplier, your customer or you; NIS2’s “supply chain” duty is the customer’s, but flows contractually to you. Second, the dates in this space moved repeatedly during 2025 and 2026, so every date below carries a verification note in the reference list. For the reporting mechanics specifically, we have a dedicated walk-through in EU Cyber Resilience Act 24-hour reporting for IIoT; this post stays at the mapping level.
The external anchor for all CRA statements is the Official Journal text of Regulation (EU) 2024/2847 on EUR-Lex, and for NIS2 the text of Directive (EU) 2022/2555.
One Product, Three Lenses: The Reference Architecture
The CRA binds the product and its manufacturer, NIS2 binds the operating organisation, and IEC 62443 is the technical standard that lets both sides produce comparable evidence. A vendor that builds to IEC 62443-4-1 and 4-2, adds CRA-specific items, and publishes a clear security-context document can answer all three regimes from one evidence base.
The mental model that works in practice is a chain of custody for security claims. The vendor makes claims about a product; the integrator makes claims about a system built from products; the asset owner makes claims about a facility; regulators audit each claim holder against their own law. IEC 62443 is organised around exactly those roles, which is why it maps so cleanly.
Figure 1: Who owes what to whom. The vendor’s technical file feeds the operator’s NIS2 supplier-risk evidence, and both are anchored in IEC 62443 artefacts.
The diagram shows three actors and two regulators. The vendor (CRA manufacturer) produces a product plus technical documentation, an SBOM and a vulnerability-handling process. The asset owner (NIS2 entity) consumes that evidence when it assesses suppliers under its own risk-management duty. Market surveillance authorities audit the vendor; national competent authorities and CSIRTs audit the operator. IEC 62443 certificates and reports sit in the middle as portable evidence both audiences can read.
The CRA: product obligations over the whole lifecycle
The CRA’s duties fall into four blocks. Design and build: the product must meet the essential requirements in Annex I Part I, which cover things like secure-by-default configuration, protection against unauthorised access, confidentiality and integrity of data, minimised attack surface, logging of security-relevant events and secure update capability. Vulnerability handling: Annex I Part II requires you to identify and document components and vulnerabilities (including a software bill of materials, SBOM, in a machine-readable format), fix vulnerabilities without delay, test regularly, run a coordinated vulnerability disclosure policy, and distribute security updates.
Support: Article 13 requires a support period that reflects the expected product lifetime and, as a floor, at least five years unless the product is expected to be used for less. For an industrial controller with a 15-to-20-year field life, this is a commercial commitment, not a footnote. Reporting: Article 14 requires manufacturers to notify actively exploited vulnerabilities and severe incidents through the ENISA single reporting platform to the designated national CSIRT, with an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report (14 days after a fix is available for vulnerabilities, one month after the incident notification for incidents).
Conformity route depends on classification. Most products fall in the default category and use internal control (self-assessment plus technical documentation and an EU declaration of conformity). Products in Annex III “important” Class I may use harmonised standards to self-assess or must go to a notified body; Class II requires third-party assessment; Annex IV “critical” products can be required to hold European cybersecurity certification. As far as I can tell from the Annex text, industrial controllers are not listed by name, but components such as firewalls, intrusion detection systems and certain security-bearing microcontrollers are, so a product that embeds such a function can be pulled upward. Classification is a legal judgement you should document explicitly.
NIS2: operator obligations that reach into the supply chain
NIS2 puts three duties on essential and important entities. Article 21 requires “appropriate and proportionate” technical, operational and organisational measures, with a minimum list of ten topics that includes incident handling, business continuity, supply chain security, secure acquisition, development and maintenance (including vulnerability handling and disclosure), cryptography, access control and multi-factor authentication. Article 23 requires incident reporting: early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Article 20 makes management bodies personally accountable for approving and overseeing the measures.
For a vendor, the key sentence is in Article 21(3): in assessing suppliers, entities must take into account vulnerabilities specific to each direct supplier and the overall quality of products and cybersecurity practices of suppliers, including their secure development procedures. That clause is why your customers now send questionnaires. NIS2 does not regulate you directly unless you are also in scope as an entity (a manufacturer in certain listed categories, a managed-service or cloud provider, or a provider of digital infrastructure). It regulates the buyer, and the buyer passes obligations down by contract.
IEC 62443: the engineering vocabulary
Four groups of the series matter here. 62443-2-1 defines the asset owner’s security management programme. 62443-3-2 covers security risk assessment and the partition of the system into zones and conduits. 62443-3-3 gives system security requirements organised under seven foundational requirements (FRs) with security levels SL 1 to SL 4. 62443-4-1 specifies the secure product development lifecycle (SDL), and 62443-4-2 the technical requirements for components: embedded devices, host devices, network devices and software applications.
The part that vendors tend to underweight is the security context: 62443-4-1 expects you to state the intended use and environment of the product, and that statement then drives which 4-2 requirements apply. The CRA has an equivalent in the risk assessment it requires you to document and update, and the European standardisation work is explicitly trying to align the two. Where the standards talk about “defence in depth”, the CRA talks about “appropriate level of cybersecurity based on risks”. The audit-ready link between them is a documented security context.
Figure 2: Order of work implied by the calendar. Reporting readiness comes first, because it is already enforceable; conformity evidence follows for December 2027.
The sequence in Figure 2 is the practical consequence of the calendar. Reporting capability is the only CRA obligation already live, so it is the first thing to prove. SDL and technical documentation have an effective deadline of 11 December 2027 for products placed on the market from that date, but your design decisions for next year’s hardware are being made now.
Deeper Analysis: Deadlines, Control Mapping and Role-Based Decisions
The calendar as of October 2026
The table below consolidates the dates that matter. Treat the status column as a snapshot: several items are still moving, and the reference list flags which were taken from secondary reporting rather than the Official Journal.
| Item | Instrument | Date or status (as of 4 Oct 2026) |
|---|---|---|
| Entry into force | CRA | 10 December 2024 |
| Conformity-assessment body notification rules (Chapter IV) | CRA | Applied from 11 June 2026 |
| Vulnerability and incident reporting (Article 14) | CRA | Applied from 11 September 2026, covering products already on the market |
| Full application, CE marking, Annex I essential requirements | CRA | 11 December 2027 |
| Harmonised standards (horizontal and vertical) | CRA | Under development; core horizontal drafts targeted for late 2026 after a reported two-month slip; none yet cited in the Official Journal per secondary sources |
| Transposition deadline | NIS2 | 17 October 2024 |
| National law status | NIS2 | Most Member States have national acts in force; a handful were still outstanding or referred to the Court of Justice in mid-2026 |
| IEC 62443-4-1 and 4-2 CRA amendments | CEN-CENELEC | EN IEC 62443-4-1 and 4-2 Amendment A11:2026 reported in preparation |
Two details deserve emphasis. First, Article 14 reaches products already on the market regardless of when they were placed there. A controller sold in 2019 that you still support is inside the reporting duty today, even though its design is not subject to Annex I until you place a new or substantially modified version on the market after December 2027. Second, because the harmonised standards are not yet in the Official Journal, presumption of conformity is not yet available through them. Until it is, your technical file must stand on its own reasoning, which is a strong argument for adopting IEC 62443 now as a defensible state-of-the-art baseline.
On NIS2, reports in mid-2026 indicate that the Commission escalated the first non-transposition cases to the Court of Justice after letters of formal notice in November 2024 and reasoned opinions in May 2025. The countries named differ between secondary sources, so I will not list them; check the Commission infringement register for the current state. The engineering consequence is simple: your customers in transposed countries are already under audit pressure, and your customers elsewhere will be soon. Do not plan on country-by-country timing.
Control mapping: one control, three citations
The table below is the working artefact we recommend building. Each row is a control your product or process either has or lacks. The columns show where each regime asks for it. It is a mapping aid based on the structure of the texts, not an official crosswalk; the formal CEN-CENELEC alignment work is still in progress.
| Control or evidence item | CRA anchor | NIS2 anchor | IEC 62443 anchor |
|---|---|---|---|
| Secure development lifecycle with documented practices | Annex I Part I, technical documentation | Art 21(2)(e) secure development and maintenance | 62443-4-1 practices 1 to 8 |
| Threat model and documented risk assessment | Art 13(2) cybersecurity risk assessment | Art 21(1) risk analysis | 62443-4-1 SR/SD practices, 3-2 for system level |
| Secure-by-default configuration, no default passwords | Annex I Part I | Art 21(2)(i) access control | 62443-4-2 CR 1.x identification and authentication |
| Access control and authentication for users and services | Annex I Part I | Art 21(2)(i), (j) MFA | 62443-3-3 FR 1 and FR 2, 4-2 CR 1 and CR 2 |
| Data confidentiality and integrity in transit and at rest | Annex I Part I | Art 21(2)(h) cryptography | FR 3 and FR 4, 4-2 CR 3 and CR 4 |
| Logging of security events | Annex I Part I | Art 21(2)(b) incident handling | FR 6, 4-2 CR 6 |
| SBOM and component inventory | Annex I Part II(1), Art 13(5) | Art 21(3) supplier quality | 4-1 SM practice on third-party components |
| Coordinated vulnerability disclosure policy | Annex I Part II(5) | Art 21(2)(e) vulnerability handling and disclosure | 4-1 practice 6 issue and defect management |
| Security update delivery, signed and verifiable | Annex I Part I and II(7), (8) | Art 21(2)(e) maintenance | 4-1 practice 7 patch management, 4-2 CR 3.10 support for updates |
| Support period and end-of-life policy | Art 13(8) minimum five years | Art 21(2)(d) supply chain continuity | 4-1 update management and security guidelines practices, covering support and end-of-support guidance |
| 24 hour, 72 hour, 14 day reporting process | Art 14 | Art 23 (operator side) | 4-1 practice 6 and 2-1 incident response |
| Network segmentation guidance for the integrator | Instructions for use, Annex II | Art 21(2)(a) risk and security policies | 3-2 zones and conduits, 3-3 FR 5 |
A few mappings are looser than they look. IEC 62443-4-2 is a component standard: it tells you what a PLC, gateway or HMI must implement, but it assumes a deployment context in which the integrator provides network segmentation and the owner runs a security programme. The CRA has no such assumption. It requires the product to be secure on its own terms, within its stated intended use. That gap is why the standardisation work is adding requirements to 4-2 rather than declaring it sufficient as is.
Figure 3: One control set, three outputs. A single maintained IEC 62443 control baseline produces the CRA technical file, the NIS2 supplier evidence pack and the integrator’s system documentation.
Where the regimes genuinely diverge
Three differences cannot be mapped away. Subject and sanction: the CRA sanctions with market withdrawal and fines of up to EUR 15 million or 2.5% of worldwide annual turnover for breaches of the essential requirements and core manufacturer obligations (lower tiers of EUR 10 million or 2%, and EUR 5 million or 1%, apply to other failures such as incorrect information). NIS2 fines for essential entities reach EUR 10 million or 2%, and for important entities EUR 7 million or 1.4%, at the Member State level, with management liability on top. IEC 62443 has no sanction beyond lost contracts.
Timing of reporting: both the CRA and NIS2 use the 24-hour, 72-hour and final-report pattern, but the triggers differ. The CRA triggers on an actively exploited vulnerability or a severe incident having an impact on the security of the product; NIS2 triggers on a significant incident at the entity. One event can therefore start two clocks owned by two different organisations: your vendor clock and your customer’s operator clock. The pragmatic rule is to give customers a heads-up fast enough that their own 24-hour window is realistic.
Evidence type: the CRA wants technical documentation held for at least ten years after placing on the market or the support period, whichever is longer, plus an EU declaration of conformity. NIS2 wants records of measures and the ability to demonstrate them to a competent authority. IEC 62443 certification (for example ISASecure SDLA for the lifecycle or CSA for components, or IECEE CB scheme certificates) gives you an external attestation, which is useful but is not a CRA conformity assessment. Under the CRA, only the routes in Article 32 count, and a certificate from a recognised scheme currently supports your file rather than replacing it.
Decision matrix by company role
Different companies sit in different places on the map. Use this matrix to decide where to spend first.
| Your role | CRA exposure | NIS2 exposure | IEC 62443 emphasis | First priority |
|---|---|---|---|---|
| Component or device maker (PLC, gateway, sensor) | Manufacturer, full duties | Indirect through customers; direct if in scope as a manufacturer category | 4-1 and 4-2 | Reporting process, SBOM, support-period policy |
| Software or firmware vendor (SCADA, HMI, edge runtime) | Manufacturer if sold as a product | Indirect; direct if you run a cloud or managed service | 4-1, 3-3 capability | CVD policy, signed updates, SBOM |
| System integrator | Importer or distributor only in some cases; manufacturer if you rebrand or substantially modify | Supplier to essential entities | 3-2, 3-3, 2-4 | Zone and conduit design records, third-party component due diligence |
| Asset owner or operator | Not a manufacturer unless you build products | Essential or important entity | 2-1, 3-3 target levels | Supplier-risk programme, 24/72-hour operator reporting |
| Managed or cloud service provider for OT | Remote data processing solution may count as part of a product | Direct entity (digital infrastructure and ICT service management) | 2-4 service provider requirements | Contractual evidence flow, incident coordination |
The row that causes the most surprises is the integrator. If you substantially modify a product (for example flash custom firmware that changes its security-relevant behaviour), you can be treated as the manufacturer of the modified product. That makes a design decision about “just customising the firmware” a regulatory classification decision.
A worked example (illustrative numbers)
Consider a hypothetical vendor with four product families: a gateway, a PLC series, an HMI runtime and a cloud connector. Suppose each has about 180 third-party components on average, a figure chosen purely to illustrate scale. That is roughly 720 component entries across four SBOMs to maintain. If the team processes advisories weekly and each family sees on average two relevant advisories per month, the vendor triages around eight per month or about 100 per year before it deals with its own findings.
Now overlay the reporting clock. Suppose one advisory in the year is an actively exploited vulnerability in an embedded library. The 24-hour early warning goes out on day one with the affected product and Member States. The 72-hour notification describes the vulnerability, corrective measures and mitigations. If the patch ships on day 20, the final report is due by day 34 (14 days after the corrective measure is available). Meanwhile each customer in NIS2 scope may have to decide whether the event is a significant incident for them, which starts their own 24-hour window. The elapsed work is not the regulation; it is the coordination. That is why the reporting process is a drill, not a document.
Trade-offs, Gotchas, and What Goes Wrong
Treating IEC 62443 certification as CRA compliance. This is the most common and most costly assumption. An ISASecure or IECEE certificate evidences a lot, but the CRA requires its own technical documentation, EU declaration of conformity, a defined support period, user-facing instructions and a reporting capability. Current harmonised-standard work suggests 62443 content will feed into the CRA presumption of conformity through amendments, but until a standard is cited in the Official Journal, a certificate is supporting evidence. Budget for the gap analysis, not for a logo.
Reporting without a trigger definition. The CRA does not require you to report every vulnerability. It requires reporting of vulnerabilities you have reliable evidence are being actively exploited, and of severe incidents. Teams that skip writing down what counts as “awareness” and “reliable evidence” end up either over-reporting everything (burning goodwill and analyst time) or under-reporting through delay. Write the decision criteria, name the on-call owner, and rehearse the 24-hour step with a fake event. The clock starts at awareness, and “we were still triaging” is a weak argument if your internal ticket shows you knew.
SBOM as a file instead of a process. Annex I Part II requires you to identify and document components and vulnerabilities. An SBOM generated once at release and never matched against advisories satisfies neither the letter nor the purpose. The failure mode is stale inventories: firmware images built from vendored libraries where the SBOM lists the upstream version but the build patched or forked it. Generate SBOMs from the build, sign them, and tie them to the release artefact. Our piece on SLSA and Sigstore supply-chain architecture covers the provenance side of this.
Figure 4: The reporting path for an actively exploited vulnerability, including the parallel customer notification that feeds the operator’s own NIS2 clock.
The sequence in Figure 4 highlights the part teams forget: the customer notification. The CRA requires you to inform affected users, and your NIS2-regulated customers need that information fast to decide whether they have a reportable incident of their own. Treat customer comms as an output of the same workflow, with the same owner.
Support-period optimism. A five-year minimum is easy to meet on paper and expensive to meet in practice for products with long field lives. Every year of promised support is a year of backporting security fixes to old branches, retaining build toolchains, and keeping signing infrastructure alive. If your embedded OS or SDK vendor ends support before you do, you have inherited a gap. Check third-party end-of-life dates against your support commitments before you publish them.
Overlapping notifications and the single-platform promise. The ENISA single reporting platform is meant to reduce duplicate reporting, and the European Commission’s Digital Omnibus proposal from late 2025 aims at a broader single entry point across cyber and data-protection reporting. As of this writing, I could not verify that any of that is adopted law, so assume the current separate flows remain: CRA through ENISA and your CSIRT, NIS2 through the operator’s national authority, GDPR through the data-protection authority where personal data is involved.
Customisation as hidden manufacturing. Integrators and OEMs who rebrand or rework firmware may become manufacturers under the CRA. A “small customisation” that changes security-relevant behaviour is a substantial modification and triggers a fresh conformity assessment. Define internally what counts as substantial, and route those changes through the same release gate as a new product.
What not to do. Do not build a separate NIS2 supplier questionnaire response library, a separate CRA file and a separate 62443 binder. They will drift apart within a quarter. The control mapping in Figure 3 exists so that every claim has one owner and one source of truth, with views generated for each audience.
Practical Recommendations
Start with what is already enforceable. Reporting under Article 14 is live, so the first deliverable is a tested process, not a policy: who detects, who decides “actively exploited”, who files through the ENISA platform, who informs customers, and who writes the final report. Assign an owner and put the drill in the calendar quarterly.
Second, adopt IEC 62443-4-1 as your SDL baseline and map it to the CRA Annex I lists in one document, as in the control table above. Gaps will appear at the edges: the CRA’s explicit support-period, user-instruction and data-deletion expectations, and the requirement that the product is secure within its stated intended use rather than relying on integrator controls. Close those gaps in your own SDL rather than waiting for the amended standards.
Third, make classification a recorded decision. For each product family, document whether it falls under the default category, Annex III Class I or II, or Annex IV, with the reasoning and the date. Revisit it when you add a security function such as a firewall feature or a secure element.
Fourth, build the customer-facing evidence pack once. It should contain the security-context statement, SBOM format and delivery method, vulnerability disclosure policy and contact, support period, update and signing method, and a summary of your 62443 certification status. Your NIS2-regulated customers will ask for exactly this under Article 21(3), and sales engineers should not be assembling it ad hoc.
Fifth, review contracts. Add the reporting handshake, update cadence and end-of-support notice period to supplier and customer agreements, and align them with your support commitments.
12-month checklist
- [ ] Reporting runbook written, owner named, tabletop drill completed
- [ ] Triage criteria for “actively exploited” and “severe incident” documented
- [ ] ENISA platform access and the authorised representative set up
- [ ] Product-by-product CRA classification recorded with reasoning
- [ ] SBOMs generated from the build, signed, and matched to advisories continuously
- [ ] Public coordinated vulnerability disclosure policy and security contact live
- [ ] Support period per product published and checked against third-party end-of-life dates
- [ ] IEC 62443-4-1 gap assessment done; 4-2 capability assessment on flagship components
- [ ] Single control-mapping spreadsheet or tool covering CRA, NIS2 supplier evidence and 62443
- [ ] Customer evidence pack and contract clauses ready before December 2027 designs freeze
- [ ] Watch list: harmonised standards in the Official Journal, Commission guidance and FAQ updates, national NIS2 laws in your key markets
Frequently Asked Questions
Does the Cyber Resilience Act replace NIS2 or IEC 62443?
No. The CRA regulates products and their manufacturers, NIS2 regulates operating entities in listed sectors, and IEC 62443 is a voluntary technical standard series. They are complementary: the CRA is explicit that it applies alongside NIS2. IEC 62443 is not legally binding on its own, but it is the most widely used way to demonstrate secure development and component capability, and European standardisation work is adapting parts of it for CRA use. Expect to satisfy all three with a shared control set.
When do CRA obligations actually start for OT and IoT vendors?
The CRA entered into force on 10 December 2024. Vulnerability and incident reporting under Article 14 has applied since 11 September 2026, including to products already on the market. The main obligations, Annex I essential requirements, conformity assessment and CE marking, apply from 11 December 2027 to products placed on the market from that date. Rules on notified bodies applied earlier, from 11 June 2026. Dates have been discussed for adjustment in secondary reporting, so verify against the Official Journal.
Is a PLC or industrial gateway in scope of the CRA?
Generally yes. Hardware or software with a direct or indirect data connection falls within “products with digital elements”, and industrial devices with network interfaces qualify. Exclusions cover products governed by specific sectoral rules such as medical devices, motor vehicles and aviation, plus certain defence and national-security products, spare parts and unfinished software. Most industrial devices go through the default internal-control route unless they embed a function listed in Annex III or IV, so classification should be documented per product.
Are IoT and OT vendors directly subject to NIS2?
Only in some cases. NIS2 applies to essential and important entities in listed sectors by size. A device vendor is usually affected indirectly, because its customers must manage supplier risk under Article 21(3) and pass requirements down by contract. A vendor can be directly in scope if it falls in a covered category, for example certain manufacturing sectors, or if it runs a cloud, managed or digital-infrastructure service. Check each national transposition law, since scope can vary in detail.
Does IEC 62443 certification prove CRA conformity?
Not by itself. An IEC 62443-4-1 or 4-2 certificate shows that your lifecycle or component meets a recognised standard, which supports your technical file and customer assurance. The CRA conformity route is set in Article 32 and still requires technical documentation, a declaration of conformity and, for higher classes, third-party assessment or European certification. Once harmonised standards are cited in the Official Journal, conformity to them will give a presumption of conformity; until then 62443 is strong supporting evidence.
What are the penalties for non-compliance?
Under the CRA, breaches of the essential requirements and core manufacturer obligations can draw fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher, with lower tiers of EUR 10 million or 2% and EUR 5 million or 1% for other failures, plus corrective measures and market withdrawal. NIS2 sets maximums of at least EUR 10 million or 2% for essential entities and EUR 7 million or 1.4% for important entities, enforced nationally. IEC 62443 carries no legal penalty.
Further Reading
- IEC 62443 zones and conduits explained, the system-design side of the standard
- EU Cyber Resilience Act 24-hour reporting for IIoT, the reporting workflow in detail
- AI model supply chain security and provenance, provenance thinking that carries over to firmware and models
- Agentic AI security and prompt injection, the emerging threat surface for connected products
- Third-party zero-day and exchange security architecture, a case study in supplier-risk failure
- Regulation (EU) 2024/2847 on EUR-Lex and ENISA cybersecurity resources
References
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the EU, 20 November 2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- Directive (EU) 2022/2555 (NIS2), Official Journal of the EU, 27 December 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- IEC 62443 series, International Electrotechnical Commission / ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
- CEN-CENELEC, “EN IEC 62443 to CRA” event page, September 2025. https://www.cencenelec.eu/news-events/events/2025/2025-09-09-en-iec-62443-to-cra
- IBF Solutions, “Current status of standardisation for the Cyber Resilience Act” (secondary source for standards deadlines).
- cyberresilienceact.eu, “Where the CRA stands today” (independent guide; secondary source for ENISA platform and guidance status).
- NIS2 transposition trackers (nisd2.eu, compliancehub.wiki), secondary sources for national status and CJEU referrals, mid-2026.
By Riju – about
