Cybersecurity Is Now a Systems Engineering Problem

For most of the last two decades, cybersecurity in hardware-intensive products was a software problem handed to a separate team late in development. The systems engineer defined the functional and safety requirements. The security engineer reviewed the software. The two disciplines coexisted without much integration.

That model is breaking down—not because organizations have become more enlightened, but because regulators have made it mandatory to do otherwise.

What the Regulatory Pressure Actually Requires

Three regulatory frameworks are driving the most immediate change for hardware systems teams.

EU Cyber Resilience Act (CRA) took effect in 2024 and imposes cybersecurity requirements on any product with a digital element sold in the European Union. For hardware manufacturers—industrial controllers, medical devices, consumer electronics, connected infrastructure—this is not peripheral. The CRA requires manufacturers to conduct security risk assessments, implement security-by-design, document and maintain a software bill of materials, and provide security updates for the supported life of the product. Critically, these obligations apply before market access, which means they must be addressed during systems design, not after.

IEC 62443 has been the operational technology security standard for industrial systems for years, but its adoption as a compliance requirement under the CRA and by major industrial customers is accelerating. IEC 62443-4-1 and 4-2 address product development requirements directly—security development lifecycle, threat and risk assessment, security requirements derivation. These are not vague aspirations. They specify that security requirements must be derived from threat analysis and allocated to components, and that traceability between threat model, requirement, and verification must be maintained.

DoD CMMC 2.0 affects any organization in the US defense supply chain. For hardware manufacturers building systems for defense programs, CMMC Level 2 and Level 3 requirements—which align to NIST SP 800-171 and NIST SP 800-172—must be reflected in how systems are designed, not just how the internal IT environment is managed. Defense hardware programs increasingly require that cybersecurity requirements appear in the system specification and are traced through the program’s requirements management artifacts.

The common thread: security is now a first-class input to systems design with documentation, traceability, and verification obligations that mirror—and must integrate with—existing safety and functional requirements processes.

Deriving and Allocating Security Requirements

The technical challenge is not simply knowing what security requirements to apply. It’s deriving them systematically from a threat model and allocating them to the right level of the system architecture.

The standard approach combines a Threat Analysis and Risk Assessment (TARA)—as required by IEC 62443 and increasingly by ISO/SAE 21434 in automotive—with structured threat modeling methods like STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) or MITRE ATT&CK for ICS. The output of a TARA is a set of identified threats, estimated risk levels, and security controls or countermeasures. Those countermeasures then need to become allocated requirements on system elements: the controller, the communication interface, the update mechanism, the operator authentication subsystem.

This is conceptually the same decomposition process that systems engineers perform with safety requirements derived from hazard analysis. The problem is that most programs are running these analyses in separate silos with separate teams, separate artifacts, and no shared model of the system architecture. The safety team performs a FMEA or FTA in one tool. The security team performs a TARA in a spreadsheet or a separate risk management tool. The systems engineer maintains the requirements baseline in a third tool. The interfaces between these analyses—where the same subsystem must satisfy both a safety allocation and a security allocation—are managed by manual review and human memory.

At the requirement level, the symptoms are predictable: security requirements appear late, are written at too high a level of abstraction to be testable, are not tied to specific architectural elements, and have no traceable path to verification. When an auditor or program manager asks for the traceability matrix from threat to control to test result, teams scramble to construct it retrospectively.

The Safety-Security Conflict Is Real and Specific

The phrase “safety and security must be considered together” has become a platitude. The actual conflicts deserve specificity.

Fail-safe as attack surface. Many safety designs default to a known-safe state on failure detection: open a valve, de-energize a line, apply brakes. An attacker who can trigger the failure condition—by spoofing a sensor, flooding a diagnostic interface, or replaying a shutdown command—can induce the fail-safe state deliberately. The safety behavior that protects against uncontrolled physical events becomes a denial-of-service vector when the threat model includes adversarial actors. Addressing this requires security controls on the failure-detection pathway, which may add latency or complexity that the safety engineer needs to evaluate for impact on response time requirements.

Security updates vs. certified configurations. Safety-certified embedded systems—medical devices, industrial controllers, rail systems—are certified to specific software and hardware configurations. Applying a security patch changes the configuration and potentially requires re-certification or at minimum a documented change impact analysis. The security requirement to patch promptly conflicts with the safety process that governs configuration change. This tension is architectural: it requires designing update mechanisms that can be validated incrementally, isolating certified safety functions from components that need to be updated more frequently, and establishing processes for expedited safety review of security-critical patches.

