Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 62443-3-3 — System Security Requirements and Security Levels for Industrial Automation
Cybersecurity requirements for industrial communication networks and IACS systems with SL-C security level framework
IEC 62443-3-3:2013 is a cornerstone standard for industrial cybersecurity, defining system security requirements and security levels (SL-C) for Industrial Automation and Control Systems (IACS). As part of the comprehensive IEC 62443 series, this standard provides the technical foundation for securing industrial networks against cyber threats while maintaining operational continuity.
1. Standard Overview and Scope
IEC 62443-3-3 specifies system security requirements for IACS networks and systems, organized around seven Foundational Requirements (FRs). The standard defines security levels (SL-C) from SL 1 (basic) to SL 4 (most stringent), enabling systematic risk assessment and mitigation. This corrigendum corrected mapping errors in the original 2013 edition.
The 2014 corrigendum corrected the SR 3.4 (Software and information integrity) security level mapping in Table B.1. The correct mapping for SL-C(SI, control system) 1 is “Not selected” rather than “SR 3.4”.
2. Foundational Requirements Framework
The standard organizes security requirements into seven Foundational Requirements (FRs):
| FR | Requirement Area | Key Controls | Typical SL Target |
|---|---|---|---|
| FR 1 | Identification & Authentication | User authentication, password policies, session management | SL 2-3 |
| FR 2 | Use Control | Authorization, access restrictions, port-hopping | SL 2-3 |
| FR 3 | System Integrity | Software integrity, malware protection, integrity monitoring | SL 3-4 |
| FR 4 | Data Confidentiality | Encryption, key management, communication confidentiality | SL 2-4 |
| FR 5 | Restricted Data Flow | Firewalls, DMZs, zone/perimeter segmentation | SL 2-4 |
| FR 6 | Timely Response | Event logging, audit, alert generation | SL 1-2 |
| FR 7 | Resource Availability | Redundancy, backup, DoS protection | SL 3-4 |
Achieving SL 3 or SL 4 requires a defense-in-depth architecture with multiple layers of security controls. No single product or technology can achieve these levels alone — they require system-level engineering across network segmentation, authentication, monitoring, and response capabilities.
3. Security Levels and Capability
The standard defines Security Level – Capability (SL-C) across four tiers:
| SL-C Level | Definition | Protection Against | Typical Application |
|---|---|---|---|
| SL 1 | Basic protection | Casual or coincidental violation | Non-critical monitoring |
| SL 2 | Moderate protection | Simple intentional violation, limited resources | Discrete manufacturing |
| SL 3 | Advanced protection | Sophisticated intentional violation, moderate resources | Critical infrastructure, process industries |
| SL 4 | Highest protection | Sophisticated intentional violation, extensive resources | National security, extreme risk environments |
3.1 System Requirements (SRs) and Requirement Enhancements (REs)
Each FR contains multiple System Requirements (SRs) that define specific security functions. For higher security levels, Requirement Enhancements (REs) add additional capabilities. For example, FR 3 (System Integrity) includes SR 3.4 for software and information integrity, with RE (1) adding automated notification about integrity violations.
4. Engineering Implementation Insights
Applying IEC 62443-3-3 in practice requires careful engineering consideration:
- Zone and conduit model: The security requirements are applied within defined zones and conduits. A control system zone containing safety-instrumented functions requires higher SL-C than a basic monitoring zone.
- Legacy system integration: Existing brownfield installations often lack the authentication and integrity controls required for SL 2+. Remediation requires compensating measures such as network segmentation via unidirectional gateways.
- SR 3.4 importance: Software integrity verification (SR 3.4) is critical for preventing unauthorized modifications to control logic, HMI configurations, and firmware. The corrigendum correctly set this requirement to “Not selected” at SL 1, acknowledging that basic installations may not have integrity checking infrastructure.
The most common compliance gap in IEC 62443-3-3 implementations is the lack of automated integrity monitoring (SR 3.4 RE 1). Even organizations with strong perimeter security often fail to detect unauthorized changes to control logic once an attacker has breached the outer defenses.
5. Relationship to Other Standards
IEC 62443-3-3 operates within the broader 62443 framework: Part 2-1 defines security management processes, Part 3-2 defines security risk assessment and system design (zones/conduits), and Part 4-1 defines product development security requirements. Together, these standards provide a comprehensive approach to IACS cybersecurity.
6. FAQs
Q: What is the difference between SL-C and SL-A?
A: SL-C (Capability) is the security level a product or system is designed to achieve. SL-A (Achieved) is the actual security level measured after deployment, considering the operational environment and configuration.
A: SL-C (Capability) is the security level a product or system is designed to achieve. SL-A (Achieved) is the actual security level measured after deployment, considering the operational environment and configuration.
Q: Does IEC 62443-3-3 apply to legacy systems?
A: Yes, but achieving higher SL levels may require architectural changes such as network segmentation, application whitelisting, and compensating controls for devices that cannot support direct security requirements.
A: Yes, but achieving higher SL levels may require architectural changes such as network segmentation, application whitelisting, and compensating controls for devices that cannot support direct security requirements.
Q: How does the corrigendum affect implementation?
A: The corrigendum corrected the SL mapping for SR 3.4. Implementers should verify they are using the corrected Table B.1 when conducting gap assessments against SL-C targets.
A: The corrigendum corrected the SL mapping for SR 3.4. Implementers should verify they are using the corrected Table B.1 when conducting gap assessments against SL-C targets.
Q: What is the role of SL in procurement?
A: SL-C is used in procurement specifications to require that IACS components demonstrate the capability to meet defined security levels. The IEC 62444-4-1 standard defines the secure development lifecycle requirements for achieving SL-C certification.
A: SL-C is used in procurement specifications to require that IACS components demonstrate the capability to meet defined security levels. The IEC 62444-4-1 standard defines the secure development lifecycle requirements for achieving SL-C certification.