Understanding the IEC 62443 Implementation Crisis in Process Control
Executive Summary
Here's what's actually happening: Siemens PCS 7 has legitimate TÜV SÜD IEC 62443 certifications, which should mean something. But when you crack open their official documentation, they're literally teaching users how to build systems that violate the very standards they're certified for. I've gone through their documentation line by line, and the disconnect is staggering. We're not talking about minor oversights - this is systematic guidance that creates security vulnerabilities and vendor lock-in while completely undermining what IEC 62443 is trying to accomplish.
The Certification vs. Implementation Gap
What Siemens Has Certified
Let's be clear - Siemens did something impressive in 2016-2017. PCS 7 was the first automation system to get TÜV SÜD certification for IEC 62443-4-1 and IEC 62443-3-3. That's not nothing. The certification process is rigorous - they tested security functions, development processes, the whole nine yards. TÜV SÜD keeps auditing them to make sure they maintain these capabilities. On paper, PCS 7 has what it takes to implement proper zone segmentation, access control, and all the security functions the standard demands.
What Siemens Documents
But here's where it becomes problematic. Turn to page 15 of their Compendium Part F security manual, and you'll find this remarkable admission:
"Note that the example configuration presented in this section depicts a plant configuration without any safety measures. The example configuration shown below is a negative example from a security point of view."
You'd think after showing a "negative example," they'd follow up with the right way to do things. Nope. This admittedly insecure architecture becomes the foundation for literally everything else in the remaining 189 pages. Every diagram, every firewall rule, every configuration step builds on this broken foundation. It's like teaching someone to build a house by first showing them a structurally unsound example, then using that as the blueprint for everything else.
Critical Architecture Violations
1. Zone Independence Compromise
IEC 62443 is crystal clear about this: security zones need to be independent. If someone compromises Zone A, they shouldn't automatically get access to Zone B. That's the whole point of defense-in-depth - contain the damage, limit the blast radius. The standard (IEC 62443-3-2) spells out that zones need functional, logical, and physical independence.
Siemens throws this out the window. Their reference architecture puts operator stations in Process Control Network 1 (Unit A) that directly control equipment in Process Control Network 2 (Unit B). Think about that for a second. If I compromise one operator station in Unit A, I've got immediate control access to Unit B systems. Pages 122-123 lay this out in black and white - OS clients OSC1 through OSC4 need admin access to servers across multiple security zones. What should be independent zones become one giant interconnected vulnerability. Any breach cascades everywhere.
2. Shared Operator Stations Across Security Boundaries
The evidence on pages 122-123 is damning. Their user and group assignment tables show that every OS client needs membership in SIMATIC HMI groups across multiple server pairs in different units. Take OSC1 - it needs authentication rights to both OSS1A/OSS1B in Unit A and OSS3A/OSS3B in Unit B. These aren't temporary connections - they're permanent authentication channels that cross security boundaries.
This breaks multiple IEC 62443 principles at once. You can't implement least privilege when operators need broader access than their jobs require. You can't do time-based or context-based access controls when cross-zone access has to be always-on for normal operations. And you've created attack vectors where compromising one set of credentials gives authenticated access across zones. The standard's requirement for zone-specific access control becomes meaningless when your architecture demands permanent, bidirectional authentication everywhere.
3. Multi-Factor Authentication Absence
IEC 62443-3-3 SR 1.1 RE 2 is unambiguous: control systems need to provide multi-factor authentication capability when accessed via untrusted networks. Makes sense, right? Passwords alone don't cut it for critical infrastructure, especially with remote access or cross-zone communication.
Search through all 189 pages of Siemens' security manual. You won't find a single word about implementing MFA. They cover passwords extensively (pages 125-128) - complexity requirements, aging policies, the works. But second factors? Radio silence. Their SIMATIC Logon system only does single-factor auth. This is particularly alarming given their architecture requires extensive cross-zone authentication - exactly where you'd want MFA most.
4. Engineering Station as Single Point of Failure
Page 40 reveals the ugly truth: a single Engineering Station (ES1) in DCS1 configures and maintains servers in DCS2. This one decision cascades into multiple security violations.
The engineering station needs permanent firewall exceptions to reach across zones (detailed in firewall rules, pages 37-41). These can't be temporary - the ES needs continuous ability to modify configs, download programs, and troubleshoot everywhere. So much for least privilege - the engineering station maintains maximum privileges across all zones constantly. Compromise it, and you own every security zone in the facility.
This also kills any hope of distributed security administration. IEC 62443's defense-in-depth assumes different zones can have different policies, different admins, different access controls. With one engineering station ruling them all, every zone shares common administrative access. Your facility's security is only as strong as its weakest zone.
The Vendor Lock-In Mechanism
Technical Dependencies
The documented architecture creates a three-layer trap. First, proprietary SIMATIC protocols need permanent bidirectional connectivity between zones. These protocols are essential for PCS 7 to function, but they can't traverse properly configured zone boundaries without firewall exceptions that defeat the whole purpose.
Second, the centralized engineering model blocks distributed, secure administration. Only Siemens tools configure Siemens controllers, and they're built around centralized admin. Try to implement zone-specific engineering stations? You'll lose vendor support and probably violate license agreements. The documentation doesn't even consider multiple engineering stations with limited access.
Third, runtime dependencies mean OS clients can't operate independently in their zones. The architecture assumes operators need real-time multi-zone access. Try implementing time-based or role-based restrictions? You'll break operations.
Compliance Implications
Users face an impossible choice. Follow Siemens documentation and get a working system that violates IEC 62443. Or attempt real compliance by fundamentally restructuring the architecture, deviating from vendor guidance, potentially voiding support, and definitely increasing complexity and cost.
During audits, organizations face difficult choices. They must either acknowledge non-compliance despite using certified products, or explain deviations from manufacturer guidance. Both positions create potential liability and compliance challenges.
Security Theater Indicators
Certified Capabilities vs. Documented Practice
This is textbook security theater. PCS 7 can do secure zone segmentation, encrypted comms, proper access control - it's certified for all of it. But the implementation guidance systematically steers users away from using these capabilities correctly.
The most telling example starts on page 17, where they promise to transform a "negative example" into a secure configuration through "step-by-step" improvements. But track what actually happens: they add firewalls (pages 37-41) but configure them with so many exceptions they're essentially transparent. They implement user authentication (pages 122-128) but require shared credentials across zones. They discuss security zones but maintain the shared operator stations and single engineering station that violate zone independence.
It's like promising to teach someone how to build a secure house, starting with a fundamentally flawed foundation, then adding locks and alarms while never addressing that the walls don't reach the ceiling. Every security measure is undermined by the architectural flaws they refuse to fix.
Check pages 37-41 on firewall config. The system supports encrypted communications, but the docs include escape hatches: if you can't configure encrypted tunnels, just implement "All outbound traffic" rules bidirectionally. Translation: disable zone protection to maintain functionality. Security features become optional add-ons rather than requirements. Users think they're implementing security while creating vulnerabilities.
Firewall Rule Requirements
The firewall "protection" is a joke. Pages 37-41 specify rules that create so many exceptions the firewalls become transparent. They require bidirectional IPSec between zones, but if IPSec won't work? Just allow everything bidirectionally instead.
The documentation actually states "dedicated port filtering is not used" with these broad rules, claiming this has advantages with application-aware firewalls. That's backwards - application awareness should enable more restrictive rules, not justify removing restrictions. You get firewalls that exist on diagrams but provide zero actual security.
Password Policy Contradictions
Page 128 drops this bombshell: device-specific accounts for inter-system authentication can't have password aging because changing them requires stopping all PCS 7 operations system-wide. The docs explicitly recommend disabling password aging, noting "Password changes of the affected user accounts must be made simultaneously on all involved systems, otherwise proper operation cannot be ensured."
This isn't just local accounts - they're used for cross-zone authentication where strong password policies matter most. The architecture makes it operationally impossible to implement the password policies the standard requires. Permanent, unchanging credentials crossing security boundaries - what could go wrong?
Anticipating Vendor Counterarguments
"Operational Simplicity and Uptime Requirements"
Siemens might argue their architecture prioritizes operational simplicity and maximizes uptime. After all, having operators access multiple units from a single station is convenient. Centralized engineering reduces training requirements. Permanent cross-zone connections ensure operators can respond quickly to multi-unit events.
These arguments fail scrutiny. First, IEC 62443 exists precisely because operational convenience created catastrophic vulnerabilities in critical infrastructure. Stuxnet didn't succeed because systems were too secure - it succeeded because of interconnected, overly accessible architectures. Second, the standard already accounts for operational requirements through its Security Level framework. If an organization truly needs cross-zone visibility, they can implement read-only data diodes or properly secured data historians. What Siemens documents isn't operational balance - it's security abandonment.
"Legacy System Compatibility"
Another likely defense: this architecture maintains compatibility with decades of legacy installations. Changing to zone-independent operation would break existing plants and require massive retrofit costs.
This argument is disingenuous. Siemens already broke compatibility when moving to PCS 7 v9 with new hardware requirements and software architectures. More importantly, they pursued and obtained IEC 62443 certification, which explicitly requires zone independence. You can't claim both legacy compatibility and standards compliance. If legacy support prevents secure architecture, then don't pursue security certification. The current approach misleads customers into believing they can have both.
"Customer Demand for Integrated Operations"
Siemens might claim customers demand plant-wide integration and reject architectures that silo operations by zone. Modern plants require coordinated control strategies across units.
While coordination needs are real, secure architectures don't prevent integration - they just require doing it safely. Data historians can aggregate information across zones. Secure gateways can enable controlled cross-zone communications. Read-only connections can provide visibility without control. Other vendors have demonstrated these patterns work. The issue isn't technical impossibility but unwillingness to document secure integration patterns that might increase implementation complexity.
Real-World Impact
For Asset Owners
Asset owners get hit three ways. First, false confidence - they assume buying certified products means compliant implementation. When incidents happen or audits fail, they discover vendor guidance created the vulnerabilities.
Second, hidden costs. Real compliance means redesigning the network architecture, buying additional security products to compensate, hiring specialists who understand both the standard and vendor workarounds. Often exceeds original implementation cost.
Third, perpetual audit risk. Acknowledge non-compliance or explain why you ignored vendor guidance? Either creates liability. Follow vendor guidance for legal protection but ensure technical non-compliance. Deviate for better security but face questions about warranty, support, and whether you introduced new vulnerabilities.
For Security Assessors
Assessors face a nightmare. The documented architectures can't achieve the Security Levels asset owners target. Four "separate" zones on the diagram operate as one interconnected zone security-wise.
You have to explain why certified systems can't achieve even Security Level 1 when implemented per vendor docs. Compromising any operator station grants plant-wide access by design. Try explaining that to an asset owner who reasonably expected vendor guidance would ensure compliance.
For System Integrators
Integrators get stuck between a rock and a hard place. Implement per vendor docs knowing it creates non-compliance? Or deviate from guidance to improve security while potentially assuming liability? Gets really fun when customers demand both IEC 62443 compliance and strict adherence to vendor recommendations.
Often you discover these issues after project commitment. Changing course means major contract modifications. You document why standard architectures can't meet security requirements while customers assume you're trying to increase scope and cost.
Understanding the Root Causes
Why Does This Situation Exist?
After analyzing the documentation patterns and architectural decisions, three potential root causes emerge for this disconnect between certification and implementation guidance.
Historical Architecture Constraints PCS 7's architecture predates modern security zone concepts. The system evolved from 1990s designs where plant-wide visibility and centralized control were primary goals. Security was retrofitted onto this foundation rather than designed in. The documentation reflects this reality - they're trying to map security zones onto an architecture that fundamentally assumes open connectivity. It's like trying to add apartment doors to a building designed as open-plan office space. The structure fights you at every turn.
Business Model Dependencies There's a potential business incentive to maintain architectural complexity. The documented approach creates dependencies on Siemens professional services, specialized training, and ongoing support to manage the contradictions between stated security goals and operational reality. A truly zone-independent architecture might reduce these dependencies. Customers could potentially manage zones with local expertise rather than requiring vendor specialists who understand the intricate workarounds. This isn't necessarily malicious - it might be an unconscious bias toward solutions that maintain vendor relevance.
Documentation Philosophy Disconnect The most charitable interpretation: different teams with different priorities wrote different sections. The security team understood IEC 62443 requirements and pushed for certification. The implementation team focused on maintaining existing operational patterns and customer familiarity. The documentation team tried to bridge both worlds, creating guidance that acknowledges security requirements while preserving traditional architectures.
But there's a more troubling possibility given the page 17 promise to fix the "negative example" that never materializes: the documentation deliberately creates an appearance of security transformation without requiring actual architectural changes. This would allow Siemens to claim they provide security guidance while avoiding the support burden of helping customers through genuine architectural transformations. Nobody reconciled these contradictions because the contradictions serve a purpose - they let customers feel they're implementing security without disrupting operations or requiring fundamental changes.
The result is documentation that reads like security theater by design - acknowledging problems, promising solutions, but delivering changes that preserve every fundamental vulnerability.
Specific Documentation Failures
Missing Critical Guidance
Three glaring omissions. First, no guidance on achieving specific Security Levels. IEC 62443 has SL1 through SL4, but the docs don't explain how to configure for any particular level. Different zones might need different levels based on risk - good luck figuring that out.
Second, IEC 62443-3-2 requires formal risk assessment with specific deliverables including Cybersecurity Requirements Specifications. No templates, procedures, or guidance. Users develop these critical documents blind, often producing assessments that don't align with system capabilities.
Third, zero examples of compliant architecture. Every example, diagram, and procedure builds on that "negative example" from page 17. Want a compliant architecture? Reverse-engineer what not to do, then devise your own solution without vendor support.
Contradictory Instructions
Internal contradictions everywhere. Page 148 recommends CPU protection level 3 to prevent unauthorized access. Page 40 requires permanent bidirectional access between zones. The protection becomes meaningless when the network architecture demands open access.
The manual preaches zone segmentation while providing connection tables requiring universal communication. Discusses defense-in-depth while implementing single-layer architectures. These aren't typos - they're the result of trying to retrofit security concepts onto an architecture that wasn't designed for security zones.
Recommendations for Asset Owners
Immediate Actions
Start by documenting the gap between vendor guidance and standard requirements. Include specific citations from both IEC 62443 and vendor docs showing where following guidance creates non-compliance. This serves as due diligence evidence and justification for necessary deviations.
Conduct realistic risk assessments acknowledging actual security posture, not theoretical. Recognize that zones exist only on paper and any compromise likely goes plant-wide. Based on reality, implement compensating controls that provide some actual security despite architectural limits.
Get third-party security assessors who know both IEC 62443 and industrial control systems. They need to evaluate true compliance status and provide specific recommendations for achieving whatever compliance is possible within operational constraints.
Architecture Modifications Required
Four fundamental changes for meaningful security. First, eliminate shared operator stations. Each zone needs dedicated operator stations that cannot access other zones. This requires additional hardware and licenses but is essential for actual zone independence.
Second, deploy distributed engineering capabilities per zone. Multiple engineering stations with limited scope prevents the single-point-of-failure problem. Each zone should be independently manageable, even if it complicates overall administration.
Third, implement third-party MFA since native MFA doesn't exist. These solutions must integrate with existing authentication systems while providing the additional factors the standard requires.
Fourth, configure zones for independent operation. Each zone must continue functioning even if network connections to other zones are severed. This requires careful control strategy design and might limit some advanced features that assume plant-wide integration.
Vendor Engagement
Formally request reference architectures that actually meet IEC 62443. Be specific about which requirements can't be met with current documentation. Ask for explicit guidance on achieving specific security levels. Document requests and responses as due diligence evidence.
Get clarification on certification scope. Request detailed documentation of what configurations were tested during certification and what implementation assumptions were made. Understanding certification boundaries helps identify where additional measures are necessary.
Document all additional products, services, and modifications needed for actual compliance. Share this with Siemens to demonstrate true compliance cost and pressure for improved architectures in future versions.
Conclusion
This analysis of Siemens PCS 7 documentation exposes a fundamental disconnect between certified capability and documented implementation. PCS 7 has the technical chops for IEC 62443 compliance, but vendor guidance systematically leads users away from compliant implementations. This isn't a documentation bug - it's a comprehensive pattern throughout the security manual.
The implications go beyond technical non-compliance. Organizations buying certified products reasonably expect that following vendor guidance yields compliant implementations. Instead, they're forced to choose between vendor support and security compliance. This undermines the entire purpose of security standards and certification programs.
Most disturbing: this creates exactly the vulnerabilities IEC 62443 was designed to prevent. Instead of independent security zones with contained failures, you get interdependent zones where any compromise cascades plant-wide. Instead of defense-in-depth, you get single points of failure. Instead of least privilege, you need maximum privilege everywhere.
Organizations must understand that achieving real IEC 62443 compliance with PCS 7 requires significant deviation from vendor documentation. This is particularly important when vendors promise security transformations but deliver only superficial changes. Plan carefully, document thoroughly, and implement with full understanding of the implications for vendor support and warranty. Until vendors provide documentation that actually supports security standards, users must develop their own compliant architectures.
The industry needs to recognize that capability certification doesn't equal compliance documentation. More specifically, we must be alert to documentation that promises security improvements but preserves fundamental architectural flaws. Standards bodies, auditors, and end users must demand that vendors provide not just capable products but implementation guidance that achieves the security levels their certifications suggest. When documentation promises to transform a "negative example" into a secure configuration, it must actually deliver that transformation, not just layer security features onto a broken foundation.
References
All findings based on:
SIMATIC Process Control System PCS 7 Compendium Part F - Industrial Security (V9.1) Configuration Manual, October 2021, A5E42579070-AA Siemens AG Digital Industries, 189 pages
Note: This analysis is based entirely on publicly available Siemens documentation. All page references and quotes are from official Siemens manuals.