If one protection fails, the next one is already in place.

Defense in Depth for CAN and CAN FD

No single measure secures a CAN network completely. Defense in depth, endorsed by IEC 62443 and NIST SP 800-82, is the strategy of combining multiple defensive measures across the network layers so that the failure of any one still leaves the asset protected by the others. This page is the strategy layer; the individual measures are cataloged under Solutions. The focus here is how to compose them, where the perimeter areas fit, and how zoning and the secure bootloader sit alongside the per-node shells.

Layers and Shells

The graphic below shows how OSI network layers (orange, left) can be protected by dedicated shells. The shells (green and gray) describe the defensive controls applied across those layers. A shell may cover a single layer or span several. Calling both "layers" would be ambiguous, so this reference uses shells for the controls and layers for the network stack. Each green shell in the graphic links to its full description in the Solutions catalog: click a shell to open its page.

OSI network layers (Physical at the bottom, Application at the top) on the left, surrounded by perimeter shells on the outside (physical access protection, gateway/router/bridge/repeater protection, login procedures), and CAN-specific defensive shells in the center: load monitoring at the bottom, local injection detection and CANcrypt/SPsec across data-link and network layers, anomaly event monitoring spanning the middle layers, and Secure Object Fieldbus Access at the application layer.
OSI network layers (left), perimeter areas (gray, out of scope here) and CAN-specific shells (green) cataloged under Solutions.

Composing the Per-Node Shells

The per-node shells are deliberately complementary, not interchangeable. Detective shells (bus load monitoring, anomaly event monitoring, local injection detection) surface events but do not stop them. Preventive shells (frame security, Secure Object Fieldbus Access) stop the attack from succeeding but do not by themselves tell the operator that anything was attempted. A workable combination pairs at least one detective shell with the preventive shells whose threats it can observe, so detection has the backstop of prevention and prevention has the visibility of detection. Local Injection Detection is the special case: it raises an alarm on the impersonated node, but the alarm needs a reporting channel that reaches beyond that node, which in practice might not always be available (simple sensor module will not have an alternate communication channel). In such cases, a cryptographic secure heartbeat (part of frame security) is an option: a node who detected a local injection simply stops transmitting its secure heartbeat. The secure heartbeat loss is an indication for a security event detected by that node.

For shell-by-shell coverage of specific threats at IEC 62443 Security Levels, see the threats × shells matrix on the Solutions overview. That matrix is the catalog view of what each individual shell contributes; the strategy view here is about which shells to combine and why.

Perimeter Areas (Out of Scope)

The gray boxes in the graphic are perimeter areas around the CAN network rather than CAN-specific controls. General industrial cybersecurity practice applies and is well covered by existing standards. This reference does not duplicate that coverage. Selected perimeter areas have summary stubs under Risk Assessment for context; physical access protection is covered by external standards only:

System-Level Architectural Measures

The per-node shells assume each node on a segment enables the same controls.
Zoning and Segmentation is the architectural lever for cases where uniform per-node controls are the wrong answer: divide the CAN system into segments by exposure profile, keep classical CAN inside protected zones, and put CAN FD with frame security on segments whose wiring leaves the protected enclosure. Zoning is not a per-node shell; it is a system-level architectural pattern from IEC 62443-3-2 that composes with the shells rather than competing with them.

Composite Measures: Secure Bootloader

Firmware update has its own threat model and its own combination of primitives: pre-shared key, potentially frame authentication during the update window, image-integrity verification, rollback protection.
The Secure Bootloader is a composite control that combines these primitives into a separate operating mode rather than running as a continuous shell during normal operation. In CRA-scoped products firmware update is required, so the bootloader composition is always part of the defensive picture.

Choosing Your Combination

The combination of measures to deploy depends on the residual risk you can accept after the perimeter areas are handled. For low-risk industrial CAN networks behind a controlled enclosure, bus load monitoring plus anomaly event monitoring cover the most common compliance baselines (CRA security event log, IEC 62443 SR 6.x and SR 7.x). Higher-assurance systems, including medical devices, energy infrastructure and safety-critical machinery, add Frame Security (CANcrypt or SPsec) and, where the application layer matters, Secure Object Fieldbus Access so prevention backstops detection. Your Risk Assessment decides which row of the threats × shells matrix matters most; the Solutions overview shows what each shell contributes.

Where firmware update is in scope (and for any CRA-scoped product it always is), pair the bus-side shells with the Secure Bootloader so the update channel does not become the attack vector. See Software Updates Over CAN for the threat side of that picture.

Frequently Asked Questions

What is defense in depth for CAN?

Defense in depth combines multiple defensive measures across the network layers so that the failure of any one still leaves the asset protected by the others. For CAN, those measures group into per-node shells (cataloged under Solutions), system-level architectural measures (Zoning and Segmentation), and composite controls (the Secure Bootloader). The principle is endorsed by IEC 62443 and NIST SP 800-82. IEC 62443 NIST SP 800-82

How does Defense in Depth relate to Solutions?

Solutions is the catalog of individual defensive controls and the EmSA products that implement them, including a per-threat coverage matrix at IEC 62443 Security Levels. Defense in Depth is the strategy layer that explains how to combine those controls into layered protection for a given threat profile and IEC 62443 security level. Use Solutions to look up what a specific control does; use Defense in Depth to decide which combination fits your system.

Why does this reference distinguish shells from network layers?

The seven network layers (physical to application) describe where data is processed. Shells describe the defensive controls applied across those layers. A single shell may cover one layer (load monitoring on physical) or span several (anomaly event monitoring is cross-cutting). Calling both "layers" is ambiguous; this reference uses "shells" for the controls and "layers" for the network stack.

How do zoning and the secure bootloader fit into defense in depth?

Zoning and Segmentation is a system-level architectural measure: a choice about how the CAN topology itself is laid out, applied selectively across segments rather than uniformly per node. The Secure Bootloader is a composite control: a separate operating mode that combines authentication, image-integrity verification, and rollback protection into the firmware-update channel. Both compose with the per-node shells rather than competing with them; neither appears as a column on the threats × shells matrix.

Why are physical access protection and gateways not detailed here?

They are perimeter areas around the CAN network rather than CAN-specific controls. General industrial cybersecurity standards apply: IEC 62443-3-3 for zone-and-conduit and access control, NIST SP 800-82 for OT firewalling and remote access, ISO/IEC 27001 for management-system controls. This reference focuses on the bus-side, CAN-specific controls and points out to those standards for the perimeter side. IEC 62443-3-3 NIST SP 800-82 ISO/IEC 27001