Secure by design
The content of Annex I, Part I is detailed in Product security. This page describes how to produce it.
The risk assessment: the pivot document
It is required on two counts: it conditions the application of the essential requirements “as appropriate to the product”, and it is an item of the technical documentation.
What it must contain:
| Section | Content |
|---|---|
| Scope | Product, versions, components, interfaces |
| Intended security environment | Deployment assumptions — carried over verbatim into the user notice |
| Assets to protect | Data, functions, secrets, availability |
| Threat sources and scenarios | Who, with what capability, along which path |
| Assessment | Likelihood and impact, on a defined and written scale |
| Treatment | The measure adopted for each risk, or a reasoned acceptance |
| Annex I coverage | Requirement by requirement: applicable or not, and why |
| Residual risks | Accepted, by whom, with what information to the user |
That last row is what feeds Annex II point 5 — known circumstances that may lead to a risk.
When to revise it: at every major architecture change, at every added exposed feature, at every change in the assumed deployment environment, and at minimum annually.
Threat modelling
The risk assessment is a document; threat modelling is the workshop that produces it. Run it at design time, not afterwards.
A practical run, two to four hours per scope:
- draw the data flow and set the trust boundaries;
- for each boundary, enumerate threats against a stable grid — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege;
- keep the credible scenarios, discard the others with the reason;
- attach a countermeasure or an acceptance to each scenario kept;
- derive test criteria from them.
The deliverable is a diagram and a list. It is filed with the technical documentation and feeds the traceability matrix.
The test plan
Annex I, Part II, point 3 requires effective and regular security tests and reviews. “Regular” implies a written cadence that is actually kept.
| Test type | What it covers | Typical cadence |
|---|---|---|
| Composition analysis (SCA) | Third-party component vulnerabilities | Every build |
| Static analysis (SAST) | Defects in the code you write | Every build |
| Secret scanning | Keys and credentials in code | Every build |
| Configuration analysis | Hardening, infrastructure as code | Every build |
| Dynamic analysis (DAST) | Behaviour of the exposed application | Per version |
| Fuzzing | Robustness of input parsers | Continuous on exposed components |
| Security code review | Sensitive functions: authentication, cryptography, input parsing | Per sensitive change |
| Penetration testing | Whole-system view, chaining of defects | Annual, and before major releases |
Each test must produce a dated, retained report: that is the evidence for the requirement. A test run without an archived report does not exist for an auditor.
Hardening by default
The secure-default-configuration requirement translates into a written and automatically tested hardening baseline:
- no default credentials shared across units;
- no service or port open without functional need;
- debug interfaces absent from production builds;
- encryption enabled by default on flows and stores;
- logging enabled, with a documented way to disable it;
- a tested reset to original state procedure.
An automated install test from the factory state is the most effective control: it verifies what the customer actually receives, rather than what the documentation claims.
Frameworks to use
Pending harmonised standards being cited in the Official Journal:
| Framework | What it covers |
|---|---|
| IEC 62443-4-1 | Secure development process |
| IEC 62443-4-2 | Technical component requirements |
| NIST SP 800-218 (SSDF) | Secure development practices |
| ETSI EN 303 645 | Consumer IoT |
| EN 18031-1/-2/-3 | Radio equipment — reusable work |
| ISO/IEC 27001 | Information security management system |
| ISO/IEC 29147 and 30111 | Vulnerability disclosure and handling |
| ISO/IEC 18974 | OpenChain — open source security assurance |
Important caveat. Applying these frameworks confers no presumption of conformity under the Regulation until they are harmonised standards cited in the OJ. They make the demonstration easier and supply reusable evidence; they do not replace the demonstration.