Who is accountable for secrets and access control under the CRA?

Who owns secrets and access control when the CRA is on the table?

The CRA changes the accountability question by pushing responsibility toward the product side, not just the operator side. For secrets and access control, that means the manufacturer, and often the software provider behind the product, must be able to show how credentials, privilege, logging, and updates are governed as part of the product lifecycle.

What accountability means in practice across the product lifecycle

Under the CRA, accountability is not limited to “who runs it in production.” It extends to the people who design, ship, and maintain the product, because weak secret handling or overbroad access can be baked in before deployment. A useful way to think about this is that the product team owns the secure defaults, while the operator inherits only the controls the product makes possible.

That has direct implications for secrets management: if API keys, service credentials, certificates, or update credentials are embedded, reused, or difficult to rotate, the product side has created a security obligation that cannot be shifted away after release. Guidance on the Ultimate Guide to NHIs is useful here because the same lifecycle question applies to workload credentials, service accounts, and other non-human access paths that the product must support safely.

Access control follows the same pattern. The manufacturer has to provide role separation, least-privilege defaults, and meaningful admin boundaries; the software provider has to preserve those controls through patches, cloud services, and updates. If the product exposes privileged functions without clear authorization checks, the accountability problem is a design problem, not merely an operational mistake.

Why secrets and access control are central CRA obligations

Security obligations under the CRA are shaped by how the product behaves at release and after deployment. That is why secrets, authorization, logging, and update integrity matter together: they are the controls that prove the product can be operated without handing out standing privilege or leaving long-lived credentials exposed. The practical test is whether the product enables secure administration without forcing customers to compensate for weak defaults.

For secrets specifically, the most important design choice is whether the product can avoid long-lived shared material. If it cannot support rotation, scoped credentials, or strong isolation between environments, then the product side has created a recurring exposure. The Secrets Management Guide is a good reference point for the control patterns that matter, especially centralisation, rotation, and movement toward secretless workload identity.

For access control, the accountability question is whether privileged functions are constrained by design. A product that allows broad administrative access, weak separation between users and operators, or unclear control over updates creates the kind of condition that CRA oversight is meant to address. The product side must be able to evidence that access is intentionally granted, limited, and reviewable, not merely possible.

How security, engineering, and compliance should divide the evidence burden

The right answer is a joint one. Security should define the control expectations, engineering should implement them into the product and release process, and compliance should collect the evidence that shows the obligations are met. That division matters because CRA accountability is not satisfied by policy language alone; it needs technical proof that secrets, privilege, logging, and update paths are controlled in the shipped product.

Manufacturers and providers should be ready to show where secrets live, how they are generated, whether they are scoped, when they expire, and who can rotate them. They should also be able to show how access is authorised for support, maintenance, and emergency actions, and how those actions are logged. For teams building or reviewing those controls, the API Key Management Guide is directly relevant because it frames creation, scoping, rotation, and revocation as lifecycle obligations, not one-time setup tasks.

If the product includes machine-to-machine access, the same evidence should extend to non-human credentials and service identities. Product teams often underestimate this because the control looks “internal,” but under CRA-style accountability that internal access path is part of the product’s security posture and must still be governed.

Risk and Threat Considerations

Weak ownership of secrets and access control creates a direct exposure path: leaked credentials, overprivileged functions, and poor update governance can let an attacker pivot from a small foothold to product-wide compromise. The risk is not only theft, but also persistence, unauthorized change, and loss of trust in the software supply chain.

Failure mechanism: Long-lived secrets, broad admin rights, or poorly designed update channels let an attacker reuse a credential, abuse a support path, or modify the product without triggering effective controls.

Impact: The result can be unauthorised access, tampered updates, lateral movement across connected systems, and regulatory exposure for the manufacturer or software provider that failed to design the control correctly.

Practitioner Guidance

What to verify: Check whether the product can prove who owns each secret class, who can rotate or revoke it, and whether administrative actions are separately authorised and logged. If that evidence is missing, treat the control as incomplete even if the product “works” operationally.

Decision rule: If a credential or privileged path is embedded in the product design, prioritise redesign, scoping, and rotation support before relying on downstream operational monitoring. If the product cannot support those controls, the accountability issue belongs with the product owner, not the customer.

Practitioner takeaway: Under the CRA, the strongest posture is to design secrets and access control so the product can be operated securely by default, with clear evidence that ownership, privilege, and lifecycle control stay with the manufacturer or software provider.

Related resources from NHI Mgmt Group

• Who is accountable for access control evidence under SOC and SOX?
• Why do organisations struggle to keep secrets and privileged access under control in fast-moving environments?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?