Writing a Security Requirements Doc for Hardware
Security that is not written down does not get built. A threat model that lives in someone’s head, or in a slide deck nobody revisits, does not change what engineers implement. A security requirements document is the bridge: it turns the threats you identified into specific, testable statements that become part of what the product must do, and what testing must verify. Here is how to write one for hardware.
Why Requirements, Not Just a Threat Model
A threat model identifies what could go wrong. It does not, by itself, change the product. Engineers build to requirements, and if security is not among them, it competes for attention against features that are written down and loses. The requirements document is what gives security the same standing as any other thing the product must do.
Writing requirements also forces precision. A threat model can say the debug port is a risk; a requirement must say the debug interface shall be disabled via fuse in production units, verified by a failed read attempt. That precision is what an engineer can implement and a tester can check, and it is what turns a concern into a built-and-verified property.
Start From the Threat Model
The requirements flow from the threat model, so build that first, from attack trees, trust boundaries, and the asset-and-attacker analysis. Each significant threat the model identifies becomes one or more requirements that mitigate it. The traceability from threat to requirement is what ensures the document addresses real risks rather than a generic wish list.
This linkage matters in both directions. Every requirement should trace back to a threat it counters, so you can justify it, and every serious threat should trace forward to a requirement that addresses it, so you can see nothing was dropped. A requirements document with no threat model behind it tends to be either incomplete or full of items nobody can justify.
Make Each Requirement Testable
A requirement you cannot test is a wish. Each one should state a condition that can be objectively verified, ideally with the test method implied. Avoid vague verbs like ensure secure and handle properly; state the specific behavior and the bar it must meet.
WEAK: "The device shall be secure against firmware tampering."
STRONG: "The bootloader shall verify an ECDSA-P256 signature over the
application image before execution and shall halt if verification
fails. VERIFY: an unsigned image does not run on a production unit."The strong version names the mechanism, the algorithm, the failure behavior, and the test. An engineer knows exactly what to build and a tester knows exactly how to confirm it. The weak version, by contrast, can be argued to be met or not met by anyone, which means it will be neither built reliably nor tested meaningfully.
Cover the Hardware Decisions
Hardware requirements capture the choices that are permanent once the board is fabricated: whether there is a secure element, whether debug can be fused off, whether there is a hardware root of trust, how keys are stored, and which interfaces are exposed. These belong in the document because they must be decided before layout.
Stating them as requirements forces the decisions early and records them. The device shall store the signing key in a secure element from which it cannot be exported is a requirement that drives the BOM and the schematic. Capturing it in the document, rather than leaving it implicit, is what ensures the part actually appears on the board.
Cover Firmware and Boot
Firmware requirements address the code: secure boot and what it verifies, the update mechanism and its signing and rollback protection, key handling, input validation at trust boundaries, and the absence of debug hooks in production builds. Each is a behavior the firmware must implement and the test plan must check.
These requirements connect the threat model’s findings to concrete firmware work. A threat of downgrade to a vulnerable version becomes the device shall reject firmware older than the current version via an anti-rollback counter. The firmware team builds it, the test team verifies a downgrade is refused, and the threat is closed by a traceable chain.
Cover Provisioning and Keys
How keys are generated, injected, and managed at manufacturing deserves explicit requirements, because provisioning is where per-device security is won or lost. State that keys shall be per-device, how they are generated, ideally on the device, and that no central store of private keys shall exist. These shape the manufacturing flow, not just the product.
Provisioning requirements are easy to omit because they sit at the boundary between engineering and manufacturing, which neither team fully owns. Writing them down assigns the responsibility and makes the secure choice the specified one, so the line does not default to a convenient shared key for lack of an instruction to the contrary.
Use a Standard as a Baseline
Rather than inventing every requirement, anchor the document in an established standard like the OWASP IoT Security Verification Standard, then add product-specific items. ISVS provides a vetted, leveled set of requirements, so you start from a known-good baseline and spend your effort on what is unique to your device.
Borrowing from a standard also makes the document defensible and complete. You can state the assurance level the product targets, show the requirements derived from it, and add the product-specific ones on top. That structure is far stronger than a from-scratch list, which inevitably misses categories that a maintained standard has already thought through.
Assign Severity and Priority
Not every requirement is equally critical, and the document should say so, so that under schedule pressure the team protects the ones that matter most. Mark which requirements are mandatory for ship and which are desirable, tying the rating back to the severity of the threat each addresses.
This prioritization is what survives contact with a deadline. When something has to give, a document that distinguishes must from should lets the team cut the right things, the desirable hardening, rather than the essential controls. Without it, the cuts happen ad hoc and the critical requirement is as likely to be dropped as the cosmetic one.
Make It Traceable End to End
The document’s power is in traceability: threat to requirement to implementation to test. Each requirement carries an identifier, links to the threat it mitigates, and links to the test that verifies it. This chain lets anyone confirm that a given threat was addressed, built, and proven, and it shows immediately where a link is missing.
Traceability also makes the document auditable and maintainable. When a threat changes or a feature is added, you can find the affected requirements and tests. When an auditor asks how a risk is handled, you can show the requirement and its passing test. The matrix linking threats, requirements, and tests is the artifact that ties the whole secure-development effort together.
Keep It Alive Through Development
A requirements document written once and filed is nearly useless, because products change. New features add threats and therefore requirements; design changes affect existing ones. The document has to be a living reference, reviewed when the design evolves and consulted during implementation and testing, not a gate passed once at the start.
Kept current, it becomes the security backbone of the project: engineers build to it, testers verify against it, and reviewers check changes against it. That ongoing use is what distinguishes a document that actually improves a product from one that satisfied a checkbox and was never opened again.
From Document to Verified Product
The payoff is a product where security was specified, built, and tested as a first-class concern, with a paper trail from the threats to the verification. The requirements document is what makes security a deliverable rather than an aspiration, and it is what lets a team say, with evidence, that the product does what it should against the threats they identified.
That is the difference between hoping a product is secure and knowing what it does and why. A good requirements document, traced from a real threat model and verified by a real test plan, turns the abstract goal of a secure product into a concrete, checkable set of behaviors that someone built and someone confirmed.
Where This Fits
Turning a threat model into a testable hardware security requirements document, and tracing it through to verification, is part of the secure-development support I provide. If you want help writing requirements your engineers can build and your testers can verify, that is the kind of work we do at Berkner Tech.