Implementing security-by-design in the CRA

Security by design in the CRA: a verifiable set of requirements

The Cyber Resilience Act (Regulation (EU) 2024/2847) turns "security-by-design" and "security-by-default" from a best-practice aspiration into a verifiable set of obligations. The concrete requirements are set out in Annex I Part 1 of the Regulation. They apply per product and must be applied on the basis of the risk assessment under Article 13, to the depth that the specific product and its context of use require. Manufacturers who meet and can evidence these requirements hold the technical core of CRA conformity; infringements of Annex I fall under the highest tier of fines (Article 64(2)).

On the timeline: since 11 September 2026 the reporting obligations under Article 14 apply as the first hard manufacturer duty. Full applicability of all product requirements in Annex I - and thus the continuous security-by-design obligation - takes effect on 11 December 2027. The seemingly long lead time is deceptive: secure product design cannot be bolted on shortly before a deadline, because it touches architecture, development process and supply chain. This article is a factual overview and does not replace legal advice in an individual case.

What Annex I Part 1 concretely requires

The cybersecurity requirements translate into a verifiable catalogue. Key points:

• Delivery without known exploitable vulnerabilities - the state when made available on the market must be "clean".
• Secure default configuration (security-by-default), including the ability to reset to a secure baseline.
• Protection against unauthorised access via authentication and access management (least-privilege).
• Protection of confidentiality - encryption at rest and in transit - and of the integrity of data, commands and configuration.
• Data minimisation: process only what the function requires.
• Availability of essential functions and resilience against denial-of-service.
• Attack-surface minimisation and defense-in-depth.
• Logging and monitoring of security-relevant events.
• Update capability including secure update mechanisms - signed, authenticated, ideally automatable.

This list is the basis of the risk assessment, which is subject to documentation under Article 13 and Annex I. Threat modeling is an established method to justify which of these requirements apply and to what depth. More in the Cyber Resilience Act overview.

From catalogue to process: the secure development lifecycle

Annex I Part 1 describes the "what". The "how" is delivered by a secure product development lifecycle (secure SDLC), for which established references such as IEC 62443-4-1 are suitable. The process consists of four building blocks:

• 1. Risk assessment as the starting point. Threat modeling (e.g. STRIDE over data-flow diagrams) determines protection needs and attack paths, yielding a traceable mapping of which requirement is covered by which measure.
• 2. Secure architecture and implementation. Hardening, secure defaults, secrets management, secure-coding guidelines and dependency governance with an SBOM from the start.
• 3. Verification. SAST, DAST and SCA in the pipeline, complemented by product pentest and security reviews - each with documented results for the technical file.
• 4. Operations and maintenance. Vulnerability handling, a coordinated vulnerability disclosure (CVD) policy and update provision across the entire support period, which reflects the expected use time (at least five years, shorter only where the expected use time is shorter, Article 13(8)).

For organisations with existing development, the secure SDLC can be integrated into the existing process by adding gates, checklists and automation. A comparison against Annex I shows what is missing.

Security-by-default - the easily overlooked part

The product must be secure as shipped, without the customer having to reconfigure first. In concrete terms: no default passwords (instead, enforced setup of individual credentials on first start), minimal open ports and services, disabled debug and maintenance interfaces, secure cryptographic presets and a defined, secure reset state. These are the points addressed by Annex I, Part I, point (2)(b), (d) and (j).

A worked example: the networked control unit

A manufacturer sells a network-capable control unit with a web interface and firmware update. How could security-by-design be implemented schematically?

• Threat modeling: the data-flow diagram shows three trust boundaries (web UI, update channel, fieldbus). STRIDE identifies, among others, spoofing on the update channel and elevation of privilege via the web UI.
• Secure defaults: no shipped password; an individual password is enforced at first login. Telnet and open debug ports are disabled ex works.
• Least-privilege & attack-surface reduction: the web-UI process runs with minimal rights; unneeded services are removed from the firmware.
• Secrets management: no hard-coded keys in the firmware; device-specific keys in the secure element.
• Secure update mechanism: signed firmware, signature verification before flashing, rollback protection.
• Verification: SCA generates the SBOM, DAST tests the web UI, a product pentest confirms the measures. All results feed the technical file.

Evidence in the technical documentation (Annex VII)

Security-by-design only has regulatory effect if it is evidenced. The technical documentation under Annex VII bundles the proof: risk assessment, design and architecture decisions, verification results and the software bill of materials (SBOM). The SBOM must be drawn up in a commonly used machine-readable format covering at least the top-level dependencies (Annex I, Part II, point 1); BSI TR-03183-2 (v2.1.0) specifies CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1. There is no general obligation to publish it. The technical documentation must be kept for at least ten years after placing on the market or for the support period, whichever is longer.

This chain of evidence links security-by-design to the obligations in force since 11 September 2026: anyone who must serve the reporting cascade under Article 14 needs functioning vulnerability handling. As a reminder, reporting is staged: early warning without undue delay and in any event within 24 hours of becoming aware; notification with the general information available without undue delay and in any event within 72 hours; final report no later than 14 days after a corrective or mitigating measure is available (actively exploited vulnerability) or within one month of the notification (severe incident having an impact on the security of the product).

The effort is worth the diligence: infringements of Annex I as well as Articles 13/14 can be sanctioned with up to EUR 15 million or 2.5 % of global annual turnover (whichever is higher). For other obligations the tier is up to EUR 10 million or 2 %, and for false information to authorities up to EUR 5 million or 1 %. Article 64 is not among the provisions that apply early and applies from 11 December 2027 (Article 71(2)); the German implementing act (Bundestag printed paper 21/6134), which is to set the authority and fining procedure, had been neither adopted nor promulgated as of 9 October 2026.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) helps manufacturers make security by design demonstrable: a risk assessment per product with a threat model, a review of an existing development process against Annex I (for example against IEC 62443-4-1), an SBOM chain from the build and the preparation of the technical documentation. Penetration testing is not part of our offering.

A sensible starting point is clarifying your own exposure and product class. Use the exposure check, learn about the right approach for small and medium-sized enterprises or for your sector - or get in touch directly with the CRA team. This article does not replace legal advice in an individual case.