---
title: "Reference Architectures Are Security Theater: Why Following Vendor Documentation Guarantees IEC 62443 Non-Compliance"
description: "Every major automation vendor publishes neat zone-and-conduit diagrams that look IEC 62443-compliant. And following them to the letter guarantees non-compliance. A line-by-line indictment of the documentation itself."
canonical: "https://rivercaudle.com/writing/reference-architectures-are-security-theater/"
author: "River Caudle"
date: "2025-08-16"
---

# Reference Architectures Are Security Theater: Why Following Vendor Documentation Guarantees IEC 62443 Non-Compliance

*2025-08-16 · IEC 62443, vendor critique*

## The Visual Trap That's Killing Industrial Security

Every major automation vendor publishes reference architectures that look clean, simple, and standards-compliant in their network diagrams. Siemens PCS7, Rockwell Automation and Cisco's Converged Plantwide Ethernet (CPwE), Schneider Electric's EcoStruxure platform, and countless others present neat zone-and-conduit models that seem to align perfectly with IEC 62443 requirements. There's just one problem: **following these documented architectures guarantees non-compliance with the very standards they claim to implement.**

The issue isn't that these vendors lack the technical capability to build secure systems. Siemens PCS7 holds TÜV SÜD IEC 62443 certifications.¹ Schneider Electric's EcoStruxure products are certified to IEC 62443-4-1 and 4-2.² Rockwell Automation promotes CPwE as supporting IEC 62443-3-3 requirements.³ The products CAN implement proper zone separation, access control, and security monitoring. The problem is that their implementation documentation tells you to do exactly the opposite of what the standard requires.

## The Negative Example That Became The Standard

Here's where it gets interesting. Siemens' own Compendium Part F contains this remarkable admission on page 17:

> "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 expect them to follow this warning with a secure alternative, right? Instead, this "negative example" becomes the foundation for all subsequent configuration guidance across the remaining 189 pages. Every network diagram, firewall rule table, and configuration procedure builds upon this admittedly insecure architecture.

Schneider Electric follows a similar pattern. Their EcoStruxure documentation acknowledges that **"A flat network architecture makes it easier for malicious actors to move around within the network"⁵** while simultaneously providing reference architectures that enable exactly such configurations. Their Panel Server documentation explicitly describes dual-homed configurations where **"devices located upstream or downstream from the Panel Server can communicate with each other as part of the same network."⁶**

**This isn't an accident. This is strategic.**

## The Compliance Theater Mechanism

When you actually analyze these reference architectures against IEC 62443 requirements, the violations are systematic:

**Zone Independence Violations:** The documented architectures place operator stations in Process Control Network 1 that simultaneously control equipment in Process Control Network 2. Compromise one zone, get access to all zones. This directly violates IEC 62443-3-2's requirements for functional, logical, and physical independence.⁷

Schneider Electric's EcoStruxure Panel Server creates identical violations through **"switched mode" configurations where both Ethernet ports (ETH1 and ETH2) plus Wi-Fi can bridge security zones.⁸** CPwE implementations show FactoryTalk System Services providing "end-to-end connectivity" across zones 0 through 6, with engineering workstations maintaining direct conduits to multiple security zones simultaneously.⁹

**Shared Operator Stations:** OS clients require authentication rights across multiple security zones simultaneously. Pages 122-123 of the Siemens documentation show OSC1 needing access to both Unit A and Unit B servers.¹⁰ This makes implementing least privilege impossible and creates permanent attack vectors across security boundaries.

Schneider's **Windows Active Directory authentication spanning multiple security zones¹¹** creates identical cross-zone dependencies, while CPwE's FactoryTalk Security integration requires extensive firewall exceptions including dynamic RPC ports (49152-65535) bidirectional flows.¹²

**Centralized Engineering Vulnerabilities:** Single engineering stations with plant-wide access violate distributed security administration principles. Every zone shares common administrative access, reducing the entire facility's security to that of its most vulnerable component.

Schneider's **Cybersecurity Admin Expert (CAE) manages security settings across "switches, firewalls, PCs, and IED/Protection relays" from a single platform,¹³** while CPwE's FactoryTalk Policy Manager deploys security policies from a single interface to devices across all zones simultaneously.¹⁴

**Missing Monitoring Requirements:** IEC 62443-3-3 SR 6.2 mandates continuous monitoring, but the reference architectures provide no guidance for implementing this requirement. The zone separation they document makes such monitoring technically impossible without violating the segmentation.

