A deep dive into IEC 62443-3-3 controls for OT operators

The IEC 62443 3-3 deals with system security requirements and security levels. In an OT context, when specifically dealing with securing Industrial Automation and Control Systems (IACS), IEC 62443 3-3 offers a much needed set of requirements and measures to strengthen security in a measured manner. The simplicity of detailing with coverage are strong points for IEC 62443 3-3 and OT operators should leverage this for achieving multiple security outcomes.

To be even more specific, IEC 62443 3-3 moves well beyond high-level policies and focuses on the detailed controls enterprise wide. It also details the technical capabilities that your system must possess to withstand complex cyber threats.

Compliance is about demonstrating with audit trails that these controls are correctly implemented and effective.

Before we move forward, don’t forget to check out our last blog post on Your IEC 62443-based risk assessment to-do list for 2026 here.

The Seven Foundational Requirements (FRs)

IEC 62443-3-3 categorizes its extensive list of security requirements around seven basic Foundational Requirements or FRs. These FRs represent the core security principles that an IACS must meet in order to be considered secure. Every FR is broken down into specific System Requirements (SRs) and Requirement Enhancements (REs) to define the control's detail and the security level it supports.

Let’s dive into the FRs now to learn how we can leverage IEC 62443 3-3.

FR 1: Identification and Authentication Control (AC)

This is all about knowing who or what is accessing your system.

• Key Controls: Unique identification and authentication for all users (human, software process, and device). This includes enforcing strong password policies, using two-factor authentication (where applicable), and securely managing account lifecycles.

• SR Examples:

  • SR 1.1: Human User Identification and Authentication.

  • SR 1.5: Authenticator Management (e.g., strong password policies, storage, and change frequency).

FR 2: Use Control (UC)

Once a user or device is authenticated, this requirement governs what they are allowed to do. This is the principle of Least Privilege.

• Key Controls: Role-Based Access Control (RBAC) to restrict access and permissions to only what is necessary for the user's function. This ensures that a compromised account can only affect a limited part of the system.

• SR Examples:

  • SR 2.1: Authorization Enforcement (mapping user permissions to specific roles and enforcing them across the system).

  • SR 2.3: Use Control for Portable and Mobile Devices (monitoring and controlling their connectivity and data access).

FR 3: System Integrity (SI)

Integrity is vital in an IACS; it ensures that the system functions correctly and that its data hasn't been tampered with.

• Key controls: Covers protecting IACS components (hardware, software, and firmware) from unauthorized modification. This includes using digital signatures, conducting regular integrity checks, implementing secure communication protocols, and maintaining robust patch management processes.

• SR examples:

  • SR 3.3: Security Functionality Verification (ensuring security functions are tested and verified).

  • SR 3.4: Software and Information Integrity (preventing unauthorized changes to code and configuration).

FR 4: Data Confidentiality (DC)

This requirement ensures that sensitive information is protected from unauthorized disclosure. While often secondary to Availability and Integrity in OT, it remains crucial for proprietary processes and sensitive operational data.

• Key controls: Using cryptographic techniques to protect data both in transit (during communication) and at rest (in storage).

• SR examples:

  • SR 4.1: Information Confidentiality (encryption for communication channels and storage).

  • SR 4.3: Use of Cryptography (defining acceptable algorithms and key management practices).

FR 5: Restricted Data Flow (RDF)

This is the technical realization of the Zone and Conduit architecture—a core concept of IEC 62443.

• Key controls: Network segmentation to delineate the IACS into security Zones with consistent security requirements, and securing the controlled pathways (Conduits) connecting them. This is typically achieved using firewalls, routing rules, and VLANs, following a "deny by default, allow by exception" rule for traffic.

• SR examples:

  • SR 5.1: Zone and Conduit Enforcement.

  • SR 5.2: Zone Boundary Protection (e.g., firewall policy, traffic filtering).

FR 6: Timely Response to Events (TRE)

This is the operational side of security—the ability to detect, log, and respond to incidents.

• Key controls: Implementing continuous monitoring, comprehensive event logging (auditing), and ensuring logs are protected from tampering and accessible only to authorized personnel. Effective incident response procedures are key to this FR.

• SR examples:

  • SR 6.1: Audit Log Accessibility (read-only access for authorized users).

  • SR 6.2: Continuous Monitoring (detecting and recording security events).

FR 7: Resource Availability (RA)

This focuses on system resilience, ensuring the IACS remains operational even under attack. For critical infrastructure, this is often the most important FR.

• Key controls: Protecting against Denial of Service (DoS) attacks, implementing resource management to prevent resource exhaustion, and ensuring robust backup and recovery capabilities for quick return to a secure state.

• SR examples:

  • SR 7.1: DoS Protection (limiting the effects of DoS on system resources).

  • SR 7.3: Control System Backup (maintaining up-to-date backups).

Security Levels (SL-C) and compliance

The complexity of the required controls depends on the desired Security Level Target (SL-T), which is determined by a risk assessment (per IEC 62443-3-2).

IEC 62443-3-3 defines the technical capabilities required for a system to achieve a Capability Security Level (SL-C) from SL1 (protection against casual or accidental misuse) to SL4 (protection against nation-state level threats with extensive resources).

Compliance essentially translates into:

1. Defining the appropriate SL-T for your system based on evidence.

2. Implementing all the specific SRs and REs within IEC 62443-3-3 that correspond to the desired SL-T.

3. Verifying and validating that the implemented controls (the achieved security level, SL-A) meet or exceed the SL-T.

Achieving compliance is certainly not a one-time project. It is an ongoing effort that requires continuous monitoring, auditing, tracking, shaping and adapting your controls to the evolving threat landscape.

Lastly, Shieldworkz has an IEC 62443 practice based in 5 geographies. We have IEC 62443 experts who can work with you and guide you to meet SRs and FRs in a comprehensive manner. To learn more reach out to us.