Introduction

Under the EU Cyber Resilience Act (CRA), product classification drives the compliance path—including the depth of required evidence and whether conformity can be supplier-led or requires third-party involvement. This post explains why programmable logic controllers (PLCs) used in operational technology (OT) environments are generally not “Hardware Security Boxes” (HWSBs): the deciding factor is a product’s intended primary purpose, not the mere presence of cryptographic components. It then translates that classification logic into what PLC suppliers should prioritize for CRA readiness: mapping to the CRA essential cybersecurity requirements and maintaining an audit-ready risk assessment and evidence package.

Executive summary: PLCs are generally not “Hardware Security Boxes” under the CRA, but that does not make compliance trivial. Many PLC portfolios are more plausibly treated as Important products (Type I or Type II) depending on the specific product type and intended use. The leadership focus should be on demonstrable compliance: a clear classification rationale, an Annex I essential-requirements mapping, and a maintained cybersecurity risk assessment that drives secure development, vulnerability handling, and security update delivery.

What Is a Hardware Security Box (HWSB) Under the CRA?

European standards bodies are still refining how Hardware Security Boxes (HWSBs) should be defined and evaluated. In practice, an HWSB is a high-assurance, tamper-resistant device built to protect sensitive cryptographic material (such as private keys) and to perform critical cryptographic operations inside a protected boundary. HWSBs are listed in Annex IV of the CRA and are therefore classified as Critical—which typically triggers a third-party assessment compared to supplier-led self-assessment.

Source

Primary reference: CEN-CENELEC “CRA Standards Unlocked” webinar series, including the session “CRA Standards Unlocked: Cybersecurity Requirements for Hardware Devices with Security Boxes” (8 January 2026).

CENELEC is a major European standards body for electrotechnical products. For industrial automation, its work can influence harmonized standards and technical expectations used to demonstrate CRA conformity.

Why PLCs Are Not Hardware Security Boxes

Many modern PLCs include security capabilities (secure boot, cryptography, trusted storage, firmware integrity). That can create a legitimate classification question: are these devices becoming “security products,” or are they still primarily industrial control products with security features?

The core distinction is intent. A PLC’s primary purpose is to run control logic and operate industrial processes. An HWSB’s primary purpose is to act as a hardware-rooted trust anchor—protecting cryptographic keys and performing security-critical cryptographic operations inside a physically protected boundary. Under the CRA, that difference in intended primary purpose is a central input to classification.

A second, practical lens is context: many products with cryptography are still governed by their sector’s standards and intended use. The same logic applies to PLCs—typically keeping them in the OT/industrial domain rather than reclassifying them as dedicated hardware security devices.

What Makes an HWSB Distinct

HWSBs are engineered so that the physical enclosure is part of the security control—designed to deter, resist, or detect tampering—and so that sensitive operations (key generation, signing, decryption, etc.) stay inside that protected boundary. This design expectation is fundamentally different from most PLC deployments, where physical tamper resistance is not the product’s principal objective.

Common components inside that boundary can include secure key storage, tamper response, hardware random number generation, and dedicated cryptographic processing.

Although many embedded and industrial devices contain similar building blocks, the defining characteristic of an HWSB is that the system exists primarily to protect cryptographic material and enforce trust for security-critical operations—in other words, security is its principal objective. Technical specifications alone are insufficient to determine classification; the intended primary purpose is the deciding factor.

PLC Classification Under the CRA: Likely Important Type I or Type II

For many PLC portfolios, the more realistic CRA question is not “default vs. critical,” but whether the PLC falls under Important Type I or Important Type II based on the specific product type and intended use described in CRA Annex III. While the exact classification is product-specific, the execution pattern is consistent: (1) meet the CRA essential cybersecurity requirements (CRA Annex I) and (2) maintain a documented cybersecurity risk assessment that drives design, development, delivery, and maintenance (CRA Article 13(2)).

• Confirm classification early: determine whether the PLC aligns to Important Type I or Important Type II (CRA Annex III) and document the rationale, assumptions, and boundaries of intended use.
• Build an Annex I controls map: show how the PLC meets the CRA essential cybersecurity requirements (secure-by-design and secure-by-default, protection against known vulnerability classes, vulnerability handling, and secure updates).
• Maintain the CRA cybersecurity risk assessment: document the risk assessment required by CRA Article 13(2), keep it current, and ensure it directly informs security requirements, design decisions, and update strategy.
• Be evidence-ready: maintain an audit-ready conformity file (technical documentation, policies, test results, update and vulnerability-handling records) sized to an Important classification.

Conclusion

CRA classification is a product decision with direct cost, schedule, and evidence implications—not a paperwork exercise. For PLCs, the key point is that they are industrial control products (not HWSBs), yet many will still align to an Important category (Type I or Type II) based on the specific product type and intended use. The practical path to readiness is consistent: engineer to the CRA Annex I essential cybersecurity requirements, maintain a living Article 13(2) cybersecurity risk assessment that drives requirements and design tradeoffs, and be able to produce an audit-ready conformity file that demonstrates secure development, vulnerability handling, and dependable security updates across the product lifecycle.