## Why People Fall Into This Trap

The human psychology here is predictable and exploitable:

1. **Visual Processing Dominance:** People look at network diagrams and assume compliance. The text warnings get skipped.

2. **Authority Bias:** If the vendor who holds the certification documents it this way, it must be compliant.

3. **Complexity Avoidance:** The CPwE documentation is nearly 500 pages. PCS7 Compendium is nearly 200 pages. Most implementers grab the diagrams and run.

4. **Standards Accessibility Crisis:** IEC 62443 itself is expensive and complex. Individual documents cost hundreds of dollars each ($470+ per standard), and the complete series runs over $2,000.¹⁵ Many of the engineers actually implementing these systems can't afford copies of the standards they're supposed to comply with. They rely on vendor interpretation instead of primary sources.

## The Perfect Vendor Lock-In

This creates a beautiful business model for automation vendors:

1. **Achieve Certification:** Prove your product CAN do security correctly
2. **Document Non-Compliance:** Provide implementation guidance that creates vendor dependencies  
3. **Capture Customers:** Organizations follow your guidance believing it ensures compliance
4. **Audit Failures:** When compliance audits fail, customers need expensive remediation
5. **Vendor Dependency:** Fixing the architecture requires more vendor products and services

The customer ends up locked into increasingly complex vendor-specific solutions while moving further from actual standards compliance.

Recent vulnerabilities demonstrate these architectural flaws in practice. **CVE-2021-22681 affecting CPwE Logix controllers has a CVSS score of 10.0, allowing complete authentication bypass.¹⁶** Schneider Electric's EcoStruxure products suffer from multiple critical vulnerabilities including **CVE-2025-1960 (CVSS 9.8) with default credentials spanning multiple zones¹⁷** and **CVE-2025-54924 through CVE-2025-54927 enabling server-side request forgery attacks.¹⁸**

## The Cost of This Broken Paradigm

Organizations following vendor reference architectures face:

- **Failed Compliance Audits:** Discovering non-compliance during regulatory reviews
- **Systematic Vulnerabilities:** Zone boundaries that exist only on paper
- **Vendor Lock-In:** Architecture dependencies that prevent competitive alternatives
- **Expensive Remediation:** Fundamental redesigns required for actual compliance
- **Liability Exposure:** Non-compliant systems create legal and insurance risks

## Breaking Free From Security Theater

**The Simple Rules That Actually Work:**

Before diving into complex compliance frameworks, follow these non-negotiable principles:

- **Your engineering PCs should never be on the same network as your PLCs.** If they can talk directly, you've already lost.

- **Your PLCs shouldn't be able to talk to each other unless you explicitly make it so.** Default connectivity is default vulnerability.

- **If it has two Ethernet cables going into it, it's wrong, unless it's a security device.** Dual-homed anything creates bridging that defeats segmentation.

- **A computer is not a security device.** Neither is a PLC. They're endpoints that need protection, not protection providers.

- **The network switch? Part of a conduit. Not a security device in most cases.** It moves packets, it doesn't secure them.

- **Those handy vendor remote access boxes with cellular? Those shouldn't be security devices either.** They're convenient attack vectors masquerading as solutions.

These rules will eliminate 90% of the architectural vulnerabilities that reference architectures create. The remaining 10% requires actual security design.

**For Implementers:**
- Read the actual standards, not just vendor interpretations
- Question any architecture where operator stations span multiple security zones
- Demand zone-specific engineering capabilities
- Implement third-party monitoring that can see across vendor boundaries

**For Organizations:**
- Budget for standards access - individual IEC 62443 documents cost $470+ each, with the complete series exceeding $2,000
- Engage third-party assessors familiar with both standards and vendor products
- Document deviations from vendor guidance and the security justifications
- Plan for vendor-neutral security architectures from the beginning

**For the Industry:**
- Demand reference architectures that actually demonstrate compliance
- Create open-source compliance validation tools
- Support standards accessibility initiatives
- Call out the disconnect between certification and documentation

## The Bottom Line

Reference architectures from major automation vendors are not security guidance - they're vendor lock-in mechanisms disguised as compliance documentation. The clean network diagrams hide systematic violations of the very standards the vendors hold certifications for.

If you're designing industrial networks using these reference architectures, you're not implementing security - you're implementing security theater. The neat zones and conduits in the diagrams will fail the moment you need them most.

