When does product security become an identity governance issue under the CRA?

It becomes an identity governance issue when product operation depends on credentials, certificates, support accounts, or remote administration rights that outlive a release cycle. At that point, lifecycle ownership, revocation, and auditability matter as much as code quality. Security teams should manage those identities like governed assets, not hidden implementation detail.

Why This Matters for Security Teams

The EU Cyber Resilience Act makes product security a lifecycle obligation, not just a release-quality concern. Once a product depends on credentials, certificates, support accounts, remote admin paths, or embedded service identities, those controls become part of the product’s security posture and audit trail. The governance question is no longer only “is the code secure?” but “who owns these identities, how are they rotated, and how are they revoked when the product changes?”

This is where product security starts overlapping with identity governance. NHI Management Group research on the Ultimate Guide to NHIs shows that 71% of NHIs are not rotated within recommended time frames, and only 20% of organisations have formal offboarding and revocation processes for API keys. That gap matters under the CRA because hidden identities can become regulated operational dependencies, especially when they persist across releases, vendors, and support channels. Current guidance suggests product teams should treat these identities as governed assets with named ownership, auditability, and documented lifecycle controls, not as implementation detail. The EU Cyber Resilience Act is moving the industry toward that model.

In practice, many security teams discover identity governance gaps only after a support credential, API key, or remote access path has already outlived the release that introduced it.

How It Works in Practice

Under the CRA, product security teams should map every non-human identity that the product needs to function, including build-time secrets, runtime tokens, admin backdoors, vendor support credentials, update-signing keys, and certificates used for device trust. Each identity needs an owner, a purpose, a rotation schedule, a revocation path, and an auditable link to the product version or operational workflow that depends on it. That is the practical bridge between product security and identity governance.

A useful operating model is to manage these identities through the same controls used for privileged access: inventory, classification, least privilege, approval, time-bounded access, and formal offboarding. NHI Management Group research in the lifecycle guidance highlights how weak rotation and poor offboarding turn small credentials into durable attack paths. The operational question under CRA is whether the organisation can prove that a product identity is still needed, still constrained, and still recoverable if compromised.

• Track identities in the product SBOM-like record, but do not stop at software components.
• Separate product runtime identities from human support access and vendor break-glass access.
• Use short-lived credentials where possible, and document exceptions where hardware or legacy systems require longer validity.
• Test revocation as part of product change management, not only incident response.
• Log identity issuance, use, rotation, and removal so audit evidence exists when regulators ask.

Where organisations get this wrong, identity ownership sits in engineering tickets, while the product team assumes the IAM team will clean up credentials after deployment. These controls tend to break down in embedded, OT, or appliance-like environments because credentials and certificates are often hard-coded, long-lived, and difficult to rotate without device access.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance release velocity against auditability and revocation discipline. That tradeoff becomes sharper in legacy products, device fleets, and third-party integrations where static credentials are difficult to eliminate. Best practice is evolving, but there is no universal standard for every product category yet.

In practice, CRA-driven governance looks different across environments. A cloud-native service can often move toward ephemeral tokens, automated rotation, and policy-based access, while an industrial or offline product may need compensating controls such as hardware-backed certificates, constrained remote support windows, and explicit acceptance of residual risk. The key is not whether the identity is “human” or “non-human” in a narrow sense, but whether product operation depends on a credential that can survive beyond the intended trust boundary.

The strongest programs align product, security, and compliance around evidence. The regulatory and audit guidance from NHI Management Group helps frame that evidence, while the NIST Cybersecurity Framework 2.0 is a practical reference for ownership, protection, detection, response, and recovery. Under the CRA, the edge case is usually not whether an identity exists, but whether the organisation can prove it is governed across the full product lifecycle.

Related resources from NHI Mgmt Group

• When does NHI compliance become an operational security issue?
• What makes agentic AI an NHI governance issue?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?