IEC 62443 for SCADA Architects: A Step-by-Step Security Architecture for New Plants

Why IEC 62443 belongs in the design phase

For a greenfield plant, cybersecurity is cheapest and strongest when it is designed into the control architecture from day one. That is the core value of IEC 62443. Instead of treating security as an afterthought, the standard gives SCADA architects a method to define risk, segment the plant into zones and conduits, and then select controls that match the required security level.

IEC 62443 originated as ISA-99 and was later adopted into the IEC family. For new plants, the most useful starting points are:

• IEC 62443-2-1 for the Cyber Security Management System, or CSMS
• IEC 62443-3-2 for security risk assessment and target security levels
• IEC 62443-3-3 for system security requirements

If you are designing a control system for water, chemicals, food and beverage, manufacturing, or energy, a sensible baseline target is often SL 2 or higher, depending on consequence and threat exposure. SL 2 is commonly used where the plant must resist intentional compromise by attackers with moderate resources, which is a realistic minimum for many modern SCADA environments.

The architecture mindset: risk first, hardware second

A common mistake in new plants is to start with PLC brand selection, switch models, or HMI preferences before defining the security model. IEC 62443 reverses that order.

The sequence should be:

1. Define what the system must protect
2. Assess threats and consequences
3. Assign target security levels
4. Partition the plant into zones and conduits
5. Select products and technical controls
6. Verify, monitor, and maintain the design

That approach aligns well with the Purdue Model and with ISA-95 style segmentation, but IEC 62443 gives the security language that the Purdue Model never had.

Step 1: Build the cybersecurity management system

IEC 62443-2-1 Clause 4 requires a CSMS that covers governance, roles, risk management, incident response, and continuous improvement. In practice, this means the plant owner must decide who owns OT security before the first network diagram is approved.

What to do first

• Create a cross-functional team with OT engineering, IT security, controls, operations, and maintenance
• Assign ownership for each security zone
• Write policies for access control, change management, backups, remote access, and incident response
• Define how security exceptions are approved and tracked

A useful operating model is to treat OT like a managed engineering discipline, not just a network. For example, Rockwell FactoryTalk Security, Siemens TIA Portal user management, or AVEVA System Platform role-based access control can be integrated with Active Directory, but the policy still has to exist first.

Practical target

For a new 500,000 sq ft chemical plant, a reasonable goal is to move from ad hoc security maturity to a defined CSMS within 12 months. That is consistent with the maturity logic used in IEC 62443-2-1 and with common OEM and EPC governance models.

Step 2: Inventory assets and classify them by criticality

IEC 62443-2-1 and IEC 62443-3-2 both depend on knowing what is in the system. You cannot protect what you have not inventoried.

Inventory should include

• PLCs and remote I/O
• Safety controllers
• HMIs and operator stations
• Engineering workstations
• Historians and application servers
• Switches, firewalls, and wireless bridges
• Field devices and smart instruments
• Remote access gateways
• Time synchronization sources

Common examples include Siemens S7-1500, Rockwell ControlLogix, Schneider Modicon M580, Beckhoff TwinCAT IPCs, ABB ACS drives, and Ignition or AVEVA System Platform for supervisory control.

Classify by impact

A simple classification table helps the risk team focus on the right assets.

For a new plant, aim for 100% asset coverage before FAT, not after commissioning. Automated discovery tools such as Nozomi Networks Guardian or Claroty can help validate the inventory, but the engineering team still needs to confirm the functional role of every asset.

Step 3: Perform the IEC 62443-3-2 security risk assessment

IEC 62443-3-2 is the backbone of the design process. It defines how to establish the System under Consideration, identify threats, estimate risk, and determine the target security level.

A practical workflow

1. Define the system boundary
2. Identify critical processes and loss scenarios
3. Model threats and vulnerabilities
4. Estimate consequence and likelihood
5. Assign target SL per zone and conduit
6. Document required compensating controls

A useful threat model is STRIDE, mapped to ICS-specific attack paths such as MITRE ATT&CK for ICS. For example, logic manipulation, spoofed commands, unauthorized firmware changes, and denial of service are all common OT threat patterns.

Risk example

Suppose a water treatment plant has an HMI-to-PLC conduit controlling chemical dosing. If the likelihood is moderate and the consequence is high, the target may be SL 2 or SL 3 depending on public health impact and exposure.

A simplified risk expression can be written as:

$$ Risk = Likelihood \times Consequence $$

For IEC 62443-3-2, the more important output is not the score itself, but the target security level and whether the architecture can achieve it.

Engineering note on CRRF

IEC 62443-3-2 Annex B uses the Cyber Risk Reduction Factor, CRRF. For SL 2, a common design target is:

$$ CRRF \ge 100 $$

That means the architecture should reduce the expected risk by at least two orders of magnitude compared with the unmitigated condition. In practice, segmentation, strong authentication, and strict conduit control are what make that reduction real.

Step 4: Define zones and conduits

This is the most important architectural move in IEC 62443.

• A zone is a group of assets with similar security requirements
• A conduit is the controlled communication path between zones

IEC 62443-1-1 and IEC 62443-3-3 both rely on this concept. For greenfield plants, zones and conduits should be drawn before detailed panel layouts are frozen.

A practical zone model

Example architecture

Enterprise IT (SL1)
  |
  |-- Firewall / proxy conduit
  v