**Stop using vendor reference architectures to design your security. Start with the standards themselves, and build vendor-neutral implementations that can actually pass compliance audits.**

The stakes are too high, and the industrial sector is too critical, to keep playing this game of compliance theater. It's time to demand better from our vendors and ourselves.

---

## Sources

1. TÜV SÜD IEC 62443 certification for Siemens PCS7 (2016-2017)
2. Schneider Electric EcoStruxure Cybersecurity Commitment to IEC 62443 - https://www.productinfo.schneider-electric.com/esxp_digital_apps_nema/transverse/English/BM_ESXP_DG_Transverse_Section_NEMA_DD00542196.xml/$/ESXP_DG_SYSD_Cyber_ISA_IEC_0001157270
3. Cisco CIP Security within CPwE Architecture - https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/CPwE/5-1/CIP_Security/WP/CPwE-5-1-CIPSec-WP/CPwE-5-1-CIPSec-WP.html
4. Siemens PCS7 Compendium Part F, page 17
5. Schneider Electric Data Center Expert Security Handbook - https://community.se.com/t5/DCE-Security/Data-Center-Expert-Security-Handbook/ta-p/446553
6. Schneider Electric EcoStruxure Panel Server Ethernet Communication Guide - https://www.productinfo.schneider-electric.com/ecostruxurepanelserverguide/doca0172-ecostruxure-panel-server-user-guide/English/DOCA0172%20EcoStruxure%20Panel%20Server%20Universal%20User%20Guide_0000492433.xml/$/TPC_PanelServerEthernetCommunicatio-34532EC0
7. IEC 62443-3-2 Security risk assessment and system design - https://webstore.iec.ch/en/publication/62883
8. Schneider Electric Panel Server Network Settings Documentation - https://www.productinfo.schneider-electric.com/ecostruxurepanelserverguide/doca0172-ecostruxure-panel-server-user-guide/English/DOCA0172%20EcoStruxure%20Panel%20Server%20Universal%20User%20Guide_0000492433.xml/$/EcoStruxurePanelServer_Network_Settings_0000517274
9. Rockwell Automation CPwE Design and Implementation Guide ENET-TD001E-EN-P
10. Siemens PCS7 documentation pages 122-123, user group assignment tables
11. Schneider Electric EcoStruxure Power Operation CAE Overview - https://product-help.schneider-electric.com/EcoStruxure-Power-Operation-2022/content/5%20cybersecurity/caeoverview.htm
12. Cisco CPwE Network Security Architecture - https://www.cisco.com/c/en/us/td/docs/solutions/Verticals/CPwE/5-1/Network_Security/WP/CPwE-5-1-NetworkSecurity-WP/CPwE-5-1-NetworkSecurity-WP.html
13. Schneider Electric CAE tool documentation
14. CPwE FactoryTalk Policy Manager documentation
15. IEC 62443 standards pricing - https://webstore.iec.ch/en/publication/62883
16. CVE-2021-22681 Rockwell Automation Logix Controllers - https://www.cisa.gov/news-events/ics-advisories/icsa-21-056-03
17. CVE-2025-1960 Schneider Electric EcoStruxure Power Automation System - https://www.cisa.gov/news-events/ics-advisories/icsa-25-077-03
18. CVE-2025-54924 through CVE-2025-54927 EcoStruxure Power Monitoring Expert - https://www.cisa.gov/news-events/ics-advisories/icsa-25-224-03
19. Pen Test Partners dual-homed device analysis - https://www.pentestpartners.com/security-blog/fully-segregated-networks-your-dual-homed-devices-might-disagree/
20. Dragos IEC 62443 Concepts - https://www.dragos.com/blog/isa-iec-62443-concepts/
21. CISA Top Ten Cybersecurity Misconfigurations - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a
22. Security Compass ICS Compliance - https://www.securitycompass.com/whitepapers/isa-iec-62443-compliance-in-industrial-control-systems/
23. Novesh IEC 62443 Zone Analysis - https://novesh.com/blog/novesh-blog-7/understanding-iec-62443-3-2-zones-conduits-and-risk-assessments-27
24. ISA/IEC 62443 Standards Series - https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
25. FireEye ICS Security Assessment Findings - https://www.fireeye.com/blog/threat-research/2018/10/ics-tactical-security-trends-analysis-of-security-risks-observed-in-field.html

