Start by moving identity checks to the earliest practical stage in delivery, such as pre-merge, build, or pre-deploy gates. Focus on the controls that most often create operational risk, including service account permissions, secret exposure, and deployment credentials. The goal is to make secure identity behaviour the default path for release, not a separate review step.
Why This Matters for Security Teams
Identity controls in DevOps are not just about preventing accidental misconfiguration. They determine whether a pipeline can safely authenticate, authorize, and rotate access without exposing build systems, deploy jobs, or service accounts to unnecessary privilege. NIST’s Cybersecurity Framework 2.0 reinforces that identity and access management must be embedded into operational workflows, not bolted on after delivery.
For release engineering, the main risk is that pipelines often become the quiet path by which secrets are copied, reused, or over-scoped across environments. NHIMG’s Guide to the Secret Sprawl Challenge shows why this matters: secrets do not stay contained when they are handed from developer machines into CI runners, deployment tools, and automation scripts. Once that happens, review controls that focus only on code are too late.
Security teams get the best results when identity checks are treated as release controls, similar to testing or policy validation, rather than as a separate manual approval. In practice, many teams discover pipeline identity gaps only after a leaked token or over-privileged service account has already been used in a live environment.
How It Works in Practice
The practical model is to shift identity enforcement as far left as possible while keeping it automated. That means checking who or what is requesting access, what scope is being requested, how long it should live, and whether the pipeline stage actually needs it. For most environments, the strongest pattern is short-lived access issued just in time, tied to workload identity rather than a static shared credential.
In CI/CD, that usually includes four controls:
- Pre-merge checks for hardcoded secrets, mis-scoped configuration, and unsafe permission changes.
- Build-time validation that service accounts, federated roles, and token scopes match approved policy.
- Pre-deploy gates that verify the pipeline is using ephemeral credentials, not long-lived keys.
- Post-deploy verification that deployed workloads received only the access they need, with rotation and revocation still enabled.
This is where identity and secrets management converge. The more teams rely on shared deployment credentials, the harder it becomes to prove provenance and contain blast radius. The NHIMG Cisco DevHub NHI breach and the CI/CD pipeline exploitation case study both illustrate the same operational problem: once an attacker reaches the pipeline identity layer, they can often pivot into source control, artifact stores, or downstream cloud accounts.
Current best practice is evolving toward policy-as-code, workload identity federation, and automatic secret rotation. That aligns well with NIST CSF 2.0, but implementation details vary by platform. These controls tend to break down when legacy pipelines depend on long-lived static credentials baked into scripts, shared runners, or manual release steps.
Common Variations and Edge Cases
Tighter identity controls often increase pipeline complexity and maintenance overhead, so organisations must balance release speed against blast-radius reduction. The tradeoff is especially visible in multi-cloud and hybrid builds, where a single deployment may need different identity providers, token lifetimes, and approval logic.
There is no universal standard for this yet, but guidance consistently points toward three patterns: use ephemeral credentials wherever possible, separate human approval from machine authorization, and treat secrets as deploy-time dependencies rather than static configuration. The Ultimate Guide to NHIs is useful here because it frames pipeline actors as non-human identities with their own lifecycle, not as an extension of human user accounts.
Edge cases arise when teams need emergency break-glass access, third-party deployment tooling, or blue-green releases that span multiple trust zones. In those cases, best practice is to log every credential issuance, constrain duration aggressively, and require explicit revocation after the job completes. The operational goal is not zero friction, but predictable identity behaviour under automation. Security controls usually fail when organisations keep one-off exceptions alive after the original pipeline need has passed.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and lifecycle control in pipelines. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be enforced for pipeline identities. |
| CSA MAESTRO | IAM | Agent and workload identities need runtime authorization in automated delivery. |
Use ephemeral pipeline credentials and automate rotation and revocation on every release path.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams implement identity visibility before tightening access controls?
- How should security teams reduce risk in software delivery pipelines with NHI controls?
- How should security teams limit ransomware spread through identity controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