OT DMZ (SL2) -- historian replica, jump server, patch staging
  |
  |-- Firewall conduit with allow-list
  v
SCADA Core (SL2/SL3) -- Ignition, AVEVA, engineering workstation
  |
  |-- Controlled conduit
  v
Control Zone (SL2/SL3) -- Siemens S7, ControlLogix, Modicon, drives

In many plants, a unidirectional gateway or data diode is appropriate for historian export or safety-related telemetry. For example, Level 1 to Level 2 data flow may be acceptable, while command traffic in the reverse direction should be tightly restricted or eliminated.

Step 5: Select controls to achieve the target security level

IEC 62443-3-3 defines 37 system security requirements across 14 foundational requirement groups. This is where architecture becomes implementation.

The big control families

• Identification and authentication
• Use control
• System integrity
• Data confidentiality
• Restricted data flow
• Timely response to events
• Resource availability

Example control mapping

Firewall rule example

Allow: EtherNet/IP (TCP 44818, UDP 2222) from HMI zone to PLC zone
Allow: Modbus/TCP (502) only from approved SCADA hosts
Deny: All other inbound traffic
Log: Security events to SIEM
Inspect: Application-aware filtering where supported

When selecting network gear, look at Cisco Industrial Ethernet, Rockwell Stratix, Fortinet FortiGate, or Schneider Electric industrial firewalls. For micro-segmentation, features like 802.1Q VLANs, ACLs, and OT-aware deep packet inspection matter more than generic enterprise features.

Component hardening

IEC 62443-4-2 is also relevant at the component level. That means:

• Disable unused services and ports
• Change factory default credentials
• Enforce signed firmware where supported
• Limit remote engineering access
• Lock down USB use and removable media
• Protect time synchronization and backup paths

Step 6: Design access control and hardening into operations

A secure architecture fails if operations can bypass it every day.

Access control

IEC 62443-3-3 SR 1.x and SR 2.x require identity, authentication, authorization, and session control. In plant environments, that usually means:

• Role-based access control
• MFA for remote access and admin functions
• Named accounts, never shared logins
• Time-bound elevated access for maintenance
• Jump server use for vendor access

Solutions like Duo, FactoryTalk Security, and Ignition user roles can support this model, but the process has to be enforced by operations and maintenance procedures.

Hardening guidelines

• Use VLANs to separate zones
• Avoid large flat networks
• Keep broadcast domains small
• Restrict engineering workstations to approved conduits
• Segment safety systems from standard control systems
• Use patch staging in the OT DMZ
• Apply quarterly patch windows for SL 2 systems where feasible

For machine-level environments, NFPA 79 and IEC/EN electrical design practices still matter. Security cannot compromise functional safety, but it should be coordinated with it.

Step 7: Verify, monitor, and prove the architecture

IEC 62443 is not only about design. It is also about verification and lifecycle maintenance.

Verification activities

• Factory Acceptance Test and Site Acceptance Test security checks
• Firewall rule review
• Account and role validation
• Backup and restore testing
• Penetration testing for the system boundary
• Validation of conduit restrictions and alarm paths

IEC 62443-3-2 Annex C supports security validation activities, while IEC 62443-2-4 is relevant when evaluating service providers and integrators.

Monitoring

Use OT-aware monitoring tools such as Nozomi, Claroty, or Dragos to detect anomalies like:

• Unexpected PLC programming traffic
• New devices appearing on a control subnet
• Abnormal EtherNet/IP or Modbus patterns
• Unauthorized remote sessions
• Firmware or logic changes outside the maintenance window

A useful operational target is to detect and triage critical OT incidents within hours, not days. For high-availability plants, MTTR under 4 hours is often a meaningful engineering objective.

A simple design checklist for new plants

Before detailed design is released, confirm the following:

1. CSMS ownership is assigned
2. Asset inventory is complete
3. Risk assessment is documented
4. Zones and conduits are drawn
5. Target SL is assigned per zone
6. Controls are mapped to IEC 62443-3-3
7. Access control and remote access are approved
8. Logging and monitoring are specified
9. Backup and restore are tested
10. Commissioning deliverables include security verification

Why this matters for EPCs, panel builders, and owners

For EPC contractors and panel builders, IEC 62443 reduces redesign risk, RFIs, and late-stage change orders. For plant owners, it improves uptime, audit readiness, and cyber resilience. For procurement teams, it creates a defensible specification basis when comparing products from Siemens, Rockwell Automation, Schneider Electric, ABB, Beckhoff, and other suppliers.

It also supports broader compliance goals, including EU NIS2, CE-marking-related engineering discipline, and alignment with NERC CIP where applicable. In many projects, a well-structured IEC 62443 architecture is the difference between a clean commissioning and a painful retrofit.

Final takeaway

If you are designing a new SCADA system, do not ask, “How do we secure it later?” Ask, “What zones, conduits, and security levels does the plant require from the start?” That is the IEC 62443 way.

A greenfield plant gives you the rare chance to build security into the architecture, the cabinets, the network, and the operating model at the same time. Use the standard early, document the target SLs, and let the risk assessment drive the design rather than the other way around.

If you are planning a new plant or modernizing a control architecture and want help turning IEC 62443 into a practical SCADA design, our team can help you build the right security model from the first P&ID through commissioning - /contact