Who is accountable when product identities and secrets are exposed?

Why This Matters for Security Teams

When product identities and secrets are exposed, the issue is not just leakage, but who had the duty to prevent it, detect it, and revoke it. Under the EU Cyber Resilience Act, accountability follows the product manufacturer, even when development, hosting, or operational tooling is outsourced. That means security teams need a clear ownership model for non-human identities, secret issuance, and revocation across the product lifecycle.

This is especially important because secrets failures are usually systemic, not isolated. NHIMG research on Guide to the Secret Sprawl Challenge shows how fragmented secret storage, duplicate managers, and inconsistent access paths make it hard to prove control. In the broader 52 NHI Breaches Analysis, exposed machine identities and unmanaged credentials repeatedly turn into downstream compromise, not mere compliance findings. In practice, many security teams encounter accountability gaps only after a leaked secret has already been used to move laterally, rather than through intentional lifecycle governance.

How It Works in Practice

For product teams, accountability should map to the entity that ships the product and controls its secure-by-design posture. That usually means the manufacturer owns the policy, evidence, and remediation path, even if a cloud provider, SaaS partner, or MSSP operates part of the stack. The practical test is simple: who can change the code, rotate the secret, revoke the identity, and demonstrate auditability? If the answer is not the product owner, then the operating model is incomplete.

Current guidance suggests treating product identities as governed assets with explicit lifecycle controls:

• Assign a named owner for each secret, token, certificate, and service identity.
• Use short-lived credentials where possible, with rotation tied to deployment and release events.
• Separate build-time, runtime, and human admin access so a single exposure does not cascade.
• Log issuance, use, and revocation events so exposure can be traced to a product, version, and environment.
• Test recovery paths, because discovery without revocation is not real control.

Implementation also needs to align with the product’s trust boundary. The OWASP Non-Human Identity Top 10 reinforces that machine credentials fail most often when ownership, rotation, and privilege boundaries are unclear. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because static secrets create longer exposure windows and make accountability harder to prove after the fact. These controls tend to break down in multi-tenant product platforms where environment boundaries are blurred and no single team can revoke access quickly.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance clear ownership against release velocity and vendor complexity. That tradeoff becomes sharper when the product depends on third-party SDKs, embedded agents, or managed services that can introduce secrets outside the primary SDLC.

There is no universal standard for this yet, but current guidance suggests treating outsourced components as delegated operations, not delegated responsibility. If a supplier stores or rotates credentials on behalf of the manufacturer, the manufacturer still needs contractual evidence, audit rights, and incident notification triggers. The same logic applies when secrets are injected by CI/CD systems, infrastructure-as-code pipelines, or device provisioning services.

Edge cases also arise when a product is updated frequently or deployed across customer-managed environments. In those cases, ownership must be explicit at the artefact level, not just the company level. NHIMG’s CI/CD pipeline exploitation case study shows why pipeline compromise can expose product secrets even when the application itself is sound. External reporting on AI-enabled intrusion tradecraft, such as the Anthropic report, also underscores that exposed credentials can be rapidly operationalised once discovered.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities in Salesforce?