Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC Guide 120 – Security Aspects for Standards Development
Comprehensive guide for integrating security considerations into IEC standards — cybersecurity for electrotechnical products
1. Introduction to Security Standardization
IEC Guide 120, titled “Security aspects — Guide for their inclusion in publications,” is a relatively recent addition to the IEC Guide series that addresses the growing importance of security in electrotechnical products and systems. As connectivity becomes ubiquitous through the Internet of Things (IoT), industrial internet, and smart grid technologies, the security of electrotechnical equipment has become as critical as traditional safety considerations. The guide provides a structured methodology for identifying and addressing security aspects during the development of IEC standards.
Security can no longer be treated as an afterthought in product design. Guide 120 establishes that security considerations must be integrated into the standards development process from the outset, following the same systematic risk assessment approach that safety has used for decades.
The guide defines security in the context of IEC work as encompassing three primary dimensions: confidentiality (ensuring information is accessible only to authorized parties), integrity (ensuring information and system functions are not modified in unauthorized ways), and availability (ensuring systems are accessible and functional when needed). These three dimensions — commonly known as the CIA triad — form the foundation of the guide’s security framework. Additionally, the guide addresses accountability (actions can be traced to entities) and privacy (protection of personal information).
2. Security Risk Assessment Methodology
At the core of Guide 120 is a structured security risk assessment methodology that parallels the safety risk assessment approach of Guide 104 but addresses the distinct characteristics of security threats. Unlike safety hazards, which are typically unintentional and result from physical processes, security threats are often intentional, adaptive, and perpetrated by intelligent adversaries who actively seek to bypass protective measures.
| Phase | Activity | Security-Specific Considerations | Output |
|---|---|---|---|
| 1 | Context establishment | Identify assets, threat actors, and attack surface | Security scope and boundaries |
| 2 | Threat identification | Use threat libraries (CAPEC, ATT&CK) for systematic coverage | Threat catalogue |
| 3 | Vulnerability assessment | Analyze system architecture for weaknesses | Vulnerability list |
| 4 | Risk estimation | Evaluate likelihood of exploitation vs. impact severity | Risk matrix |
| 5 | Risk evaluation | Compare against acceptable risk criteria | Risk prioritization |
| 6 | Security measure selection | Choose controls from established security frameworks | Security requirements specification |
Security risk assessment differs fundamentally from safety risk assessment because threats are adaptive. A security measure that is effective today may be ineffective tomorrow as attacker techniques evolve. Guide 120 emphasizes the need for continuous monitoring and periodic reassessment.
The guide emphasizes that security risk assessment must consider the full product lifecycle, including development, deployment, operation, maintenance, and decommissioning. A vulnerability introduced during development (e.g., a coding error that creates a buffer overflow) may not be exploitable until years later when the product is deployed in a connected environment. This long-tail risk profile requires security consideration throughout the entire lifecycle, which is a significant departure from traditional hardware-focused product development.
An important concept introduced by Guide 120 is the notion of “security levels” analogous to the performance levels used in functional safety. The guide defines four security levels ranging from basic (low-impact, low-likelihood threats) to very high (critical infrastructure, national security). Each level corresponds to increasingly rigorous security requirements, design practices, and verification methods. This tiered approach allows standards developers to specify security requirements proportional to the actual risk, avoiding both under-protection and over-engineering.
3. Implementation Guidance and Engineering Practice
Guide 120 provides practical guidance on selecting and specifying security measures in product standards. The measures are organized into technical categories: identification and authentication, access control, cryptography, communication security, software security, physical security, and security management. For each category, the guide references established security standards such as IEC 62443 (industrial communication networks security), ISO/IEC 27001 (information security management), and ISO/IEC 15408 (common criteria for security evaluation).
Guide 120’s most important contribution is making security accessible to engineers who are not security specialists. By providing a structured methodology and cross-referencing established security standards, the guide enables technical committees to address security competently without requiring deep security expertise.
A critical engineering insight from Guide 120 is the principle of “defense in depth” — the idea that no single security measure should be relied upon to provide complete protection. Instead, multiple layers of security controls should be implemented so that if one layer is breached, additional layers remain to protect the system. For example, an industrial control system might combine network segmentation, firewall rules, application-layer authentication, encrypted communication, and physical access controls to provide comprehensive protection.
When implementing defense in depth, explicitly identify the “crown jewels” — the most critical assets that require the highest level of protection. Focus the deepest security layers around these assets rather than applying uniform security across all system components. This risk-based approach is more cost-effective than blanket security.
The guide also addresses the important topic of secure development lifecycle (SDL). Product standards that include security requirements should reference secure coding practices, security testing (including penetration testing and vulnerability scanning), and secure update mechanisms. Guide 120 mandates that standards requiring cryptographic mechanisms must specify the minimum cryptographic strength (key length, algorithm) appropriate for the security level, with consideration for the expected product lifetime and the evolution of computational capabilities (including quantum computing threats to current cryptographic algorithms).
Cryptographic algorithms have a limited effective lifetime. A cipher that is secure at the time of product development may be broken before the product reaches end-of-life. Guide 120 recommends specifying cryptographic agility — the ability to update cryptographic algorithms without replacing hardware — as a requirement for products with long lifecycles such as grid infrastructure and industrial equipment.
For design engineers, Guide 120 provides several practical checklists and design patterns. The security requirements checklist covers: secure boot and authenticated firmware updates, secure debug interface control, hardware security module integration, secure key storage, trusted execution environment implementation, and secure communication protocol selection. Each checklist item includes references to relevant ISO/IEC or IEC security standards, implementation guidance, and common pitfalls to avoid.
The guide also addresses the critical relationship between safety and security — sometimes called “safety-security co-engineering.” Security measures must not compromise safety functions, and safety measures must not introduce exploitable security vulnerabilities. For example, an emergency stop button must remain functional even during a cyberattack, and a safety interlock must not create a vector for unauthorized system access. Guide 120 provides rules for resolving conflicts between safety and security requirements.
Never implement security measures that can disable safety functions. A firewall that blocks emergency shutdown signals or an authentication system that delays safety-critical responses can create more harm than the security threats they address. Safety always takes precedence over security in electrotechnical equipment standards.
4. Frequently Asked Questions
Q1: How does Guide 120 relate to IEC 62443?
IEC 62443 is a comprehensive series of standards for industrial communication network security (OT cybersecurity). Guide 120 provides the overarching framework for including security in any IEC standard, while IEC 62443 provides detailed technical requirements specifically for industrial automation and control systems. Guide 120 references IEC 62443 as one source of detailed security measures but applies more broadly to all electrotechnical domains.
IEC 62443 is a comprehensive series of standards for industrial communication network security (OT cybersecurity). Guide 120 provides the overarching framework for including security in any IEC standard, while IEC 62443 provides detailed technical requirements specifically for industrial automation and control systems. Guide 120 references IEC 62443 as one source of detailed security measures but applies more broadly to all electrotechnical domains.
Q2: Should every IEC product standard include security requirements?
Not necessarily. Guide 120 requires a security risk assessment to determine whether security requirements are needed. Products with no network connectivity, no user data storage, and no safety functions may have minimal security risk. However, with the trend toward connected products, the guide recommends that all new product standards at least perform a security scoping exercise to determine whether security requirements are applicable.
Not necessarily. Guide 120 requires a security risk assessment to determine whether security requirements are needed. Products with no network connectivity, no user data storage, and no safety functions may have minimal security risk. However, with the trend toward connected products, the guide recommends that all new product standards at least perform a security scoping exercise to determine whether security requirements are applicable.
Q3: How should a standard address the rapid evolution of security threats?
Guide 120 recommends that standards specify security requirements at a functional level rather than prescribing specific technical solutions that may become obsolete. For example, instead of requiring “AES-256 encryption,” a standard might require “cryptographic protection providing 256-bit equivalent security strength.” Standards should also include provisions for security updates and a process for addressing newly discovered vulnerabilities.
Guide 120 recommends that standards specify security requirements at a functional level rather than prescribing specific technical solutions that may become obsolete. For example, instead of requiring “AES-256 encryption,” a standard might require “cryptographic protection providing 256-bit equivalent security strength.” Standards should also include provisions for security updates and a process for addressing newly discovered vulnerabilities.
Q4: What is the relationship between security and functional safety in Guide 120?
Guide 120 explicitly addresses the intersection of security and safety. Security threats can compromise safety functions (e.g., an attacker disabling a safety interlock), and safety measures can introduce security vulnerabilities (e.g., a diagnostic access port providing an attack vector). The guide requires standards developers to consider both domains and resolve conflicts using a structured methodology that prioritizes safety without ignoring security.
Guide 120 explicitly addresses the intersection of security and safety. Security threats can compromise safety functions (e.g., an attacker disabling a safety interlock), and safety measures can introduce security vulnerabilities (e.g., a diagnostic access port providing an attack vector). The guide requires standards developers to consider both domains and resolve conflicts using a structured methodology that prioritizes safety without ignoring security.
