---
title: "Defense in Depth for CAN — Strategy and Composition"
canonical_url: https://can-security.net/risk-assessment/defense-in-depth/
description: "How to combine CAN-specific shells, zoning, the secure bootloader, and perimeter controls into layered protection that meets IEC 62443 security levels."
last_updated: 2026-08-27
---
# Defense in Depth for CAN and CAN FD

No single measure secures a CAN network completely. Defense in depth, endorsed by [IEC 62443](https://can-security.net/resources/terms-and-definitions/#term-iec-62443) and [NIST SP 800-82](https://can-security.net/resources/terms-and-definitions/#term-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](https://can-security.net/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.

## 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](https://can-security.net/solutions/). 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](https://can-security.net/resources/terms-and-definitions/#term-risk-assessment) for context; physical access protection is covered by external standards only:

- [IEC 62443-3-3 SR 2.11](https://can-security.net/resources/iec-62443-sl2-requirements/#sr-2-11) [NIST SP 800-82](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-82) **Physical access protection:**  
  enclosures, locked cabinets, tamper-evident seals, controlled wiring runs.  
  For further info, see IEC 62443-3-3 SR 2.11 (least privilege physical access) and NIST SP 800-82 Section 6 (physical security).

- [IEC 62443-3-3 SR 5.x](https://can-security.net/resources/iec-62443-sl2-requirements/) [NIST SP 800-82](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-82) **[Gateways, routers, bridges, repeaters](https://can-security.net/risk-assessment/secure-gateways/):**  
  every link leaving the CAN segment is a conduit risk.  
  For further info, see IEC 62443-3-3 SR 5.x (restricted data flow / zone-and-conduit) and NIST SP 800-82 on OT firewalling.

- [IEC 62443-3-3 SR 1.x](https://can-security.net/resources/iec-62443-sl2-requirements/) [ISO/IEC 27001](https://can-security.net/resources/terms-and-definitions/#term-iso-iec-27001) **[Login / diagnostic access control](https://can-security.net/risk-assessment/access-limitation/):**  
  user and service-port authentication, including diagnostic interfaces.  
  For further info, see IEC 62443-3-3 SR 1.x (identification and authentication control) and ISO/IEC 27001 Annex A.5–A.9 for the management-system view.

## System-Level Architectural Measures

The per-node shells assume each node on a segment enables the same controls.  
[Zoning and Segmentation](https://can-security.net/solutions/zoning-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](https://can-security.net/solutions/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](https://can-security.net/resources/terms-and-definitions/#term-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](https://can-security.net/resources/terms-and-definitions/#term-cancrypt) or [SPsec](https://can-security.net/resources/terms-and-definitions/#term-spsec)) and, where the application layer matters, Secure Object Fieldbus Access so prevention backstops detection. Your [Risk Assessment](https://can-security.net/risk-assessment/) decides which row of the threats × shells matrix matters most; the [Solutions overview](https://can-security.net/solutions/) 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](https://can-security.net/solutions/secure-bootloader/) so the update channel does not become the attack vector. See [Software Updates Over CAN](https://can-security.net/threats/software-updates/) 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](https://can-security.net/solutions/)), system-level architectural measures ([Zoning and Segmentation](https://can-security.net/solutions/zoning-segmentation/)), and composite controls (the [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/)). The principle is endorsed by IEC 62443 and NIST SP 800-82. [IEC 62443](https://can-security.net/resources/iec-62443-sl2-requirements/) [NIST SP 800-82](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-82)

### How does Defense in Depth relate to Solutions?

[Solutions](https://can-security.net/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](https://can-security.net/resources/terms-and-definitions/#term-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](https://can-security.net/solutions/zoning-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](https://can-security.net/solutions/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](https://can-security.net/resources/iec-62443-sl2-requirements/) [NIST SP 800-82](https://can-security.net/resources/terms-and-definitions/#term-nist-sp-800-82) [ISO/IEC 27001](https://can-security.net/resources/terms-and-definitions/#term-iso-iec-27001)