Who should be accountable for CRA readiness in a connected device programme?

Why This Matters for Security Teams

CRA readiness is not just a compliance exercise. It is an ownership problem across product engineering, security, operations, and supply chain management. The EU Cyber Resilience Act raises the bar on secure-by-design development, vulnerability handling, and evidence that persists across the device lifecycle. If accountability is ambiguous, the programme tends to fail at the exact moments regulators and customers ask for proof.

NHI Management Group has documented the same pattern in identity operations: 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, and 68% do not know how to fully address NHI risks in the first place, as noted in the Ultimate Guide to NHIs. The lesson translates directly to connected device programmes: if one team provisions, another patches, and a third owns audit evidence, no one owns the full control story.

Security teams should treat CRA readiness as a governance design issue, not a late-stage review. Current guidance suggests accountability must follow the team that can influence build, release, update, and decommissioning decisions end to end. In practice, many programmes discover this only after a defect report, a failed supplier attestation, or a missing update record has already exposed the gap.

How It Works in Practice

The practical model is shared accountability with a single named owner for programme governance. That owner is usually the product or platform lead who can coordinate engineering, security, legal, procurement, and operations. They are accountable for the control system, while individual functions remain responsible for their own evidence and actions. This is the difference between “everyone is involved” and “someone can answer the regulator’s question.”

For connected device programmes, the ownership map should cover device design, software supply chain, secure updates, vulnerability intake, logging, and end-of-life handling. The most reliable teams turn these into explicit handoffs with artefacts at each stage: threat model sign-off, component inventory, update policy, supplier assurance, and post-release monitoring. That is where the EU Cyber Resilience Act matters operationally, because it makes lifecycle evidence a continuous obligation rather than a one-time declaration.

For identity-heavy device environments, the same discipline is described in the Ultimate Guide to NHIs: ownership must follow credentials, rotation, offboarding, and visibility. That is especially important when devices use service accounts, certificates, or update tokens that outlive the people who created them.

• Assign one programme owner for CRA governance and evidence continuity.
• Map each lifecycle stage to a named function and a required artefact.
• Require suppliers to provide security and update evidence in a reusable format.
• Track firmware, software, and identity credentials together, not as separate registers.
• Test who can produce proof of remediation, not just who can say the control exists.

These controls tend to break down when device fleets are built from inherited components and multi-tier suppliers, because the evidence chain becomes fragmented across organisations that do not share the same release cadence.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance speed against auditability. That tradeoff becomes visible in distributed product lines, where local engineering teams move quickly but central security teams need consistent evidence. Current guidance suggests central governance with federated execution is the most practical model, but there is no universal standard for this yet.

One common edge case is the outsourced or white-label device programme. In those environments, the brand owner may be accountable for CRA readiness even when most implementation work sits with a contract manufacturer or software supplier. Another edge case is a product that ships before its update pipeline is mature. In that situation, readiness depends less on the initial release and more on whether the organisation can prove safe patching, revocation, and incident response after shipment.

This is also where identity governance matters. If device credentials, service accounts, or API keys are handled by different teams without a common offboarding process, the programme will struggle to show evidence continuity. Organisations that already have weak NHI lifecycle controls should treat that as a CRA risk signal, not a separate hygiene issue.

In practice, the strongest model is a single accountable owner backed by shared control owners, because regulatory questions rarely stop at one team boundary.

Related resources from NHI Mgmt Group

• Who is accountable when a malicious connected app is authorised by an employee?
• Who is accountable when identity data from a connected system becomes unreliable?
• Who is accountable when a device still has access after administrators believe it has been revoked?
• Who is accountable when CUI is moved to an unencrypted or unauthorised USB device?