The delivery layer is the set of tools and configuration objects that move code from development into release and deployment. It includes pipelines, permissions, service connections, and workflow settings. In identity terms, it is where access, trust, and change control determine whether software can safely move.
Expanded Definition
The delivery layer is the operational control plane that turns source changes into deployable release artefacts. In NHI security, it is not just a build path. It is the place where pipeline identities, service connections, approval rules, branch protections, and environment gates determine whether a change can move safely from development into production. Definitions vary across vendors, but the security meaning is consistent: the delivery layer is where machine-to-machine trust is translated into release authority.
That distinction matters because a pipeline can be technically functional while still being insecure if its credentials are overbroad, its approvals are bypassable, or its secrets are exposed in workflow settings. NHI Management Group treats the delivery layer as part of the identity attack surface, especially when CI/CD systems inherit privileges that outlive the change they were meant to support. Guidance in NIST Cybersecurity Framework 2.0 aligns with this view by emphasising governed access, change control, and continuous monitoring.
The most common misapplication is treating the delivery layer as a pure DevOps efficiency function, which occurs when teams optimise throughput without restricting pipeline identities, secret access, and deployment permissions.
Examples and Use Cases
Implementing the delivery layer rigorously often introduces release friction, requiring organisations to weigh faster deployments against tighter control over who and what can promote code.
- A build pipeline uses a short-lived service connection to fetch artefacts, but only after an approved change record is linked to the release.
- An environment gate blocks production deployment until the workflow identity is scoped to the target subscription and the secret is stored in a managed vault, not in the pipeline definition.
- A team reviews pipeline permissions after reading the Ultimate Guide to NHIs, then removes standing write access from automation accounts.
- A release job integrates with NIST Cybersecurity Framework 2.0 to support access reviews, logging, and alerting when pipeline behaviour changes unexpectedly.
- A security team separates test and production service connections so a compromised lower-tier workflow cannot directly push code into live systems.
These examples are common because the delivery layer often accumulates exceptions over time, especially where multiple teams share pipelines or where automation was assembled before security governance was formalised.
Why It Matters in NHI Security
The delivery layer is where NHI compromise often becomes a production event. If an attacker gains control of a pipeline identity, they may be able to tamper with code, insert malicious dependencies, or deploy altered workloads using legitimate automation paths. That makes delivery-layer governance central to preventing supply chain abuse, secret exposure, and privilege escalation through trusted release tooling.
The scale of the problem is visible in NHIMG research: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, as reported in the Ultimate Guide to NHIs. In practice, that means delivery systems are not just operational infrastructure. They are high-value identity assets that need least privilege, rotation, separation of duties, and auditability.
Organisations typically encounter the consequences only after a compromised pipeline or unexpected production change, at which point the delivery layer becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and improper machine identity handling in delivery systems. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access rights management for systems that move code into production. |
| NIST Zero Trust (SP 800-207) | SC.L2 | Zero Trust principles apply to every release path and service connection in the delivery layer. |
Harden pipeline secrets, rotate credentials, and limit delivery-layer access to the minimum required.
