Implementing security-by-design in the CRA

Security-by-design in the CRA is not a slogan but a requirements catalogue

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 – not uniformly, but 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; those who ignore them risk the highest tier of fines.

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 at placing 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 not a wish list but the basis of the risk assessment, which is subject to documentation under Article 13 and Annex I. Threat modeling is the recognised 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. Four building blocks carry the process:

• 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 is oriented to the expected product lifetime (guidance value at least five years).

The decisive point for most organisations: this is not a greenfield project. The secure SDLC is integrated into an existing development process – as an addition of gates, checklists and automation, not a rebuild.

Security-by-default – the often 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. This is exactly where many IoT and embedded products fail in practice – and exactly where Annex I intervenes.

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 rather than merely disabled.
• 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 machine-readable – CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 (cf. BSI TR-03183-2 v2.1.0), at least at the level of top-level dependencies; there is no general obligation to publish it. The technical documentation must be kept for ten years from placing on the market.

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, the final report follows two different deadlines: 14 days after a corrective measure becomes available for actively exploited vulnerabilities, and one month after the 72-hour notification for severe security incidents. Early warning within 24 hours, full notification within 72 hours.

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 %.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) supports manufacturers in integrating security-by-design into existing development – not as a paper exercise but along a robust secure SDLC: threat modeling and risk assessment, hardening and default concepts, SBOM setup, verification via SAST/DAST/SCA and product pentest, and preparation of the technical documentation. The focus is on concentrating effort, on a risk basis, where it delivers the greatest protective benefit.

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.