Who is accountable when secretless access still fails in production?

Accountability sits with the team that owns the workload identity, the federation relationship, and the surrounding access policy. If the platform, application, and security team each assume the other controls the trust path, offboarding and review will fail even when the credential itself is no longer stored locally.

Why This Matters for Security Teams

secretless access does not remove accountability; it changes where control is exercised. The workload identity, federation trust, and access policy still determine whether a session is legitimate, so failures usually come from ownership gaps rather than missing passwords. NHI Management Group research on the Guide to the Secret Sprawl Challenge shows how fragmented secrets and identity controls make central oversight difficult, even when teams believe they have reduced risk.

For security teams, the practical issue is not whether a secret exists locally. It is whether the right team can prove who issued trust, who approves access, and who is responsible when a federation rule, token exchange, or policy exception fails. That is why guidance in the OWASP Non-Human Identity Top 10 treats NHI governance as an ownership problem as much as a technical one.

In practice, many security teams only discover the accountability gap after offboarding breaks, an integration keeps working past its intended scope, or incident response finds that no single group can change the trust path quickly enough.

How It Works in Practice

In production, accountable secretless access depends on three things: ownership of the workload identity, ownership of the federation relationship, and ownership of the policy that authorises the call. A service account, OIDC trust, SPIFFE identity, or cloud workload identity can all be configured without storing long-lived secrets, but those controls still need a named operator and a clear review cycle. NIST control expectations in NIST SP 800-53 Rev. 5 Security and Privacy Controls support this by tying access decisions to governance, review, and least privilege.

Operationally, teams should map each trust path to one accountable owner and one backup approver. That owner is responsible for:

• Defining who or what the workload may impersonate.
• Reviewing federation trust, token lifetimes, and audience restrictions.
• Revoking access when the workload changes purpose, namespace, tenant, or deployment boundary.
• Validating that logging shows the workload identity, not just the API caller IP.

NHIMG guidance in the 52 NHI Breaches Analysis reinforces a consistent lesson: failures often occur when identity is decentralised but responsibility is not. Secretless designs are strongest when they pair ephemeral credentials with policy-as-code, explicit federation ownership, and a documented change process for every trust relationship. These controls tend to break down in multi-team platforms with shared clusters, inherited cloud roles, and cross-account federation because nobody owns the full trust path end to end.

Common Variations and Edge Cases

Tighter trust control often increases operational overhead, requiring organisations to balance faster delivery against more frequent review and clearer change management. That tradeoff becomes sharper in platform engineering, multi-cloud, and multi-tenant environments where workloads are redeployed often and identity bindings change faster than tickets do.

There is no universal standard for this yet, but current guidance suggests the accountable party should be the team best positioned to change the trust relationship, not merely the team that runs the application. In some organisations, that is the platform team for federated identity plumbing; in others, it is the product team that owns the workload and its runtime policy. The key is to avoid split accountability, where security approves the model but cannot revoke it, or application teams consume identity but cannot explain its scope.

This is also where incident response matters. If a secretless workload is compromised, the response is usually to disable the trust source, shorten token lifetimes, or cut off federation rather than search for a leaked password. The NHIMG Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for understanding how distributed NHI ownership creates persistent review gaps.

Best practice is evolving, but the accountability rule remains stable: if a team cannot revoke, review, or explain the workload identity relationship, it does not truly own the access.

Related resources from NHI Mgmt Group

• Who is accountable for AI agent access to protected health information?
• Who is accountable when third-party administrators access regulated systems?
• Who should be accountable for frictionless access without weakening security?
• Who is accountable when a digitally connected product fails CRA expectations?