← All ResourcesCamp Roberts, February 2026: Independently verified. COPA 500 demonstrated no vulnerabilities after a timed cybersecurity assessment.
Case Study

The COPA 500 Demonstrated No Vulnerabilities After Timed Cybersecurity Assessment

COPA Staff

·

September 1, 2026

·

4 min read

An independent government cybersecurity team assessed the COPA 500 at Camp Roberts in February 2026 and within the 4-hour testing window, found no vulnerabilities that enabled unauthorized interaction with its control functions.

Who Did the Testing

This wasn't a vendor-commissioned pentest or a compliance checkbox. The assessment was conducted by the Joint Vulnerability Assessment Branch (JVAB), part of the U.S. Army DEVCOM C5ISR Center's Engineering and Systems Integration Directorate, Unique Mission Cell. JVAB exists specifically to find vulnerabilities in technologies evaluated at U.S. government field experimentation events. Their mandate is adversarial. Their incentive is to find problems.

JVAB assessed the COPA 500 at Camp Roberts, California, from February 23-27, 2026. That event (one of the Naval Postgraduate School's quarterly collaborative technology experimentation programs) drew 263 participants and 102 stakeholders from commands including USSOCOM, USINDOPACOM, USTRANSCOM, and Naval Special Warfare Command. JVAB conducted 9 cyber vulnerability assessments and 12 RF vulnerability assessments across participating technologies that week. The COPA 500 was one of them.

The test was a pressure test and COPA came knowing that. The experiment summary for the COPA 500 states the intent plainly: COPA would "demonstrate the COPA 500 test unit serve as the test bed for threat emulation during red teaming exercises." They showed up at one of the DoD's premier adversarial technology venues and invited the red team in.

What Was Assessed

The COPA 500 is a next-generation industrial control system built for critical infrastructure, manufacturing and energy management. Its architecture is built around the Open Process Automation Standard (O-PAS), integrating OPC UA and Open Connectivity Framework (O-PAS OCF) communications, CODESYS control logic, an Ignition HMI for visualization, and CPLANE.ai's Fusion orchestration platform. All of this running across Phoenix Contact I/O modules, ASRock industrial control nodes, and SuperMicro application servers, segmented across management and data planes.

JVAB conducted the assessment without credentials or prior knowledge of the system's network topology which is a true black-box approach. The assessment covered network services, accessible interfaces, and observable activity across the management environment. No path to unauthorized control of COPA's operational functions was found.

What They Found and Didn't Find

The core finding: the assessment identified no vulnerabilities enabling unauthorized access to COPA's control functions.

One operational hardening recommendation came out of the assessment, related to a standard Windows service-hardening best practice. COPA is addressing it. Critically, it was not a vulnerability that enabled control system compromise.

CTO of CPLANE (a COPA Partner) John Casey helping with the test.

Why the Architecture Deserves Credit

The result reflects deliberate security-by-design, not luck. The COPA 500's network architecture enforces segmentation between the management plane and the operational control/data plane. An attacker who gains a foothold on the management network still cannot reach the controllers, because there's no routable path between them. That's the kind of defense-in-depth that decades of ICS security guidance recommends, and the kind that held up under adversarial scrutiny.

This is also what the O-PAS Standard demands. The Open Process Automation Forum (OPAF) has designated ISASecure as the exclusive cybersecurity verification provider for O-PAS, aligning the standard with ISA/IEC 62443, which is the internationally recognized framework for industrial control system security. The COPA 500 is built to that framework, not retrofitted to it.

Addressing the "Open Means Insecure" Assumption

There's a persistent belief in the OT world that proprietary systems are inherently more secure than open ones. The rationale that obscurity provides protection. The evidence doesn't support it. Triton/TRISIS. Colonial Pipeline. The string of DCS and PLC compromises targeting energy, chemical, and manufacturing facilities over the past decade. Proprietary architecture did not protect those systems.

What protects a control system is sound security engineering: network segmentation, access control, hardened interfaces, and authenticated communications. Those are architecture decisions, not vendor loyalty decisions. The COPA 500 was built around them, and an independent government red team confirmed they hold.

What This Means Going Forward

A single assessment is a milestone, not a finish line. The threat landscape evolves, and the COPA 500 will continue to be tested as deployments grow, as new hardware partners join the ecosystem, and as adversarial techniques advance. That ongoing commitment to independent validation is part of what responsible critical infrastructure security looks like.

For owner-operators evaluating open process automation as well as the defense and government stakeholders who gathered at Camp Roberts, the JVAB assessment provides a meaningful, independent, government-produced answer: the COPA 500's control functions are protected, and the architecture works.

Note: Unfortunately, we cannot make the report public but can share it under NDA. If you want to take a look, contact us and we'll set up a time to share it.

Ready to move beyond proprietary control?

Contact Us