IEC 62443-3-3 System Requirements Explained: Turning Risk Into Controls

If IEC 62443-3-2 tells you how much security you need, then IEC 62443-3-3 tells you exactly what security controls to implement.

This is where risk assessments become actionable security architectures.

How 3-2 and 3-3 Connect

Standard	Question It Answers	Output
IEC 62443-3-2	"How much security do I need?"	Target Security Levels (SL-T) per zone
IEC 62443-3-3	"What specific controls achieve that level?"	Foundational Requirements + System Requirements

Think of it this way:

• 3-2 says: "Your control room needs Security Level 3 because of high consequences and sophisticated threats."
• 3-3 says: "Here's what Security Level 3 looks like: MFA, network segmentation, real-time monitoring, cryptographic integrity..."

The Seven Foundational Requirements (FRs)

IEC 62443-3-3 organizes all security capabilities into seven pillars:

FR	Name	Plain English
FR 1	Identification and Authentication Control (IAC)	"Prove who you are before you touch anything"
FR 2	Use Control (UC)	"You can only do what you're authorized to do"
FR 3	System Integrity (SI)	"The system hasn't been tampered with"
FR 4	Data Confidentiality (DC)	"Secrets stay secret"
FR 5	Restricted Data Flow (RDF)	"Data only goes where it should"
FR 6	Timely Response to Events (TRE)	"We notice problems and react quickly"
FR 7	Resource Availability (RA)	"The system stays running even when attacked"

Each FR contains multiple System Requirements (SRs), and each SR has Requirement Enhancements (REs) for higher security levels.

How Security Levels Work

IEC 62443 defines four graduated levels of control strength:

Security Level	Requirement Strength
SL 1	Basic protection (prevents accidents and casual violations)
SL 2	Enhanced protection (stops intentional attacks with simple means)
SL 3	Advanced protection (stops sophisticated attacks with moderate resources)
SL 4	Maximum protection (stops state-sponsored attacks with extensive resources)

Key Principle: Each higher SL includes all lower SL requirements plus additional enhancements.

Example for FR 1 (Identification & Authentication):

• SL 1: Identify and authenticate all users
• SL 2: ✅ SL 1 + Unique IDs per user + password complexity
• SL 3: ✅ SL 1 + SL 2 + Multi-factor authentication
• SL 4: ✅ SL 1 + SL 2 + SL 3 + Hardware-based MFA for all access

Deep Dive: FR 1 (Identification and Authentication)

Let's examine how one Foundational Requirement scales across security levels.

System Requirement 1.1: Human User Identification and Authentication

SL	Requirement	What It Means in Practice
SL 1	Identify and authenticate all human users	Username + password (basic)
SL 2	Unique identification per user	No shared accounts; individual usernames
SL 3	Multi-factor authentication for all users	Smart cards, OTP tokens, biometrics
SL 4	Hardware-based MFA for all access	FIDO keys, HSM-backed authentication

System Requirement 1.2: Software Process and Device Identification and Authentication

SL	Requirement	Implementation
SL 1	Identify and authenticate devices and software processes	Device certificates, service accounts
SL 2	Unique identification per device/process	No default credentials; unique device IDs
SL 3	Cryptographic-based authentication	PKI certificates, mutual TLS
SL 4	Hardware-based device authentication	TPM chips, hardware security modules

System Requirement 1.5: Authenticator Management

SL	Requirement	What It Means
SL 1	Procedures for password management	Written password policy
SL 2	Password complexity and expiration enforced	12+ characters, 90-day expiry, complexity rules
SL 3	Automated enforcement of authenticator policies	System-enforced password rules, lockout after failed attempts
SL 4	Hardware security modules for credential storage	Passwords stored in HSMs, cryptographically protected

Example: Mapping Risks to 3-3 Requirements

Let's take a real-world risk and show how IEC 62443-3-3 addresses it.

Risk: Shared Administrator Password on HMIs

Zone: Control Room (Zone 3) Target SL: SL 3 Consequence: High (full control room compromise)

IEC 62443-3-3 Requirements to Address This Risk

Primary FR: FR 1 (Identification and Authentication Control)

Relevant System Requirements:

1. SR 1.1 — Human User Identification and Authentication

   • SL 3 Requirement: Multi-factor authentication
   • Implementation: Deploy smart cards or OTP tokens for all HMI logins

2. SR 1.3 — Account Management

   • SL 3 Requirement: Automated lifecycle management
   • Implementation: Integrate with Active Directory; auto-disable accounts on termination

3. SR 1.5 — Authenticator Management

   • SL 3 Requirement: Automated policy enforcement
   • Implementation: System-enforced password complexity, 90-day rotation, account lockout

Before (Risk State):

• Shared "admin" password across all 15 HMIs
• No individual accountability
• No MFA
• Password hasn't changed in 3 years

After (SL 3 Compliance):

• Unique user accounts for all 23 operators
• Smart card authentication (MFA)
• Active Directory integration
• Automated password policies
• Session logging per user

Result: Risk reduced from High to Low.

The Full Requirements Matrix for a Zone

Here's how all seven FRs apply to a Control Room at SL 3:

FR	Key System Requirements	Current State	Target (SL 3)	Gap
FR 1	SR 1.1 User ID/Auth	Shared passwords	Unique + MFA	Critical
	SR 1.3 Account management	Manual	Automated lifecycle	High
	SR 1.5 Authenticator mgmt	None	Enforced policy	Critical
