The seven Foundational Requirements (FRs) form the basis of all security requirements within
ISA/IEC 62443-3-3. Each FR addresses a different aspect of cybersecurity and contributes to the overall
Security Level (SL) of a zone or conduit.
Rather than assigning a single security level to an entire system or zone, IEC 62443 allows each
Foundational Requirement to have its own Security Level, producing an SL Vector. This
provides much greater flexibility when designing security controls.
Important: Security Levels are assigned per Security Zone (or Conduit) and per
Foundational Requirement — not as a single overall rating for the zone. A zone is therefore not
simply described as "SL-T 2"; instead, it carries an SL Vector where each FR may have a different Target
Security Level. For example, a production zone might require SL-T 4 for Restricted Data Flow (FR5) and
System Integrity (FR3), but only SL-T 2 for Data Confidentiality (FR4) if sensitive data exposure is
limited. This per-FR, per-zone approach is the central purpose of the Foundational Requirements framework
and the SL Vector concept.
Example SL Vector for a single zone:
SL-T = {IAC UC SI DC RDF TRE RA}
3 3 2 1 3 2 3
Each value in the vector represents the Target Security Level required for that Foundational Requirement
within that specific zone. Different zones within the same facility will typically have different SL Vectors
reflecting their individual operational risk, asset criticality and exposure.
Figure – Overview of the seven IEC 62443 Foundational Requirements (FR1–FR7) and their relationship
to Security Level vectors.
Learning Objectives
Understand the purpose of each of the seven Foundational Requirements.
Recognise how FRs map to distinct security objectives within IACS.
Understand how Security Levels are assigned independently to each FR within each Security Zone or Conduit, forming an SL Vector.
Recognise that a zone is characterised by a range of per-FR Security Levels, not a single overall SL-T.
Identify typical security controls and industrial examples associated with each FR.
Refer to: ISA/IEC 62443-3-3 Refer to: ISA/IEC 62443-3-2 Annex A Refer to: ISA Training IC33 Section 11
FR1 – Identification and Authentication Control (IAC)
Purpose
Ensure that only authorised users, devices, applications and processes can identify themselves and gain
access to the system. This is the first line of defence against unauthorised access.
Objectives
Verify user identities.
Authenticate devices.
Prevent anonymous access.
Protect against unauthorised interrogation of systems and data.
Typical Requirements
Unique user accounts.
Password policies.
Multi-factor authentication (where practical).
Certificate-based authentication.
Device authentication.
Account lockout.
Session timeout.
Industrial Examples
Operator login to HMI.
Engineering workstation authentication.
PLC accepting only trusted engineering software.
VPN authentication before remote access.
FR2 – Use Control (UC)
Purpose
Ensure authenticated users only perform actions they are authorised to perform. Authentication determines
who you are; Use Control determines what you can do.
Objectives
Restrict operations.
Enforce least privilege.
Prevent unauthorised actions.
Control use of devices and information.
Typical Requirements
Role-Based Access Control (RBAC).
Administrator privileges.
Operator permissions.
Engineering permissions.
Command authorisation.
Separation of duties.
Industrial Examples
Operator
✔ Start process
✔ Stop process
✘ Modify PLC logic
Engineer
✔ Download PLC program
✔ Change control parameters
Maintenance
✔ Diagnostics
✔ Firmware updates
FR3 – System Integrity (SI)
Purpose
Ensure software, firmware, hardware and communications remain accurate, complete and unaltered. Protect
systems from unauthorised modification.
Objectives
Prevent tampering.
Detect modification.
Ensure trusted software.
Maintain integrity of communications.
Typical Requirements
Secure boot.
Digital signatures.
File integrity monitoring.
Anti-malware.
Whitelisting.
Change management.
Configuration management.
Secure firmware updates.
Industrial Examples
Detect modified PLC firmware.
Prevent unauthorised ladder logic download.
Verify software signatures before installation.
FR4 – Data Confidentiality (DC)
Purpose
Ensure sensitive information cannot be viewed by unauthorised individuals. Focuses on protecting
information from disclosure.
Objectives
Prevent eavesdropping.
Protect confidential information.
Encrypt communications.
Typical Requirements
Encryption.
VPN.
TLS.
Secure protocols.
Secure key management.
Industrial Examples
Encrypted remote engineering session.
Secure historian replication.
Password encryption.
VPN between plants.
FR5 – Restricted Data Flow (RDF)
Purpose
Control where information is allowed to travel. Limit communications to only those necessary for
operation.
Objectives
Restrict communication paths.
Prevent unauthorised publication of information.
Reduce attack surface.
Enforce network segmentation.
Typical Requirements
Firewalls.
Data diodes.
ACLs.
VLANs.
Zones and conduits.
Allow-list communication.
Industrial Examples
Only allow:
PLC → SCADA
SCADA → Historian
Engineer → PLC
Block:
Corporate PC → PLC
Guest WiFi → Control Network
Internet → Controller
FR6 – Timely Response to Events (TRE)
Purpose
Detect, report and respond to cybersecurity incidents quickly. Minimise the impact of attacks.
Objectives
Detect violations.
Notify appropriate personnel.
Collect forensic evidence.
Initiate corrective action.
Support incident response.
Typical Requirements
Security logging.
Audit trails.
Syslog.
SIEM integration.
Alarm generation.
Time synchronisation.
Incident response procedures.
Industrial Examples
Failed login alerts.
PLC firmware change notification.
Firewall alarm.
Automatic isolation of compromised device.
FR7 – Resource Availability (RA)
Purpose
Ensure systems continue operating even during failures or cyber attacks. Availability is often the
highest priority within industrial systems.
Objectives
Maintain operation.
Resist denial-of-service attacks.
Preserve critical resources.
Support resilience.
Typical Requirements
Redundant servers.
Controller redundancy.
Network redundancy.
UPS systems.
Backup communications.
Resource monitoring.
DoS protection.
Industrial Examples
Redundant SCADA servers.
Dual Ethernet rings.
PLC redundancy.
Hot standby historians.
Automatic failover.
Relationship Between the Seven FRs
FR
Name
Primary Security Goal
FR1
Identification & Authentication Control (IAC)
Verify identity
FR2
Use Control (UC)
Authorise actions
FR3
System Integrity (SI)
Prevent unauthorised modification
FR4
Data Confidentiality (DC)
Prevent unauthorised disclosure
FR5
Restricted Data Flow (RDF)
Control communications
FR6
Timely Response to Events (TRE)
Detect and respond to incidents
FR7
Resource Availability (RA)
Maintain operational availability
Foundational Requirements and Security Levels
IEC 62443 does not require every Foundational Requirement within a zone to have the same Security Level.
Instead, each FR within a given Security Zone or Conduit can have its own Target Security Level (SL-T),
Achieved Security Level (SL-A), and Capability Security Level (SL-C), creating an SL Vector.
Per-Zone, Per-FR Security Levels: When assessing or designing cybersecurity for a zone,
do not reduce the zone to a single Security Level (e.g. "this zone is SL-T 2"). IEC 62443 expects each
zone to be defined by an SL Vector — a set of seven Security Level values, one for each Foundational
Requirement. The SL-T for Identification and Authentication (FR1) may differ from the SL-T for Resource
Availability (FR7) within the same zone, reflecting the specific risks and operational priorities of that
area. This is the fundamental relationship between Foundational Requirements and Security Levels: FRs
define what must be protected; the SL Vector defines how strongly each aspect must be
protected for that particular zone.
This per-FR, per-zone approach provides a more accurate representation of the security posture and allows
security controls to be tailored to operational risk rather than applying uniform controls across all
security objectives.
Example SL Vector for one Security Zone:
FR
SL-T
IAC
3
UC
3
SI
4
DC
2
RDF
4
TRE
3
RA
4
Refer to: ISA/IEC 62443-3-2 (Security Level Target Determination) Refer to: ISA/IEC 62443-3-3, Clause 4 (System Security Requirements and Security Levels)
Key Takeaways
IEC 62443 defines seven Foundational Requirements (FR1–FR7) that form the basis of IACS cybersecurity.
Each FR addresses a distinct security objective, including identity, authorisation, integrity, confidentiality, communications, incident response, and availability.
Security Levels (SLs) are assigned independently for each FR within each Security Zone or Conduit, producing an SL Vector rather than a single overall security rating.
A zone is not simply "SL-T 2" (or any single level) — it is defined by a vector of seven SL values, one per Foundational Requirement, which may all differ.
The SL Vector allows security controls to be proportionate to the specific risks facing each security objective within that zone.
The required Target Security Level (SL-T) for each FR is established through a cybersecurity risk assessment in accordance with ISA/IEC 62443-3-2.
System security requirements in ISA/IEC 62443-3-3 are organised under these seven Foundational Requirements, making them the core framework for designing and assessing secure industrial control systems.
Standards References
ISA/IEC 62443-3-3 – System Security Requirements and Security Levels.
ISA/IEC 62443-3-2, Annex A – Foundational Requirements and Security Level determination.
ISA Training IC33, Section 11 – Foundational Requirements.
