Who should own CRA identity controls across product and platform teams?

Why This Matters for Security Teams

CRA identity controls are not a paperwork exercise. They determine who can create, bind, rotate, approve, and revoke the identities that products and platforms rely on to function securely. When ownership is unclear, the result is usually inconsistent secret storage, weak revocation paths, and access that survives long after the original business need has ended. That is exactly the kind of condition the EU Cyber Resilience Act is meant to pressure organisations to fix.

NHI Management Group research shows how common the failure pattern already is: 96% of organisations store secrets outside secrets managers, and only 5.7% have full visibility into service accounts. The Ultimate Guide to NHIs makes the operational point clear: if identity ownership is scattered across teams, lifecycle controls break first at the handoff points. In practice, many security teams encounter excessive access and unreleased credentials only after a product release, incident, or audit has already exposed the gap rather than through deliberate ownership design.

How It Works in Practice

The cleanest operating model is to separate policy ownership from implementation ownership. Platform security, IAM, or identity engineering should own the control framework for CRA identity lifecycle requirements because they govern the systems that issue, scope, observe, and revoke access. Product teams should own product-specific intent, such as which services need to call each other, which environments are in scope, and what customer-facing trust boundaries exist. Product security then verifies that those design choices map to enforceable controls.

That division works best when there is a single identity lifecycle path for non-human identities, backed by clear approval and evidence collection. In practical terms, the owning team should define:

• how new service identities are requested and approved
• what secrets or workload credentials are issued
• where credentials are stored and rotated
• how privilege is limited by environment, workload, and purpose
• how revocation happens during decommissioning, incident response, or supplier exit

For organisations already wrestling with service account sprawl, the Top 10 NHI Issues research is useful because it shows that ownership failures are rarely just technical. They are often process failures between engineering, security, and operations. Current guidance suggests that identity controls should be policy-driven and auditable, not left to each product team to improvise in pipelines or application code. That aligns with the CRA’s expectation that security outcomes be repeatable across product lines, not reinterpreted per team or release train.

When implementation needs to extend across CI/CD, cloud, and runtime environments, the owning team should standardise on one control pattern for credential issuance and one for revocation evidence, then let product teams consume that pattern through approved interfaces. These controls tend to break down when legacy applications require embedded secrets because the retirement path is usually unclear and revocation becomes manual.

Common Variations and Edge Cases

Tighter ownership often increases operational overhead, requiring organisations to balance strong governance against product delivery speed. That tradeoff is real, especially in companies where platform security is small and product teams ship frequently.

There is no universal standard for this yet, but the best practice is evolving toward a federated model. Platform or IAM should own the control plane, while product teams own application-level inventory and business justification. In environments with many embedded integrations, supplier-managed components, or multiple cloud accounts, some responsibility may also sit with infrastructure or SRE teams because they control the runtime where identities are actually used.

The main edge case is a product team that builds and operates its own identity stack. Even then, the control expectations should not change: one accountable owner, one lifecycle policy, and one evidence trail. A second edge case is third-party or embedded software, where the product team may not directly manage the identity mechanism but still owns the risk acceptance and inventory accuracy. The 52 NHI Breaches Analysis shows why this matters: identity incidents often spread across teams because no one owns the full chain from provisioning to revocation. For that reason, CRA identity ownership should be assigned at the control layer, not left to whichever team happens to implement the last change.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams evaluate identity controls inside a larger security platform?
• Who should own MCP governance, identity teams or platform teams?
• Who should own access decisions when identity controls are spread across multiple platforms?