Access control vs. emergency access. Security requirements push toward strong authentication and least-privilege access. Safety requirements for emergency response push toward fast, reliable access to control systems under stress conditions. The physical maintenance technician who needs to bypass authentication during a plant emergency is both a legitimate user and an attack scenario. Designing authentication mechanisms that satisfy both requirements—cryptographically robust under normal conditions, reliably accessible in authenticated emergency conditions—is a genuine systems engineering problem, not a policy decision.

Encryption latency in time-critical loops. Encrypting communications on industrial control networks introduces latency. For control loops with tight timing requirements, that latency has system-level consequences. The security requirement to encrypt all communications must be evaluated against the real-time performance requirements of the control system. Sometimes the answer is hardware-accelerated encryption. Sometimes it’s network segmentation that limits which traffic requires encryption. Either way, the decision must be made at the system architecture level, not delegated independently to the network and security teams.

Managing these tensions requires explicit architectural decisions recorded in the system model with rationale. “We know the fail-safe pathway has limited authentication because adding it would introduce 50ms of latency that violates requirement X; we have mitigated this by isolating the pathway from external network interfaces per architecture decision Y.” That rationale needs to be traceable—visible to auditors, accessible to new engineers joining the program, reviewable when the threat model changes.

Building Competency: Where the Systems Engineering Community Is

The systems engineering community is building cybersecurity competency, but the distribution is uneven.

What’s improving: INCOSE has published guidance on systems security engineering that aligns with NIST SP 800-160. ISO/SAE 21434 has created a generation of automotive systems engineers who understand TARA methodology. Academic systems engineering programs are beginning to include security as a required topic rather than an elective. Defense programs that have lived with cybersecurity requirements for years have developed internal competency that is slowly diffusing through the supply chain via contract requirements.

What remains underdeveloped: The population of systems engineers who can run a TARA with the same fluency they apply to FMEA is still small. Threat modeling is often owned entirely by cybersecurity specialists who are not embedded in systems engineering workflows and who produce outputs that systems engineers don’t know how to consume. Security requirements review is inconsistently integrated into systems engineering reviews—many programs that have rigorous SRR and PDR processes for safety and function treat security as a checkbox at the end rather than a gated input.

Tool integration is a persistent problem. DOORS, Jama Connect, Polarion, and Codebeamer are capable requirements management platforms with mature safety workflow support. They are less naturally suited to maintaining the connected model from TARA outputs through allocated requirements to architectural decisions and verification—partly because the threat model is graph-structured (threats connect to attack paths connect to assets connect to countermeasures) while traditional RM tools are document-structured. Bridging that gap currently requires either custom integrations or manual export-import workflows that break traceability.

Platforms like Flow Engineering, which model requirements and their relationships as a connected graph rather than a document hierarchy, handle the allocation of security-derived requirements alongside safety requirements more naturally—because the graph structure can represent the many-to-many relationships between threats, controls, system elements, and verification events without forcing everything into a flat matrix. For programs that are building integrated safety-security requirements baselines, the architectural difference between graph-based and document-based tooling becomes operationally significant.

What Capable Programs Are Actually Doing

The programs that are handling this well share a few operational characteristics.

They run TARA and FMEA with overlapping team membership, so the same subsystems are viewed through both lenses before architecture is finalized. They allocate security requirements to system elements in the same requirements management baseline as safety and functional requirements, not in a separate security plan that exists in parallel. They include security-to-test traceability in their verification planning—not as a separate security test plan, but as rows in the same verification matrix as safety and functional tests. They document safety-security conflict resolutions as architectural decisions with explicit rationale, not as informal agreements between team leads.

They also treat the threat model as a living artifact. A TARA done at program start and never updated is nearly useless by delivery. Threat landscapes change. Architectures evolve. New CVEs are published. The programs that maintain meaningful security posture update their TARA when architectures change significantly and review it on a cadence that matches their development cycle.

The Honest Assessment

Cybersecurity has become a systems engineering discipline whether the systems engineering community was ready for it or not. The regulatory frameworks are implemented. The contract requirements are in place. The auditors are asking for traceability.

The gap between where most hardware programs are and where the regulations require them to be is real and specific: threat models exist but aren’t connected to requirements, security requirements are written but aren’t allocated to architecture, safety-security conflicts are resolved informally without recorded rationale, and verification coverage of security requirements is thin.

Closing that gap is not primarily a tool problem—it requires people who can bridge systems engineering and cybersecurity competency, and processes that integrate threat analysis into the program’s standard engineering workflow. But the tool environment matters, because document-based approaches make it genuinely difficult to maintain the connected model from threat to requirement to architecture to test that both good engineering and regulatory compliance require.

The teams that treat security as a third pillar of systems engineering—alongside safety and function, derived with the same rigor, allocated with the same discipline, verified with the same coverage—are building products that will survive regulatory scrutiny and be harder to attack. The teams waiting for the security team to hand them a requirements document at CDR are building technical debt with a regulatory due date.