Ownership should sit with the platform and identity governance functions together, because secure delivery is both an engineering workflow and an access-control problem. The platform team implements the controls, while identity teams define the rules for secrets, permissions, and approvals that must hold across services and environments.
Why This Matters for Security Teams
In a modern platform model, secure delivery is no longer a narrow CI/CD concern. It sits at the intersection of pipeline engineering, identity governance, secrets hygiene, and access approval. That matters because the most common failures are operational, not theoretical: long-lived credentials drift into code, vaults, build logs, and environment variables, while approval paths lag behind deployment velocity. The NIST Cybersecurity Framework 2.0 helps frame this as a governance problem as much as a technical one, especially where ownership boundaries are unclear.
NHI Management Group’s research shows why this is urgent: 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 71% fail to rotate NHIs within recommended time frames. See Ultimate Guide to NHIs — Standards for the underlying governance lens, and the broader context in Ultimate Guide to NHIs — The NHI Market.
Security teams get into trouble when platform engineering assumes identity exceptions can be handled later, while identity teams assume delivery tooling will enforce policy automatically. In practice, many organisations discover the ownership gap only after a secret is exposed or a deployment path is abused, rather than through intentional control design.
How It Works in Practice
Ownership should be split by function but unified by control objective. The platform team owns implementation inside the delivery stack: secret injection, workload authentication, secure defaults, pipeline guardrails, and deployment-time enforcement. The identity governance function owns the policy model: who or what may request access, what approvals are required, how long credentials may live, and what evidence is needed for exception handling. That division aligns with how NIST Cybersecurity Framework 2.0 treats govern, identify, protect, and detect as connected outcomes rather than separate silos.
In practice, mature organisations define secure delivery controls around a few repeatable primitives:
- Workload identity for services, build agents, and deployment jobs instead of shared human credentials.
- Just-in-time access for privileged deployment actions, with automatic expiry and revocation.
- Policy-as-code for approvals, environment restrictions, and secret handling rules.
- Centralised secrets lifecycle rules, including rotation, offboarding, and emergency revocation.
- Audit trails that prove which workload, pipeline, or automation step requested access and why.
This is also where platform and identity teams must co-design blast-radius limits. A pipeline that can deploy to production but cannot read production secrets is safer than one that can do both by default. Likewise, identity governance should not stop at directory permissions. It has to extend into the runtime path where secrets are fetched, tokens are minted, and deployment agents authenticate. The Ultimate Guide to NHIs — Standards section is useful for mapping these controls to lifecycle and governance expectations.
Where possible, the platform team should own the implementation details, while identity governance owns the control requirements and exception policy. These controls tend to break down when legacy release tooling hardcodes shared service accounts across multiple environments because revocation and attribution become nearly impossible.
Common Variations and Edge Cases
Tighter secure delivery controls often increase release friction, so organisations have to balance speed against assurance. That tradeoff is especially visible in high-change environments, where frequent releases make manual approvals and static credentials unsustainable. Current guidance suggests the right answer is not more blanket exceptions, but narrower scope, shorter-lived access, and clearer ownership of each control point.
Some environments need additional nuance. Regulated workloads may require a separate approval chain for production secrets, while internal developer platforms may allow lower-risk paths to be self-service with policy enforcement embedded in the tooling. Shared platform services can also complicate ownership because a single control, such as secret rotation, may span infrastructure, application, and identity teams. In those cases, best practice is evolving toward a control owner model rather than a team-only model, where each control has one accountable owner even if multiple teams implement it.
The key exception is when delivery tooling itself becomes the source of authority, such as in GitOps, ephemeral runners, or delegated deployment systems. Then platform engineering must enforce technical constraints, but identity governance still sets the rules for trust, approval, and revocation. Organisations that do not formalise that boundary often end up with controls that look strong on paper but are easy to bypass in emergency release paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 | Covers governance of supply-chain and service-provider controls in delivery workflows. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secrets rotation and lifecycle control for non-human identities. |
| CSA MAESTRO | GOV-01 | Defines governance responsibilities for agentic and automated platform controls. |
Assign accountable owners for delivery controls and review them as governed supply-chain dependencies.
