The Hardware Security Engineering Gap: Systems Engineers Face New Pressure

For most of the past two decades, hardware security was someone else’s problem. The security team reviewed designs late in the program. Red teams probed prototypes. Supply chain concerns were handled by procurement. The systems engineer owned requirements for function, performance, safety, and interface—but security properties arrived as memos, not requirements.

That arrangement is ending. In defense, automotive, and industrial sectors simultaneously, hardware security requirements are being written into contracts, standards, and regulatory frameworks that make them traceable engineering obligations. Systems engineers who have not built the tooling, process, and vocabulary to handle them are discovering the gap the hard way—during program reviews, audits, and source selection evaluations.

This article covers what changed, what specific requirements frameworks are now in play, where they fit in the V-model, and what it actually takes to manage them alongside the safety requirements that already consume significant engineering bandwidth.

What “Hardware Security Requirements” Actually Means

The phrase covers four distinct technical domains, each with different derivation logic and different verification approaches:

Supply chain integrity addresses whether the physical components in a system are authentic, sourced from legitimate channels, and free from malicious modification. This is not a procurement problem alone—it generates engineering requirements around component provenance documentation, approved vendor lists as design constraints, and test methods for detecting counterfeit or recycled parts.

Anti-counterfeiting overlaps with supply chain integrity but focuses specifically on detection mechanisms: physical unclonable functions (PUFs), secure element markings, serialization schemes that survive integration. These are design requirements with measurable acceptance criteria.

Tamper resistance and tamper evidence address physical attack vectors—epoxy encapsulation, mesh layers, environmental sensors that zeroize key material under probing conditions. These generate geometric and material requirements, environmental requirements, and failure-mode requirements that live inside the same requirement hierarchy as mechanical and thermal constraints.

Hardware root of trust (HRoT) is increasingly the anchor for all of the above. An HRoT—whether implemented as a discrete secure element, an integrated security subsystem in an SoC, or a TPM—provides cryptographic identity and attestation that other security properties depend on. Specifying an HRoT correctly means writing requirements for boot integrity, key storage, attestation protocols, update mechanisms, and recovery behavior. Each of those has derived child requirements. None of them are soft.

These four domains do not arrive independently. A program with an HRoT requirement will have derived supply chain requirements (the secure element must come from an approved manufacturer with documented chain of custody), derived tamper resistance requirements (the HRoT must be physically protected against probing to a specified attack level), and derived anti-counterfeiting requirements (the HRoT must support attestation that distinguishes authentic units from clones). The requirement graph is dense.

The Regulatory and Contractual Pressure Driving This

Three frameworks are generating the most immediate pressure on engineering teams right now.

DoD CMMC and Hardware Security

The Cybersecurity Maturity Model Certification program’s Level 2 and Level 3 requirements—derived from NIST SP 800-171 and SP 800-172 respectively—include hardware-specific obligations that most discussions of CMMC underemphasize. Configuration management controls require that hardware baselines be documented and controlled with the same rigor applied to software. Supply chain risk management practices require supplier assessments and provenance verification that must be traceable to contracts and design decisions. Physical protection requirements address tamper-evident packaging, hardware disposal, and controlled access to hardware development environments.

The CMMC audit requirement is what changes the engineering calculus. An assessor does not accept a policy document stating that the organization manages hardware supply chain risk. They want evidence: records, traceability, design documentation showing security requirements were derived, allocated, and verified. Systems engineers who cannot produce that evidence from their requirements management infrastructure will find their organizations failing assessments on hardware provisions that seemed administrative.

NIST SP 800-193: Platform Firmware Resilience

NIST SP 800-193 defines three properties that firmware and hardware platforms must implement: Protection, Detection, and Recovery. Each property generates a structured set of requirements. Protection requirements cover authenticated firmware update mechanisms, integrity measurement, and cryptographic verification of boot components—all of which have hardware design implications. Detection requirements address runtime integrity monitoring, which requires hardware support for measurement and reporting. Recovery requirements specify that systems must be able to return to a known-good state using components that are physically isolated from potentially compromised firmware.

The standard is not prescriptive about implementation, which means systems engineers must derive specific requirements for their platform architecture. This is exactly the kind of requirements work that does not fit into a free-text document or a spreadsheet. The requirements have parent-child relationships, they allocate to specific subsystems, and they must be traced to verification evidence from hardware and firmware testing.

SP 800-193 is increasingly referenced in federal contracts, critical infrastructure programs, and—through the influence of federal procurement on industry norms—in commercial applications where platform integrity matters.

Automotive: ISO/SAE 21434 and the Convergence with ISO 26262

The automotive sector has been working through this convergence for several years, and the lessons are instructive for defense and industrial programs that are earlier in the process.

ISO/SAE 21434 establishes cybersecurity engineering processes for road vehicles with a structure deliberately parallel to ISO 26262’s functional safety framework. Both use threat and hazard analysis (TARA vs. HARA), both generate goals that must be decomposed into requirements, both require traceability through development, and both demand verification evidence that can be audited.

The practical challenge automotive teams face is that safety requirements and security requirements now share the same design artifacts. An electronic control unit has both ASIL allocation from ISO 26262 and CAL (Cybersecurity Assurance Level) allocation from 21434. Those allocations may conflict—a safety measure that improves availability may reduce security by limiting authentication overhead, or vice versa. Resolving those conflicts requires that both requirement sets live in the same traceable model, visible to the same engineers at the same time.

Teams that kept safety requirements in one tool and security requirements in a separate system—or in documents—found that conflicts surfaced late, at integration, where they are expensive to resolve. The engineering community has reached rough consensus: safety and security requirements must be co-managed, not handled in parallel silos.

