Threat and Risk Assessment under IEC 62443: Method, Evidence, Common Gaps

Almost every company that builds field devices has a threat and risk assessment. Far fewer have one that survives an audit. The difference rarely lies in the method — it lies in whether the analysis can still be traced at the time of the review: which version applies, what the risk decision was based on, and whether anything was changed after approval.

This article explains how an assessment under IEC 62443 is structured methodically, which additional obligations the Cyber Resilience Act brings, and where it tends to break down in practice.

Two perspectives that are often confused

IEC 62443 is a series of standards, not a single standard — and its parts address different roles. For risk assessment, two viewpoints are relevant:

Plant perspective (62443-3-2): An asset owner or integrator looks at a System under Consideration, partitions it into zones and conduits, and assesses the risks of that structure.
Product perspective (62443-4-1 / 4-2): A device manufacturer looks at its product — the development process that systematically produces security (4-1), and the technical requirements the device must meet (4-2).

If you build devices, you primarily work in the second world. The process of 62443-3-2 is still instructive, because it demonstrates cleanly how a risk assessment proceeds in a structured way — and because your customers will ask questions based on exactly this logic.

The structured process: seven steps

IEC 62443-3-2 (Edition 1.0, 2020-06) describes the risk assessment as a sequence of seven steps, the Zone and Conduit Requirements (ZCR):

Step	Content
ZCR 1	Identify the System under Consideration — architecture and asset inventory
ZCR 2	Initial risk assessment
ZCR 3	Partition into zones and conduits
ZCR 4	Decision: does the initial risk exceed the tolerable risk?
ZCR 5	Detailed risk assessment (if yes)
ZCR 6	Derive the Cybersecurity Requirements Specification
ZCR 7	Approval

The overarching principle for the partitioning is explicitly the risk assessment itself (ZCR 3.1) — not the network topology and not the organization chart.

The real value of this process lies in step 4. It forces an explicit statement about what counts as tolerable. This is exactly the statement missing from most of the analyses we come across — and without it, every prioritization that follows is a matter of taste.

Assessing risk means keeping two quantities separate

A risk is not a number that falls from the sky, but the interplay of likelihood and impact. Both are determined separately and only combined at the end — typically via a matrix, not a formula.

For the likelihood side there is an established, traceable methodology: the attack potential rating from the Common Criteria methodology, published as the international standard ISO/IEC 18045. It breaks the question "how realistic is this attack?" down into five factors — elapsed time, specialist expertise, knowledge of the target of evaluation, window of opportunity and equipment — and turns the estimate into a reproducible calculation instead of a gut feeling.

On the impact side, it pays to separate categories — safety, financial damage, operational disruption, legal consequences, data protection. Especially for devices with a safety-related function, the safety category is where security analysis and functional safety meet: a loss of integrity there is not purely an IT problem, but can disable the protective function itself.

What the Cyber Resilience Act adds

The CRA turns good practice into an obligation — with two dates that mean different things:

11 September 2026: The reporting obligations apply. Actively exploited vulnerabilities and severe security incidents must be reported to ENISA and the competent national CSIRT — including for products that are already on the market. There is no transition period here.
11 December 2027: The remaining obligations apply in full — the essential cybersecurity requirements of Annex I, conformity assessment, technical documentation, EU declaration of conformity and CE marking.

For risk assessment, the second date is the more relevant one: the risk assessment is not an optional extra, but part of the chain of evidence on which the declaration of conformity rests. Whatever you sign, you must be able to justify.

The four gaps that stand out in an audit

Four patterns recur across our assessments:

The analysis is a document, not a state. It was created once, usually before a release, and never touched again. The product has changed three times since. At the audit, the formally valid version does not describe the current firmware.

The rating is not reproducible. Risks carry values like "high", but nobody can say how that value came about. Two people on the same team would reach different results — that is not a rating scale, it is an opinion with a color code.

Coverage is claimed, not proven. Every requirement has a checkmark, but no activity that backs it. The question "which concrete measure covers this requirement, and where is its result?" remains unanswered.

Process maturity and implementation diverge. The development process according to 62443-4-1 is documented in exemplary fashion — but the corresponding technical requirement from 62443-4-2 has not been verified in the device. This gap is the most expensive one, because it only surfaces when someone examines the product itself rather than the filing cabinet.

What follows from this

A robust threat and risk assessment is less a question of choosing a method than of staying power. It needs an explicit risk acceptance threshold, a reproducible rating methodology, a traceable link from requirement to evidence — and a mechanism that keeps all of this current when the product changes.

The method for this has been available and well documented for years. What fails in practice is almost never the procedure, but the question of where the current state lives and who maintains it.

Sources

This article was originally published in German on the Alsensio Cybersecurity Hub.