EU Cyber Resilience Act — Guide for VP of Engineering

The VP of Engineering carries management-level accountability for the technical implementation of CRA obligations. Article 10 places ongoing security obligations on manufacturers throughout the product support period — which means engineering teams cannot treat security as a launch-gate-only concern. The VP of Engineering must embed CRA checkpoints into the SDLC: design review, code review, pre-release security validation, and post-release monitoring. Under Annex I Part II, products must be shipped without known exploitable vulnerabilities — which requires the VP to ensure that unresolved security findings do not get deprioritised in favour of feature work without formal risk acceptance. The VP also owns the engineering response to Article 14 incident reporting windows, which demand fast diagnosis and patch timelines.

Day-to-day, a VP of Engineering running a CRA-compliant programme is managing a security backlog alongside the product backlog. This means setting policies for how critical and high CVEs are prioritised — a 30-day remediation SLA for criticals, for example — and ensuring the engineering capacity exists to meet them. Secure SDLC adoption requires that threat modelling, dependency scanning, and security review gates are part of the definition of done for relevant features, not optional additions. The VP of Engineering also approves build vs buy decisions for compliance tooling: whether to integrate SBOM generation into existing CI/CD tooling or procure a dedicated platform, and whether OTA update infrastructure is built in-house or sourced from a qualified vendor.

The VP of Engineering is the primary peer of the CISO and CTO on CRA matters within the organisation. The CISO sets security policy; the VP of Engineering ensures it is implemented. When the legal counsel raises a regulatory question about the engineering team's practices, the VP of Engineering provides the answer. Coordination with the PSIRT manager is critical during active vulnerability response: the VP of Engineering must ensure that remediation engineers are available, can triage quickly, and that patch delivery does not bottleneck on engineering capacity. The compliance officer needs regular engineering status updates for the technical file and conformity documentation — the VP of Engineering is responsible for ensuring those inputs are accurate and timely.

The most common VP of Engineering trap in CRA compliance is treating security obligations as a one-time certification project rather than an ongoing engineering discipline. CRA compliance is not achieved and then maintained passively — it requires sustained engineering investment. A second trap is under-resourcing the security backlog: when security work consistently loses prioritisation to feature delivery, the technical debt accumulates until a serious vulnerability exposes the gap. A third trap is building CRA tooling from scratch when qualified off-the-shelf solutions exist — the build vs buy decision should weigh compliance assurance risk, not just cost. Finally, failing to establish clear escalation paths from security engineer to PSIRT to executive for Article 14-triggering events creates dangerous latency.

Start by mapping your current SDLC against CRA's Annex I obligations and identifying gaps — where are the checkpoints missing, and which teams are most exposed? Conduct a team readiness assessment: do your engineers understand secure coding practices, CRA scope, and how to handle a vulnerability disclosure? Establish a security backlog with clear SLAs for critical, high, and medium findings and confirm you have sprint capacity to meet them. Define the escalation path from security finding to Article 14 notification with named owners at each step. Finally, evaluate your current tooling against SBOM generation, vulnerability scanning, and OTA update requirements — identify gaps and initiate procurement or integration projects with delivery milestones.