Who is accountable for protecting secrets when an organisation self-hosts its own infrastructure?

Why This Matters for Security Teams

When an organisation self-hosts its own infrastructure, it also accepts full responsibility for how secrets are created, stored, rotated, monitored, and recovered. That includes API keys, certificates, tokens, and service credentials across build systems, production workloads, and admin tooling. The risk is not just exposure. It is persistence, duplication, and invisible privilege drift across systems that teams believe they control.

NHIMG research on secrets sprawl shows why this becomes operational, not theoretical. In the Guide to the Secret Sprawl Challenge, the problem is framed as a lifecycle failure as much as a discovery problem, and the 2025 State of NHIs and Secrets in Cybersecurity highlights how often secrets are duplicated, overused, and left active after access should have ended. That aligns with the broader control model in the OWASP Non-Human Identity Top 10, which treats secret management as a core identity security issue, not a storage problem.

Security teams often underestimate self-hosting because the infrastructure is “inside” the organisation, but secret compromise still moves faster than change control, especially when tooling, CI/CD, and operators all share the same access paths. In practice, many security teams encounter this only after a leaked token has already been reused across multiple systems.

How It Works in Practice

Accountability rests with the organisation because self-hosting removes the vendor boundary that would otherwise absorb some operational duties. The platform owner, security team, and system operators must define who can issue secrets, where they may live, how long they remain valid, and what triggers revocation. That includes backups, logs, patching, recovery procedures, and access reviews. The governance model should map to NIST Cybersecurity Framework 2.0 functions and the control expectations in NIST SP 800-53 Rev. 5 Security and Privacy Controls.

In practice, strong programs treat secrets as governed assets rather than static strings. A workable self-hosted model usually includes:

• Central issuance from a trusted secrets manager, with no ad hoc storage in code, tickets, or chat.
• Short-lived credentials where possible, with rotation tied to job completion or time-to-live.
• Separate controls for human administrators and non-human identities, so service access does not inherit broad human privileges.
• Continuous detection for leaked secrets in source control, build logs, container images, and collaboration tools.
• Documented ownership for every vault, namespace, and application integration.

NHIMG incident research, including the 52 NHI Breaches Analysis, shows that compromise often begins when a credential is exposed in one place and reused somewhere more privileged. Self-hosted environments need this discipline because the organisation must not only protect the secret store, but also every downstream system that trusts it. These controls tend to break down when multiple engineering teams can create or copy secrets without a single revocation process, because no one can confirm what still works after a change.

Common Variations and Edge Cases

Tighter secret governance often increases operational overhead, requiring organisations to balance faster delivery against stricter access control and auditability. That tradeoff is real in self-hosted CI/CD, ephemeral test environments, and hybrid estates where legacy applications cannot yet use dynamic credentials.

There is no universal standard for every deployment model, but current guidance suggests a few exceptions need explicit handling. Air-gapped environments may justify longer rotation intervals, yet they still need ownership, vault approval, and compensating controls. Shared admin credentials are sometimes retained for emergency recovery, but they should be isolated, heavily monitored, and tested under break-glass procedures. Where container images, build pipelines, or developer workstations touch secrets, the attack surface expands beyond the vault itself. NHIMG’s research on the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack is a reminder that secrets often fail at the integration layer, not the vault.

The practical takeaway is simple: self-hosting does not reduce responsibility, it concentrates it. Organisations that assume their internal network or private cloud makes secrets safer tend to discover the opposite when a misconfiguration, stale token, or overbroad service account becomes the fastest path to lateral movement.

Related resources from NHI Mgmt Group

• Who is accountable for protecting self-service account creation and authentication workflows?
• Who should own secrets security and NHI governance across the enterprise?
• Who is accountable when Infrastructure as Code changes create compliance or security failures?
• Who should be accountable for secrets governance when developer productivity and security controls conflict?