Industrial: IEC 62443 and Operational Technology

Industrial control system security under IEC 62443 is generating similar pressure in manufacturing, energy, and process control sectors. The standard’s security level (SL) framework generates zone-and-conduit requirements that propagate into hardware design—specifying physical port access controls, communication path isolation, hardware authentication for field devices, and tamper detection for equipment in accessible physical locations.

Industrial programs have historically been even less systematic about security requirements than defense or automotive—operational technology environments evolved without the security engineering culture that information technology developed over decades. The convergence of IT and OT networks, combined with the documented consequences of IEC 62443 non-compliance in regulated industries, is forcing a rapid maturation of security requirements practice.

Where Hardware Security Requirements Belong in the V-Model

The V-model’s left side—system requirements, architecture, and design—is where hardware security must enter. This is not a philosophical preference; it reflects the engineering reality that most security properties cannot be added after the architecture is fixed.

An HRoT that is not specified at system requirements level will not be allocated at architecture level. It will not appear in the hardware design. By the time a security review identifies the gap, the PCB layout is complete, the secure element is not footprinted, and the recovery path requires a board revision that costs months and hundreds of thousands of dollars.

Hardware security requirements should enter the V-model at the same level as safety requirements, functional performance requirements, and interface requirements. They should derive from threat models and security objectives using the same structured decomposition process applied to other requirement types. They should be allocated to subsystems with the same rigor as power and timing budgets.

The verification side of the V-model then requires matching test cases. Physical attack testing, firmware integrity verification, supply chain audit evidence, and cryptographic attestation validation must trace back to specific requirements. Verification without traceability is not auditable, and in CMMC and ISO 21434 contexts, non-auditable verification is non-compliant verification.

The Tooling Gap

The tooling situation for hardware security requirements is, candidly, not good for most organizations.

Legacy requirements management platforms—IBM DOORS, DOORS Next, Polarion, Codebeamer—were not built for requirements that have dense graph relationships across safety and security domains. They can store security requirements as requirement objects. They struggle with the kind of cross-domain impact analysis that is needed when a security constraint changes and engineers need to understand which safety requirements, verification cases, and design decisions are affected. Configuration management features exist, but navigating complex traceability relationships through a document-centric interface is slow and error-prone.

Jama Connect handles regulatory traceability reasonably well and has invested in review workflows that suit compliance-heavy environments. It remains document-oriented in its fundamental model, which limits the kind of automated impact analysis that dense security-safety requirement graphs require.

The specific requirements of hardware security integration favor tools with native graph-based traceability, where the requirement model is a network of linked objects rather than a hierarchy of documents. Impact analysis becomes a graph traversal operation rather than a manual audit. Cross-domain conflicts between safety and security constraints become visible as link conflicts rather than discovered during integration reviews.

This is where tools built on modern data models have a structural advantage. Flow Engineering, designed for hardware and systems engineering teams with exactly this kind of requirement complexity, implements graph-based traceability as a core capability rather than an add-on. Its AI-assisted analysis can surface conflicts between co-located safety and security requirements before they propagate to design decisions—the kind of early-phase analysis that the V-model demands but that manual requirements review processes routinely miss. For teams standing up hardware security requirements processes from scratch, the structural fit between the tool’s data model and the actual shape of the requirement problem matters more than feature count.

That said, no tool solves the underlying human problem: systems engineers need to understand hardware security domains well enough to write requirements with measurable acceptance criteria, and many programs are currently short on that expertise. Tool capability is a necessary condition for managing hardware security requirements at scale, not a sufficient one.

Practical Starting Points

For programs that are beginning to integrate hardware security requirements into their systems engineering process, several practices reduce the risk of getting it wrong:

Start with threat modeling before writing requirements. Hardware security requirements that are not derived from a threat model are guesses. TARA (from 21434), STRIDE applied to hardware attack surfaces, or the NIST Cybersecurity Framework threat categorization all provide structured starting points. The threat model is the source document that justifies the requirement hierarchy.

Allocate security requirements explicitly, not by implication. Every security requirement needs a responsible subsystem. “The system shall implement tamper resistance” is not an engineering requirement. “The cryptographic key storage module shall implement active mesh protection and shall zeroize key material within 100 milliseconds of mesh breach detection” is. The difference is allocatability, verifiability, and ownership.

Establish the safety-security conflict resolution process before you need it. Programs that wait until a conflict appears to define how it will be resolved lose time they cannot recover. The process—who decides, with what authority, based on what analysis—should be in the systems engineering management plan before the first requirement is written.

Verify supply chain requirements against design choices. If a requirement specifies that a component must come from a CMMC-compliant supplier, that constraint must reach the bill of materials. Requirements that don’t connect to design decisions and procurement processes are not enforced requirements.

Use configuration management for security requirements with the same discipline as safety requirements. Version-controlled, baselined, change-controlled. Security requirements that can be informally modified without formal impact assessment are not requirements—they’re suggestions.

Honest Assessment

The pressure on systems engineers to manage hardware security requirements is real, is accelerating, and reflects a genuine engineering problem that was deferred for too long. The regulatory and contractual frameworks in play—CMMC, NIST SP 800-193, ISO/SAE 21434, IEC 62443—are not going away. They will become more specific, not less.

The gap between what most programs’ requirements management processes can handle and what these frameworks demand is significant. Closing it requires investment in process, expertise, and tooling simultaneously. Organizations that treat it as a documentation compliance problem—generating the paperwork without the underlying engineering rigor—will face the same audit and integration failures that have historically followed the same approach to safety requirements.

Systems engineers who build genuine competence in hardware security requirements derivation, allocation, and traceability will be increasingly valuable on programs where the left side of the V-model now has to carry more weight than it ever has before.