Few questions in industrial cybersecurity generate as much confusion as the classification of programmable logic controllers (PLCs) under the EU Cyber Resilience Act (Regulation (EU) 2024/2847). Ask ten engineers, compliance leads, or notified-body consultants whether a PLC is Class I or Class II, and the answers will diverge — often sharply, and often with each side citing the same regulation.

The disagreement is not accidental. It reflects a genuine tension in how practitioners read the CRA: one camp insists that risk is the decisive factor, another that risk alone cannot determine class. Both positions are defensible in isolation, and both are incomplete. The CRA does not resolve PLC classification in a single step; it resolves it in a sequence, and mixing the steps together is the source of nearly every misclassification argument in circulation today.

This post sets out that sequence. Rather than asking the single, overloaded question — "what class is my PLC?" — the analysis proceeds through three distinct gates:

→ First, is the product within the scope of the CRA at all?

→ Second, if so, does it fall within a listed category under Annex III (Important) or Annex IV (Critical)?

→ Third, and only if Annex III applies, which class is its category in?

Kept in order, these questions yield a defensible classification for an ordinary PLC. Collapsed into one, they yield the contradictions that dominate current industry debate. What follows works through each gate in turn, identifies where risk legitimately enters the analysis, and explains why the correct answer for most PLCs is neither Class I nor Class II — but a default classification carrying a high-assurance obligation.

"Class I or Class II" lives in Annex III only

Quick map of the annexes, because the labels get mixed up constantly:

• Annex I — the essential cybersecurity requirements and manufacturer process requirements.
• Annex II — user information and instructions. Not a class.
• Annex III — Important products with digital elements, split into Class I and Class II.
• Annex IV — Critical products with digital elements.

So "Class I vs Class II" is an Annex III question and nothing else. If a product isn't in Annex III or IV, the CRA doesn't vanish — the product is simply a product with digital elements that is neither Important nor Critical (informally, the default category). Default means "not specifically listed," not "low security." A PLC can be default and still carry a severe risk profile. Within Annex III, Class I and Class II are two tiers of the same list: both are Important products and both must meet the same Annex I requirements, but the tier sets the conformity-assessment route. Class I allows self-assessment if the manufacturer meets certain conditions; Class II covers categories whose compromise would do more damage, and requires third-party involvement. Annex III fixes which tier applies.

A PLC is not a listed product by name

The approved CRA does not list PLCs anywhere in Annex III, and does not list them in Annex IV either. "Industrial controller" does not automatically mean "higher class." The word PLC answers nothing — you classify by the product's legal characteristics, not market shorthand.

Annex IV (Critical) is the easy ruling. Annex IV lists categories like Hardware Devices with Security Boxes, smart meter gateways, and smartcards/secure elements. PLCs aren't there. A PLC isn't promoted to Critical just because it contains secure boot, crypto, or trusted storage — the CRA doesn't classify by component. For an ordinary PLC, Annex IV is a quick no. 

The Annex III gate is core functionality

Once Annex IV is out, the next question is not "Class I or II." It's whether the product enters Annex III at all.

Article 7(1) is the gate: a product is Important only if it has the core functionality of an Annex III category. No core-functionality match, no Annex III — and the Class I/II question never opens. A product can be operationally critical, safety-relevant, and high-consequence in the field and still fail this test if its core function doesn't match a listed category.

The 2025 technical descriptions (Implementing Regulation (EU) 2025/2392) help here. Recital 7 says the examples in those descriptions are illustrative, not exhaustive. A product need not be named in the examples to fit a category, but the category list itself is fixed.

One more point on embedded parts: Recital 45 of the CRA (core functionality is the test — a product that merely integrates a firewall or IDS is not thereby Important), reinforced by recitals 4 and 5 of the Implementing Regulation, confirms that embedding an Important function or component does not reclassify the host if the host as a whole lacks that core functionality. Similar architecture is not the test. Core functionality is.

Where risk actually fits

The CRA uses "risk" in three places — keep them separate:

Article 13(2)–(3): every covered product needs a documented cybersecurity risk assessment, Annex III or not. This is general, and it does not create Annex III status.

Article 7(2)(b): the significant risk of adverse effects (harm to many other products, or to users' health, security or safety) explains why certain categories are listed as Important. It justifies the list; it does not turn a high-impact product outside the listed categories into an Important one.

Recital 44: explains why Annex III has two classes — a Class II incident may cause greater harm. The split is set in Annex III, not product by product.

So both slogans are true: risk matters (it drives the Article 13 risk assessment and the whole Annex I security case), and risk alone doesn't create Annex III status or decide the class (that's core functionality and the Annex III list).

Default classification, high-assurance treatment

Here's the part industrial teams need. The CRA does not set lighter requirements for default-category products. The essential requirements in Annex I apply across the board; what scales with risk is how demanding the implementation and evidence must be.

So, a PLC can be legally default category and still need an assurance posture as rigorous as what people associate with Class II — because Article 13 forces the manufacturer to act on the risk assessment across the full lifecycle, and Annex I demands a level of cybersecurity appropriate to the risk. Article 32 even lets a manufacturer choose a heavier conformity route voluntarily.

What the CRA does not support is calling that product "Class II" when Annex III doesn't apply. The right framing is a risk-based assurance decision, not a legal reclassification. Classification isn't permanent either: under Article 7(3) the Commission can amend Annex III, normally with at least 12 months' transition, so re-check default products when it changes.

A genuine Class II conclusion needs one thing: the product's core functionality matches a Class II category in Annex III. Once listed, it can't be argued out on risk. Article 7(2)(b) and Recital 44 explain why the category is listed. That's a far stronger statement than "PLCs are high risk, so Class II."

Why the route / class matters

Per Commission conformity-assessment guidance: Annex III Class I products may use the internal route (internal control, where the manufacturer self-assesses against the requirements and no notified body is involved) only if the manufacturer applies harmonized standards, common specifications, or an applicable EU cybersecurity certification scheme — otherwise third-party assessment is required. Class II drops the internal option entirely: third-party assessment, or a certification scheme where available. That's why the Class I/II line is commercially material — it changes the assurance path.

Where IEC 62443 fits

IEC 62443 does not decide classification — that's CRA text only. What it does is show how the essential requirements can be met: 62443-4-1 for the secure development lifecycle, 62443-4-2 for IACS component controls, and it's getting more direct: CEN-CENELEC is adapting EN IEC 62443-4-1 and -4-2 for CRA alignment, and once harmonized references are published in the Official Journal, conformity with them supports a legal presumption of conformity.

Bottom line

Run classification steps in order — rule out Annex IV, test Annex III by core functionality, and if a category matches, take the class from Annex III. If Annex III doesn't fit, keep the default classification but let the Article 13 risk assessment drive a high-assurance build where risk demands it.

Default classification, high-assurance treatment. That's the position worth defending to a customer, a notified body, or a regulator.

References: Regulation (EU) 2024/2847 (CRA); Commission Implementing Regulation (EU) 2025/2392; European Commission — CRA Conformity Assessment and CRA Standardisation guidance; IEC 62443-4-1, -4-2, CEN-CENELEC EN IEC 62443 → CRA work.