Who is accountable when a product cannot prove secure design under the CRA?

Why This Matters for Security Teams

Under the EU Cyber Resilience Act, accountability is not reduced to a single technical owner when secure design cannot be demonstrated. The legal duty sits with the organisation placing the product on the EU market, but the operational burden spans product leadership, engineering, AppSec, compliance, legal, and PSIRT. That matters because a failure to prove secure design is usually a failure of evidence, traceability, or governance, not only code quality. The EU Cyber Resilience Act raises the standard from informal assurance to defensible lifecycle control.

Security teams often assume that passing tests or completing a design review is enough. Under CRA-style expectations, teams need to show how security requirements were set, how risks were assessed, how vulnerabilities were handled, and who approved the release decision. That means accountability must be visible in the product record, not only in meeting notes or ticket comments. A mature control set often resembles the discipline described in NIST SP 800-53 Rev 5 Security and Privacy Controls, where evidence, monitoring, and authorisation are treated as core control outcomes rather than afterthoughts. In practice, many security teams encounter accountability only after a regulator, customer, or incident responder asks for the evidence chain, rather than through intentional design governance.

How It Works in Practice

In operational terms, accountability should be assigned across the product lifecycle, not only at release. The organisation placing the product on the market remains responsible for compliance, but each function should have a defined role in producing and preserving evidence. Product management owns security requirements and intended use. Engineering owns secure implementation and design decisions. AppSec validates threat modelling, testing, and remediation expectations. Compliance tracks regulatory mapping and document completeness. PSIRT owns vulnerability intake, triage, and remediation coordination.

That division works only if it is backed by a durable evidence model. A CRA-ready record usually needs to answer four questions: what security requirements were defined, what threats were considered, what controls were implemented, and what residual risks were accepted. For many organisations, this maps well to the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, even though CRA is a separate regime. The practical value is simple: if ownership is explicit, evidence can be assembled quickly; if ownership is implicit, the audit trail fragments across tools and teams.

• Assign a named owner for secure design evidence at product level.
• Require threat modelling and security requirements before build completion.
• Link test results, remediation tickets, and release approvals to the product record.
• Define who can accept residual risk and under what conditions.
• Ensure PSIRT can prove vulnerability handling and customer communication paths.

The model breaks down when product teams rely on generic corporate compliance checklists but cannot tie them to a specific software version, component inventory, or release decision, because the evidence no longer proves the product was secure by design.

Common Variations and Edge Cases

Tighter accountability often increases process overhead, requiring organisations to balance release speed against evidentiary confidence. That tradeoff becomes sharper in distributed engineering environments, where product lines, outsourced development, and shared platform teams blur responsibility. Best practice is evolving, but current guidance suggests that no single team should act as a catch-all for every security duty unless the organisation has deliberately centralised product security governance.

One common edge case is the use of shared libraries, open-source components, or upstream firmware. In those environments, the organisation may not control the original design, but it still controls whether the product is safe to place on the market. Another edge case is a product that is secure in a lab but not explainable in documentation. CRA risk is not limited to exploitable flaws; it also includes inability to prove that the secure design process existed and was followed. That is why evidence ownership matters as much as technical ownership.

Where products include connected services, the accountability picture can extend beyond the device or application itself to update channels, telemetry, and vulnerability disclosure processes. The EU Cyber Resilience Act makes that broader lifecycle responsibility difficult to outsource completely. If the organisation cannot show who signed off on security claims, who reviewed exceptions, and who maintained the technical file, the accountability gap becomes a compliance gap as well.

Related resources from NHI Mgmt Group

• Who is accountable when audit evidence cannot prove least privilege?
• Who is accountable when a contractor cannot prove CMMC identity controls?
• Who is accountable when a crypto firm cannot prove AML/CFT compliance?
• Who is accountable when a compliance tool cannot prove access control operation?