IEC 62443-Style Risk Assessment for CAN Systems
IEC 62443-3-2 specifies the risk-assessment process expected of industrial automation and control systems. Applied to CAN-based products, the same eight-step process gives manufacturers and integrators a defensible structure for the documentation that CRA Article 13 requires. The assessment is not a one-time deliverable; it is a living record that follows the product through its lifecycle. The full walk-through, with worked examples and the supporting risk and traceability matrices, is taught in the EmSA CRA Planning and CAN Risk Assessment course. This page summarizes the steps and the CAN-specific judgment calls. Per-finding vulnerability scoring with CVSS is a separate activity, addressed on the sibling CVSS for CAN page. IEC 62443-3-2 CRA Art. 13 CRA Annex I
Why a Methodology Helps
The CRA does not prescribe a specific risk-assessment method. Manufacturers can choose any established approach, and where a safety risk-assessment process is already in place, it can usually be extended rather than replaced. Several frameworks are in common use, each shaped by the sector it grew up in:
- ISO/IEC 27005 — information-security risk management. IT-leaning, oriented to enterprise information assets rather than control-system equipment.
- NIST SP 800-30 — US federal guidance for information-system risk assessments. Documentation-heavy, common in government and government-supplier contexts.
- ISO/IEC 27019 — energy-sector control-systems overlay on ISO/IEC 27002. Useful where the deployment is specifically a power-utility installation.
- EN 18031-1/-2/-3:2024 — harmonized standards under the Radio Equipment Directive 2014/53/EU as activated for cybersecurity by Commission Delegated Regulation (EU) 2022/30. The standards include their own risk-assessment and risk-reduction process for connected radio equipment. Relevant for CAN-based products that include a radio module: per CRA Article 2(3), products already covered by the RED Delegated Regulation for the same essential requirements run a RED / EN 18031 assessment instead of a CRA one.
- IEC 62443-3-2 — the system-level risk-assessment process from the IEC 62443 series for industrial automation and control systems. Chosen as the basis for this reference because it is mature, recognized by most notified bodies for industrial CAN, and produces the structured artifact CRA Article 13 expects: a traceable analysis from assets through threats, mitigations, and residual risk.
This page describes the IEC 62443-3-2 risk-assessment
process.
A Living Record, Not a One-Off
A frequent misconception is that the risk assessment is something written once at release and filed away. The CRA explicitly rejects that view. The technical documentation evolves as the product evolves: when firmware changes, when new vulnerabilities are reported, when the threats facing the product shift, when connectivity is added or removed. Each significant change triggers a re-evaluation, and a new revision of the assessment must be generated and recorded.
Vulnerability reports and the actions taken to resolve them belong in the same record, along with firmware-version logs, SBOM revisions, and the audit trail of who changed what and when. Earlier revisions are archived so that any past decision or design state can be reconstructed if questioned later. Treating the assessment as a living document is the cheapest way to be ready for an audit at any time, and it is the only way to honor the CRA's expectation of ongoing vulnerability handling for as long as the product is supported.
The Eight Steps
The
IEC 62443-3-2 risk-assessment process is conventionally
described as eight ordered steps. The earlier steps frame what
is being protected from what threats; next you determine your
security objectives and analyze & assess the risks; the
later steps identify, select, apply, and verify the security
measures applied. Each step builds on the one before it, and
each output feeds the next. Whenever the final outcome is
undesirable (because mitigations don't hold or new risks
appeared), the process is triggered again.
For CRA documentation it is beneficial to show that this is a
process and mitigations improve over time.
1. Identify Assets
List the hardware, firmware, software, configuration, and (where applicable) data elements that warrant protection. For a typical CAN device, that includes the housing, the MCU, external non-volatile memory, the power-supply circuitry, the CAN and UART circuitry, the debug interfaces (JTAG, SWD), the bootloader, the higher-layer protocol stack, the application firmware, and any configuration parameters that survive a power cycle. Whether stored or transmitted data is itself an asset depends on the application: process data and operational telemetry can be high-value when they drive fiscal decisions, quality-control feedback, access-control logic, or safety functions, and effectively zero-value otherwise. The decision is documented either way.
2. Identify and Analyze Threats
For each asset, list the realistic ways it can be compromised. The CAN bus itself faces sniffing, frame injection, spoofing, replay, and flooding. Debug ports face firmware extraction and debug-level control. The bootloader faces downgrade attacks and malicious-firmware uploads. Configuration storage faces malicious remapping and overwrite. Hardware faces tampering, replacement, and side-channel attacks such as voltage glitching. The same threat may apply to several assets; one asset may face several threats. Nothing should be left without at least one corresponding threat entry.
3. Determine Security Objectives
For each asset and threat, state what must hold. Tamper detection on the housing, code-and-memory protection on the MCU, integrity and confidentiality on stored configuration, authenticated firmware update on the bootloader, message-level access control on the higher-layer protocol stack. Some objectives are met inside the device; others must be addressed at integration. Locked debug interfaces are the manufacturer's responsibility; physical enclosure is the integrator's. The split is recorded explicitly so the integrator knows exactly what residual obligation lies with them.
4. Analyze and Assess Risks
Pick a scoring scale (a five-by-five exposure-by-impact grid is a practical default), assign an exposure value and an impact value to each threat, multiply for an individual risk score, and optionally compute a normalized total over the theoretical worst case. Exposure reflects attacker reach and motivation, including whether the device is internet-reachable. Impact reflects what happens if the threat succeeds: device-level instability, configuration-level safety problems, system-level loss of operation, fleet-level fiscal damage. The normalized score is not part of IEC 62443 itself, but it gives auditors and decision-makers a single percentage that compares cleanly across product variants and across the before-and-after of mitigation.
5. Identify and Rate Security Measures
List the mitigation candidates per asset and threat. Rate each one by cost (engineering effort, redesign, additional components) and effect (how much it reduces exposure or impact). Some measures are cheap and high-effect, like locking unused service ports or password-protecting configuration writes. Others are expensive and high-effect, like adding a cryptographic frame-security layer. A few are expensive and low-effect, such as fully sealing a housing against an attacker who has already extracted firmware through an open debug port. Those usually drop out of consideration at the next step.
6. Select Security Measures
Choose the working set. Start with measures that are mandatory for the targeted Security Level; for any CRA-scoped product with a remote update channel, an authenticated bootloader is effectively non-negotiable. Add the low-cost / high-effect measures next, since their inclusion is hard to justify against. Layer on higher-cost measures only where they are the only option that addresses a high-residual-risk threat. When two measures share infrastructure, count the saving: a cryptographic foundation that supports both authenticated update and configuration locking pays for itself twice.
7. Implement Security Measures
Translate the selection into product behavior, integration guidance, and customer documentation. Some measures live in the device firmware (the bootloader, the access control on configuration writes). Others rely on the integrator (physical enclosure, gateway hardening, security-event monitoring at the system level). The user-facing documentation must spell out what the integrator and operator are expected to do, and the implementation tests that prove each measure works become evidence in the CRA technical file. Every product update is also an implementation review, since a new release is the moment when a previously selected measure may regress without anyone noticing.
8. Process Review and Audit
Verify that every selected measure is implemented and tested, that the residual-risk matrix is acceptable for the targeted Security Level, that compliance against the chosen standards is met, and that a review cycle is in place to revisit the assessment when threats or the product change. Penetration testing and security-log review belong here, along with the formal sign-off that closes the assessment loop for the current revision and starts the clock on the next.
Risk Scoring: Exposure × Impact
The example matrices use a five-by-five scale
with named levels. Exposure runs from rare to very likely;
impact runs from negligible to critical. The product gives a
per-threat score from 1 to 25, color-coded into low / medium /
high / very-high bands. For CAN, exposure also turns on
whether the device is reachable remotely. A bus-attached
attack scales to one machine at a time; a compromised gateway
with internet access scales to the whole fleet. That
distinction usually dominates the system-level risk picture.
The normalized risk score (the sum of all individual risk scores divided by the theoretical worst case, expressed as a percentage) is not required by IEC 62443, but it is a useful summary number for the CRA technical file. It compares cleanly across product variants and across the before-and-after of mitigation, which is exactly what auditors and notified bodies want to see at a glance.
Example: A CANopen I/O Module
A short summary
of the device-level example. The full walk-through is in the
EmSA course;
The example device is a generic industrial I/O module with a CANopen interface, no gateway functionality, intended for integration into larger CANopen networks. The asset list is the standard set: housing, MCU, external non-volatile memory, power supply, CAN and UART circuitry, debug interfaces, bootloader, CANopen stack, application firmware, and the I/O and CANopen configurations. Data is left for the integrator to evaluate, since its value depends on the deployment.
The threat list pairs each asset with its typical compromise paths: frame injection and replay on the CAN circuitry, code extraction at the debug port, downgrade attacks on the bootloader, malicious remapping of the I/O configuration, and so on. Initial exposure and impact values are assigned conservatively, since the manufacturer cannot fully model the deployment. The first-pass normalized risk score lands around 45 %, with several threats sitting in the high or critical band.
- The selected mitigations are pragmatic:
- Lock the debug interfaces.
- Password-protect the I/O and CANopen configuration writes.
- Encrypt and authenticate the external non-volatile storage.
- Implement an authenticated Secure Bootloader.
- Add Frame Security (CANcrypt or SPsec) where the deployment requires it.
Instruct the integrator, in writing, to physically protect
the device and limit CAN-cable exposure.
Re-scoring with these in place drops the normalized risk to
roughly 19 %, with most threats moving into
the low band and the residual medium-band entries marked for
the integrator to drive further down at system level.
Trust Boundaries: Zones and Conduits
The methodology partitions the system under consideration into zones and conduits. A zone groups components that share security requirements and exposure. A conduit is a communication path that crosses a zone boundary. For CAN-based products the bus itself is typically a single zone; gateways, diagnostic ports, charger ports, and remote-service interfaces are conduits to other zones. Zones can be defined coarsely or finely; the standard allows judgment, as long as each zone groups elements that genuinely share trust and exposure. A common simplification is to combine subsystems on one CANopen network into a single zone, since a successful injection on one subsystem typically reaches the others through the shared bus anyway.
Documenting each zone and each conduit as its own module pays off across product families: a subsystem reused in another machine carries its zone documentation with it, and only the integration context needs to be re-evaluated.
Manufacturer and Integrator Responsibilities
A device manufacturer cannot fully assess every risk, because the deployment context, the value of the data, the connectivity profile, and the surrounding subsystems are all set by the integrator. The honest move is to score what you control with conservative defaults, document the assumptions explicitly, and pass forward the threats that need re-evaluation in the integrated system. The integrator then uses the device-level assessment as input, adds the system-level threats and conduits that only become visible at their layer, and either takes residual responsibility or passes it further to the operator. Documenting the chain is what makes the CRA technical file defensible end-to-end.
Beyond the Device: System-Level Assessments
The same eight-step process repeats at integration scope. Now the assets are subsystems and the network rather than individual components, the threats include cross-subsystem attack paths, and the mitigations include security gateways between zones, Anomaly Event Monitoring across the bus, and authenticated communication on exposed wiring segments. In the EmSA course, the worked system example (a mobile machine with battery, drive, and manipulator subsystems plus diagnostic and remote-service ports) starts at a normalized risk score of 65 %, drops to 34 % once a CAN security monitor is added, and falls to 22 % once a secure zone with authenticated gateways protects the exposed wiring. The methodology is identical to the device case; only the scope and the residuals shift.
The Traceability Matrix
The traceability matrix is the single overview that ties the assessment together. Each row is one threat. The columns record the threat ID from the analysis, the final risk factor after mitigation, the CRA Annex I requirement the threat addresses, the mitigation control that reduces it, and a reference to the evidence (test report, configuration description, SBOM entry, code-review record). For an auditor or a notified body, this matrix is the entry point into the rest of the documentation; for the engineering team, it is the at-a-glance status of the assessment.
Where to Find the Full Walkthrough
This page introduces the methodology and the CAN-specific shape of it. The EmSA CRA Planning and CAN Risk Assessment course covers the worked examples in detail, including the full asset and threat tables, the cost-and-effect rating per measure, the heat matrix that visualizes the risk distribution, and a downloadable traceability-matrix template that links every threat to its mitigation, its CRA Annex I requirement, and its evidence reference. The course also continues into modular documentation patterns for product families that reuse subsystems across multiple variants, and into how to package the resulting risk-assessment record so an integrator downstream can pull it into their own system-level assessment without rewriting it. If you are building a CAN-based product that needs a defensible CRA risk-assessment record, the course is the recommended next step.
Frequently Asked Questions
How does an IEC 62443-3-2 risk assessment differ from a CVSS scoring exercise?
An IEC 62443-3-2 risk assessment is a system-level methodology: identify assets and zones, derive risk per zone, and choose treatment to reach a target Security Level. CVSS scores individual vulnerabilities once a system or product is defined. The two are complementary. The risk assessment frames the system; CVSS scores findings within it.
Do I need a separate IEC 62443 assessment if my product is CRA-compliant?
CRA Article 13 requires a documented cybersecurity risk assessment. It does not prescribe a specific methodology. IEC 62443-3-2 is the most common industrial methodology and produces output that many notified bodies recognize. For a CAN-based component going through CRA conformity assessment, an IEC 62443-3-2 style assessment is usually the path of least resistance.
Can my safety risk-assessment process be reused for cybersecurity?
Often, yes. The structure (assets, threats, likelihood, impact, mitigations, residual risk) is the same shape as a safety risk assessment. The two main shifts are that likelihood becomes exposure (which depends on attacker reach and motivation rather than on natural failure rates) and that the threat list is dominated by intentional, adaptive actions rather than fault conditions. If a safety process is already in place, it is usually cheaper to extend it than to start a parallel cybersecurity process.
What is a normalized risk score?
The sum of individual risk scores across all threats, divided by the theoretical worst case (number of threats times the maximum per-threat score), expressed as a percentage. It is not part of IEC 62443 itself, but it is a useful single-number summary for the CRA technical file. It makes before-and-after comparisons clean and helps non-specialists read the overall risk picture without working through the full matrix.
Why does the risk assessment need to be re-done over the product lifecycle?
Because the inputs change. New vulnerabilities are reported, the threats facing the product shift, firmware updates change behavior, integration contexts change connectivity, and the standards themselves are revised. The CRA expects the technical documentation to follow these changes for as long as the product is supported. Treating the assessment as a one-off filed at release leaves both compliance and the actual security posture stale.