EU Cyber Resilience Act — Guide for Security Engineer

Under Article 13, the manufacturer bears primary responsibility for product security, but that accountability flows directly to the engineering teams who make design decisions. Security engineers are expected to implement the security requirements set out in Annex I Part I, covering areas including secure configuration, minimal attack surface, protection of data in transit and at rest, and the ability to receive security updates. Failures at the engineering level — unpatched dependencies, hardcoded credentials, disabled security features — constitute non-conformity that can expose the manufacturer to market surveillance action and financial penalties up to €15 million or 2.5% of global annual turnover.

Annex I Part I lists fourteen security properties that products with digital elements must satisfy. These include: minimal attack surface by default, no known exploitable vulnerabilities at the time of placing on the market, the ability to update components securely, confidentiality and integrity of data, protection against unauthorised access, and resilience against denial-of-service conditions. Security engineers should map each requirement to a specific control in the product's architecture — for example, mutual TLS for data-in-transit confidentiality, signed firmware updates for integrity, and rate-limiting on authentication endpoints for resilience. Harmonised standards published under the CRA will provide presumption of conformity; tracking the EN 303 645 and IEC 62443 series is advisable until dedicated CRA standards are adopted.

Annex I Part II requires manufacturers to identify and document components, including by producing a Software Bill of Materials in a machine-readable format such as CycloneDX or SPDX. Security engineers own the accuracy of this SBOM and must ensure it is updated with each release. When new CVEs are published, engineers must assess each one against the product's component inventory: determine whether the vulnerable component is present, whether the vulnerable code path is reachable, and whether the product configuration mitigates the issue. CRA Recital 64 expects vulnerability management to be systematic, not ad hoc. Tooling that automates SBOM generation from build pipelines and watches NVD feeds for affected components significantly reduces manual triage burden.

Article 14 imposes strict notification timelines on manufacturers: an early warning to ENISA and the relevant national CSIRT within 24 hours of becoming aware of an actively exploited vulnerability, a full notification within 72 hours, and a final report within 14 days. Security engineers are typically the first to assess whether a reported or discovered vulnerability meets the 'actively exploited' threshold. Establishing a clear internal escalation path — from initial triage to PSIRT notification to legal sign-off — ensures that the clock does not run out during internal deliberation. Security engineers should also participate in drafting CSAF advisories, providing the technical accuracy that gives published advisories operational value for downstream users.

Begin by auditing the product's existing dependency inventory against NVD for known critical vulnerabilities — this gives an immediate compliance baseline. Next, integrate SBOM generation into the CI/CD pipeline using a tool that outputs CycloneDX or SPDX. Then map each Annex I Part I control to existing architecture documentation and identify gaps. Establish a threat model for the product if one does not exist, and record residual risks in a security assessment document that will form part of the technical file. Publish a security.txt file referencing the CVD contact address, and confirm internally who owns the Article 14 notification obligation. Review the CRA readiness score on CVD Portal to prioritise remaining gaps.