In May 2021, the Colonial Pipeline ransomware attack did not directly compromise pipeline control systems.
It compromised IT systems.
Yet the company shut down fuel distribution across the U.S. East Coast anyway.
Why?
As soon as corporate systems were compromised, leadership was no longer assured of the integrity of operations between the IT and OT environments. The best alternative was to close down the operations.
The result of that decision was fuel shortages, mass buying, federal emergency declarations and a ransom payment of approximately 4.4 million dollars.
This was not a lesson of ransomware sophistication.
It was of architectural interdependence.
Now ask yourself:
Would you be able to say confidently that your OT environment would run safely and independently should your IT network be attacked tomorrow?
Or would you close the factories because you are not confident?
That uncertainty is where ISA/IEC 62443 becomes real.
This blog will explore the idea of why implementation attempts and IEC 62443 processes fail in the industry setting, what does change when done, and how to implement it as a resilience strategy instead of compliance activity.
For more information about our cybersecurity and industrial resilience services, visit the official ACET website.
The Threat Environment Is No Longer Abstract
Industrial organizations are no longer peripheral targets.
75% of industrial organizations experienced ransomware attacks in the past year, and operational systems were increasingly affected.
ENISA’s 2023 Threat Landscape confirms that manufacturing remains one of the most targeted sectors globally, with attackers prioritizing disruption and leverage over data theft.
Meanwhile, researchers have identified approximately 70,000 internet-exposed OT devices, many running outdated firmware with publicly known vulnerabilities.
These are not theoretical vulnerabilities hidden deep in proprietary systems. They are externally visible attack surfaces.
The industrial environment has changed. The architecture often has not.
How ISA/IEC 62443 Is Structured
ISA/IEC 62443 is organized into multiple standards covering governance, operational processes, system architecture, and component security across the industrial cybersecurity lifecycle.
The framework is divided into four major categories:
- General
- Policies and Procedures
- System
- Component
Together, these standards guide who is responsible, how security is implemented, and when protection must be applied across the lifecycle of industrial systems.
Who ISA/IEC 62443 Applies To
Unlike traditional IT security frameworks, ISA/IEC 62443 assigns responsibilities to multiple stakeholders within the industrial ecosystem:
Asset Owners: organizations operating industrial facilities and critical infrastructure
System Integrators and Service Providers: organizations responsible for deploying, maintaining, or integrating industrial control systems
Product Vendors and Manufacturers: companies designing industrial hardware and software components
This multi-stakeholder approach ensures cybersecurity responsibilities are distributed across the entire industrial supply chain.
When ISA/IEC 62443 Is Applied Across the IACS Lifecycle
ISA/IEC 62443 is not applied at a single point in time. It spans the full lifecycle of industrial automation and control systems (IACS), including:
- System design and architecture planning
- Product development and engineering
- System integration and deployment
- Operational maintenance and patch management
- Ongoing risk management and asset lifecycle governance
This lifecycle approach ensures cybersecurity remains aligned with operational continuity rather than being treated as a one-time compliance activity.
ISA/IEC 62443 General Standards (62443-1-x)
General standards establish foundational concepts and terminology used throughout the framework.
Examples include:
62443-1-1 – Concepts and Models
62443-1-2 – Master Glossary of Terms and Abbreviations
62443-1-3 – System Security Conformance Metrics
62443-1-4 – IACS Security Lifecycle and Use Cases
These standards define the conceptual basis for implementing industrial cybersecurity programs.
ISA/IEC 62443 Policies and Procedures (62443-2-x)
The Policies and Procedures standards focus on governance and operational cybersecurity programs for industrial environments.
Examples include:
62443-2-1 – Security Program Requirements for IACS Asset Owners
62443-2-2 – Security Protection Rating
62443-2-3 – Patch Management in the IACS Environment
62443-2-4 – Requirements for IACS Service Providers
62443-2-5 – Implementation Guidance for Asset Owners
These standards help organizations define operational processes that support secure industrial environments.
ISA/IEC 62443 System-Level Security (62443-3-x)
System-level standards address architecture, risk assessment, and system design for industrial environments.
Examples include:
62443-3-1 – Security Technologies for IACS
62443-3-2 – Security Risk Assessment and System Design
62443-3-3 – System Security Requirements and Security Levels
These standards define how industrial systems should be architected and protected based on risk.
ISA/IEC 62443 Component Security (62443-4-x)
Component standards apply primarily to product vendors and manufacturers developing industrial devices and software.
Examples include:
62443-4-1 – Secure Product Development Lifecycle Requirements
62443-4-2 – Technical Security Requirements for IACS Components
These standards ensure industrial components are designed with security integrated into their development process.
Why IEC 62443 Is Difficult: Not Because It’s Complex, But Because It Forces Trade-Offs
The reason why most organizations fail to implement IEC 62443 is that their OT assets, communication paths, and security controls are not consistently documented or continuously verified.
They do not work, as implementation imposes uncomfortable choices.
For example:
A vendor insists on persistent VPN access for faster maintenance response.
Engineering values uptime and rapid troubleshooting.
IT wants strict access control and session monitoring.
Who decides?
The governance requirements in IEC 62443 establish the accountability of the asset owners, integrators, and service providers. That sounds administrative until an incident occurs and response speed depends on clear ownership.
Similarly, segmentation sounds simple in theory. In practice, it may require:
- Redesigning network architecture
- Introducing controlled DMZs
- Restricting direct IT-to-OT communication
- Documenting previously informal communication paths
These changes affect operations. They demand executive support.
That is why implementation often stalls: not because the framework is unclear, but because it exposes architectural shortcuts that have accumulated over years.
Security Levels: Where Risk Becomes Measurable
Security Levels (SL1–SL4) are one of the most powerful elements of IEC 62443 and one of the most misunderstood.
They are not maturity scores.
They are a structured way to determine how resistant a system must be against defined threat capabilities.
Consider again the Colonial Pipeline case. While the control systems were reportedly not directly breached, the interdependence between IT and OT environments created operational risk.
A properly segmented architecture, aligned with risk-based security levels, reduces that dependency. It enables leadership to make informed decisions rather than precautionary shutdowns.
Security Levels force an organization to articulate consequence by asking:
- What happens if this system is manipulated?
- What happens if this system is unavailable?
- What happens if this system communicates outside its intended boundary?
Without that discipline, protection becomes reactive.
Zones and Conduits: Architecture Determines Outcome
Ransomware does not typically stop at the first compromised machine. It spreads.
Flat networks, still common in industrial environments, facilitate the ransomware’s lateral spread.
IEC 62443’s zones and conduits model addresses this by requiring logical segmentation based on functional grouping and risk profile.
Imagine two scenarios:
In the first, a compromised vendor workstation can communicate freely across the control network.
In the second, that workstation is isolated within a defined zone, with strictly controlled conduits limiting access.
In both cases, intrusion occurs.
In only one case does it escalate uncontrollably.
ENISA and CISA both emphasize network segmentation as a foundational mitigation strategy for industrial cybersecurity.
The IEC 62443 operationalizes that guidance in an architectural context
Visibility: The Uncomfortable Starting Point
Many plants believe they understand their OT environments.
Few maintain continuously verified inventories of every controller, engineering workstation, remote connection, and inter-zone communication path, etc.
CISA’s ICS advisories regularly highlight vulnerabilities in widely deployed industrial systems.
Yet without visibility, it is impossible to determine exposure accurately.
IEC 62443 begins with asset identification and risk assessment not as administrative steps, but as prerequisites for rational decision-making.
Visibility transforms cybersecurity from speculation into measurable risk.
Strategic Reality
Segmentation and remote access governance is becoming a more scrutinized topic by cyber insurance providers. The regulators are increasing critical infrastructure resilience requirements. Boards are posing more difficult questions regarding operational continuity during cyber stress.
IEC 62443 does not guarantee immunity. What it offers is verifiable architecture, organized government and risk appropriate security.
The difference between organizations that reference the standard and those that implement it meaningfully often comes down to intent.
One group prepares for audits.
The other prepares for disruption.
Conclusion
The most important lesson from incidents like Colonial Pipeline is not that attackers are unstoppable. It is that architectural uncertainty forces operational shutdowns.
If IEC 62443 is implemented properly it can reduce uncertainty.
It forces clarity around segmentation, ownership, risk tolerance, and system criticality. It creates conditions in which leadership can make confident decisions under pressure.
Industrial resilience is not achieved through policy statements. It is achieved through deliberate architectural discipline.
IEC 62443 is that discipline, if treated as implementation rather than intention.
Ready to move beyond compliance and build true operational resilience? Contact ACET today to learn how we can help you design and implement a practical ISA/IEC 62443 cybersecurity strategy for your industrial environment.
Unlike ISO 27001 or NIST CSF, which are broad information security frameworks, IEC 62443 is specifically designed for industrial automation and control systems (IACS). It addresses:
- Segmentation between IT and OT
- Security Levels (SL1–SL4) tied to threat resistance
- Zones and conduits for architecture
- Operational continuity under cyber stress
In short, it complements other frameworks, filling the industrial-specific gap they leave.
Security Levels are not maturity scores. They define the minimum resistance a system must have against defined threat capabilities:
- SL1: Protection against casual or coincidental threats
- SL2: Protection against intentional, low-skilled attackers
- SL3: Protection against skilled attackers with moderate resources
- SL4: Protection against highly skilled, resourceful attackers (nation-state level)
They help translate risk into operational and technical controls, guiding decisions like segmentation, access, and redundancy.
Zones and conduits create logical segmentation of the OT environment:
- Zones: Group assets with similar criticality or functionality
- Conduits: Controlled communication paths between zones
This prevents a single compromised workstation or server from spreading malware across the entire OT network, directly addressing the type of interdependence that caused the Colonial Pipeline shutdown.
IEC 62443 requires clear governance and accountability. Successful implementation often demands trade-offs:
- IT may insist on strict access controls
- OT may prioritize rapid troubleshooting and uptime
- Vendors may need maintenance access
By defining asset owners, responsibilities, and escalation paths, organizations can make informed decisions that do not compromise either security or operations.
Start with asset visibility and risk mapping:
- Identify every controller, workstation, and network connection
- Map informal and formal IT-to-OT paths
- Classify assets by criticality and exposure
Without this baseline, segmentation, access control, and security levels are guesses, not decisions.
No. IEC 62443 does not make systems invulnerable. What it provides is:
- Defensible architecture
- Structured governance
- Risk-aligned security measures
- The ability for leadership to make informed decisions during incidents
Resilience comes from clarity and preparation, not from assuming threats won’t happen.
Related Articles
