IEC 62443-3-3 SL2 Requirements
IEC 62443-3-3 defines a set of system requirements (SRs), grouped under seven Foundational Requirements (FRs), and specifies which SRs and which requirement enhancements apply at each Security Level (SL1 to SL4). The matrix below covers only the CAN-relevant SRs at SL2, mapped to the primary and secondary defensive measures available for CAN-based products on this site. SRs that govern human-user account management, session locks, mobile code, portable device controls, and PKI-style authentication apply to the surrounding control system rather than to the CAN bus and are deliberately omitted here. Wording in the second column is a short paraphrase for matrix use; the binding text is the standard itself.
Requirement-to-Measure Matrix
Each row names an IEC 62443-3-3 SR identifier, the Foundational Requirement it belongs to, a short paraphrase of the SL2 obligation, and the controls that address it on CAN. Primary is the most direct control; secondary is the most common complement. Full text and the exact SL1-to-SL4 enhancement pattern are in IEC 62443-3-3 itself.
| SR | Requirement (short) | Measures |
|---|---|---|
| SR 1.2 | Identify and authenticate every device and process | Primary: SOFA Secondary: Frame Security |
| SR 1.5 | Manage authenticators across full lifecycle | Primary: SOFA Secondary: Secure Bootloader |
| SR 1.13 | Authenticate access via untrusted networks | Primary: Secure
Gateways Secondary: Access Limitation |
| SR 2.1 | Enforce authorization on all use | Primary: SOFA Secondary: Frame Security |
| SR 2.8 | Generate audit records for security events | Primary: Anomaly Event Monitoring |
| SR 2.11 | Timestamp audit records reliably | Primary: Anomaly Event Monitoring |
| SR 2.12 | Non-repudiation of security-relevant actions | Primary: Frame
Security Secondary: Anomaly Event Monitoring |
| SR 3.1 | Protect integrity of transmitted information | Primary: Frame
Security Secondary: Local Injection Detection |
| SR 3.4 | Protect software and information integrity | Primary: Secure
Bootloader Secondary: SOFA |
| SR 3.8 | Protect session integrity including replay | Primary: Frame
Security Secondary: Anomaly Event Monitoring |
| SR 4.1 | Protect confidentiality of information | Primary: Frame
Security Secondary: SOFA |
| SR 4.3 | Use recognized cryptographic mechanisms | Primary: Frame
Security Secondary: SOFA |
| SR 5.1 | Partition system into zones and conduits | Primary: Zoning and Segmentation |
| SR 5.2 | Protect each zone boundary | Primary: Secure Gateways |
| SR 6.2 | Continuously monitor security events | Primary: Anomaly Event Monitoring |
| SR 7.1 | Protect against denial of service | Primary: Bus
Load Monitoring Secondary: Anomaly Event Monitoring |
| SR 7.6 | Minimize network and security exposure | Primary: Secure
Gateways Secondary: Access Limitation |
The full IEC 62443-3-3 text, including the binding wording of every SR and the exact SL1-to-SL4 enhancement pattern, is published by the IEC. The series overview is at iec.ch/cyber-security. For methodology context on how these system requirements relate to the risk-assessment process that produces a target SL, see IEC 62443-Style Assessment.
Component Requirements (IEC 62443-4-2)
The matrix above lists system requirements from IEC 62443-3-3. IEC 62443-4-2 states the parallel component requirements that a single device must meet, and the Key Management section refers to these by their CR identifiers. The CAN-relevant ones at Security Level 2 are collected here so those references resolve to a definition. The numbering mirrors the system requirements, so CR 1.2 corresponds to SR 1.2, and so on.
| CR | Requirement (short) | Covered under |
|---|---|---|
| CR 1.2 | Identify and authenticate the device | Regulations & Standards |
| CR 1.5 | Manage authenticators across the lifecycle | Symmetric Key Management |
| CR 1.8 | PKI certificates, when a PKI is used | Asymmetric Key Management |
| CR 1.9 | Strength of public-key authentication | Asymmetric Key Management |
| CR 1.14 | Symmetric-key authentication | Symmetric vs Asymmetric |
| CR 3.1 | Communication integrity | Frame Security |
| CR 4.2 | Zeroize keys at end of life | Symmetric Key Management |
| CR 4.3 | Use of proven cryptography | Symmetric vs Asymmetric |
Frequently Asked Questions
Which SRs from IEC 62443-3-3 are shown on this page?
Only the system requirements at Security Level 2 that have a meaningful application to CAN or CAN FD bus security. IEC 62443-3-3 also includes SRs about human-user account management, session locks, mobile code, portable device controls, and PKI-style authentication that do not apply at the bus level and are out of scope for this reference. The skipped SRs remain relevant for the surrounding control system, just not for the CAN-specific shells cataloged on this site.
What does Security Level 2 mean?
IEC 62443 SL2 is the second of four Security Levels. SL1 protects against incidental misuse; SL2 protects against intentional violation using simple means with low resources, generic skills, and low motivation. SL3 raises the bar to moderate resources with technology-specific skills, and SL4 to extended resources. For most industrial CAN products, SL2 is the practical baseline; reaching SL3 typically requires cryptographic frame authentication via Frame Security.
Are these mappings binding?
No. The mappings are guidance derived from the EmSA reference architecture. IEC 62443-3-3 itself is the binding text; compliance is the responsibility of the manufacturer or integrator and, where applicable, the certifying body. Use this matrix to scope the design discussion, not as a substitute for a documented Risk Assessment.