FR 2	SR 2.1 Authorization enforcement	Basic	Role-based, enforced	Medium
	SR 2.3 Portable device control	USB enabled	Controlled/disabled	Medium
FR 3	SR 3.2 Malware protection	Basic AV	OT-specific, whitelisting	High
	SR 3.4 Software integrity	None	Integrity monitoring	Critical
FR 4	SR 4.1 Information confidentiality	Plaintext	Encryption at rest	Medium
	SR 4.3 Cryptographic integrity	None	Signed configurations	Medium
FR 5	SR 5.1 Network segmentation	Flat network	Tiered + internal FW	Critical
	SR 5.2 Zone boundary protection	Single firewall	DMZ + DPI	Critical
FR 6	SR 6.1 Audit log accessibility	Local only	Centralized, real-time	Critical
	SR 6.2 Continuous monitoring	None	OT IDS + SIEM	Critical
FR 7	SR 7.1 DoS protection	None	Traffic limiting	Medium
	SR 7.2 Resource management	No limits	Quotas, failover	Medium

Critical Gaps: 8 High Priority Gaps: 2 Medium Priority Gaps: 6

Practical Implementation: FR 5 (Restricted Data Flow)

Let's walk through implementing one Foundational Requirement at SL 3.

The Problem

Current State: Direct network connection between business network and OT historian (single firewall between Business Network and OT Historian).

Risk: Ransomware from IT network can spread directly to OT historian, then to SCADA, then to PLCs.

SR 5.1: Network Segmentation (SL 3)

Requirement: Segment control system based on criticality with independent management of segment protection.

Implementation: Three-tier architecture: Business Network (FW1) ↔ DMZ with Historian Replica and Jump Server (FW2) ↔ OT Network with Primary Historian.

Controls:

• DMZ: Isolated zone with historian replica
• Data Diode: Unidirectional data flow from OT → DMZ (for SL 4)
• Firewalls: Two independent firewalls (defense in depth)
• Jump Server: All remote IT→OT access via hardened jump host with MFA and session recording

SR 5.2: Zone Boundary Protection (SL 3)

Requirement: Deep packet inspection of allowed traffic at zone boundaries.

Implementation:

• Firewall Rules: Deny-by-default, allow only specific protocols (e.g., HTTPS to historian API)
• DPI: Inspect all allowed traffic for malicious payloads
• IDS/IPS: Inline threat detection at both FW1 and FW2
• Logging: All boundary crossings logged to centralized SIEM

Result: Even if ransomware compromises business network, it cannot reach OT. Historian replica in DMZ provides business users with data access without OT risk exposure.

Evidence and Trust Validation

Implementing IEC 62443-3-3 requirements isn't enough—you need to prove they're working.

Evidence Chain for SR 5.2 (Zone Boundary Protection)

Evidence Type	Artifact	Freshness	Trust Contribution
Intent	Network security policy	3 months old	Moderate
Implementation	Firewall config export	Today	High
Behavioral	Firewall logs (blocked IT→OT traffic)	Last 24 hours	Very High
Validation	Penetration test confirming no IT→OT path	8 months old	Moderate (decaying)

Composite Trust Score for SR 5.2: 82/100 (High Confidence)

The combination of fresh implementation evidence and continuous behavioral evidence maintains high trust even as the pen test ages.

Decay Alert: When the penetration test reaches 12 months old, trust score will drop to 74/100. Schedule re-test at 11 months to maintain confidence.

The Conversation with Leadership

Once you've mapped your zones to IEC 62443-3-3 requirements, you can have a fact-based conversation with executives:

"Our Control Room needs Security Level 3 based on the threat assessment—we're a target for organized criminals and potentially nation-states.

We're currently at Level 1.4 across the seven Foundational Requirements.

The three critical gaps are:

1. Network monitoring (FR 6) — We have no visibility into OT network attacks
2. Access control (FR 1) — Shared passwords with no MFA
3. Network architecture (FR 5) — Flat network allows lateral movement

Closing these requires £180K capital and £45K annual operating cost.

If we don't act:

• Our insurer indicated 40% premium increase at renewal
• We can't achieve ISO 27001 certification for the offshore contract bid
• We're non-compliant with IEC 62443 (required by customer contracts)

Here's the evidence trail for everything I've just told you."

That's the power of mapping risk assessments (3-2) to system requirements (3-3) with continuous evidence validation.

How Provn Helps

Provn's platform automates IEC 62443-3-3 compliance:

Auto-Populate System Requirements

• Select zone + target SL → System automatically shows all required SRs
• No manual lookup in 200+ page standards documents

Integrated Assessment Workflow

• Assess each SR: Not Met / Partially Met / Fully Met
• System auto-calculates achieved SL per FR (weakest link principle)
• Gap analysis shows critical shortfalls

Evidence Linking

• Link evidence to each SR (policies, configs, logs, audits)
• Evidence ages and decays automatically
• Alerts when trust scores drop due to stale evidence

Continuous Validation

• Real-time trust scores show security posture confidence
• Track trends over time
• Executive dashboards for board reporting

---

Ready to turn your IEC 62443 risk assessments into actionable, evidence-backed security controls? Request a demo to see Provn's automated compliance platform.