TL;DR: Traditional PAM built for static human administration is being stretched by CI/CD, Kubernetes, Ansible, and service accounts that need privileged access only for the task at hand, according to SSH Communications Security. The governance problem is that standing credentials and permanent permissions turn automated delivery into a persistent blast-radius problem, not a simple speed trade-off.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on SSH Communications Security's blog post: Privileged access in DevOps is moving from standing credentials to ephemeral, task-scoped access for pipelines, Kubernetes, Ansible, and service accounts.
Why it matters: IAM, PAM, and NHI teams need to treat DevOps privilege as a lifecycle problem because persistent credentials create unnecessary exposure without matching how automation actually operates.
Context
DevOps privileged access now spans human operators, pipelines, service accounts, Kubernetes workloads, and infrastructure automation. The governance problem is no longer just who gets elevated access, but how to issue it safely when the identity is non-human and the task window is short.
Traditional PAM assumptions break when privileged activity is embedded directly into CI/CD, Ansible, and cloud operations. Static credentials, long-lived API tokens, and permanent permissions create persistent exposure that clashes with the speed and repeatability DevOps teams depend on.
Key questions
Q: What breaks when developers share privileged credentials across DevOps teams?
A: When developers share privileged credentials, identity attribution breaks down and teams lose visibility into who performed which action and under what rights. That makes auditing unreliable, weakens separation of duties, and increases the chance that third parties or unintended users gain access to sensitive repositories, production systems, or automated connections.
Q: Why do long-lived secrets create risk in GitOps and CI/CD pipelines?
A: Long-lived secrets increase risk because they persist beyond the job that needs them, so exposure can turn into repeated misuse. In GitOps and CI/CD, static credentials also make rotation harder and widen the blast radius if a repository, runner, or cluster component is compromised. Short-lived credentials and runtime retrieval reduce that exposure and better align access with the actual deployment window.
Q: How do security teams know if just-in-time access is actually working?
A: Look for short-lived sessions, automatic revocation, and complete request-to-access logs. If approvals are still creating durable permissions, or if teardown depends on manual cleanup, then the programme is only partially ephemeral. Effective JIT should leave little or no reusable privilege behind after the task ends.
Q: Should organisations manage service accounts and application accounts like admin users?
A: Yes, because those accounts can carry the same or greater operational power than human admins. They need inventory, ownership, rotation, monitoring, and offboarding controls, otherwise they become hidden standing privilege paths that survive long after the business need ends.
Technical breakdown
Why standing credentials fail in DevOps automation
Standing credentials assume privileged work is occasional, manually triggered, and easy to review after the fact. In modern DevOps, a pipeline, service account, or automation tool may need privilege only for a single deployment or configuration change, then should lose it immediately. When that access is embedded as a static secret, the control plane and the attack surface become the same thing. The result is a broader blast radius, harder auditing, and a governance model that cannot distinguish between routine automation and abuse.
Practical implication: replace persistent privileged credentials with task-scoped issuance and revocation for automation workflows.
Just-in-time access for service accounts and pipelines
Just-in-time access means privilege is created only when a task is authorised and removed once the task completes. For CI/CD and infrastructure automation, that usually means dynamic credentials, certificate-based authentication, or policy-driven session grants instead of embedded keys. This matters because the identity performing the work is often not a person, so the access decision must be bound to workload context, target scope, and time. The technical shift is from secret storage to secret issuance and governance.
Practical implication: issue ephemeral credentials through policy rather than storing reusable secrets in pipelines or automation tooling.
Kubernetes and Ansible need session-level governance
Kubernetes cluster-admin rights and automation platforms such as Ansible can create broad privileges across production systems, but the real risk is not the tool itself. It is the persistence of authority beyond the task boundary. Recording privileged sessions, constraining kubectl use to approved actions, and managing machine identities centrally all reduce ambiguity about what happened and who, or what, was authorised to do it. In practice, this is how zero standing privilege becomes operational rather than aspirational.
Practical implication: bind elevated Kubernetes and infrastructure actions to recorded, short-lived sessions with central policy control.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Standing privilege is the wrong unit of control for DevOps automation. The article shows that pipelines, service accounts, and orchestration tools now perform privileged work as part of normal delivery. That breaks the assumption that privilege can remain resident without changing the risk model. The practitioner conclusion is that access governance must move from durable entitlement to task-bounded issuance.
Ephemeral privileged access is a governance pattern, not just a credential format. Short-lived certificates, dynamic authorization, and session recording all matter because they align privilege with execution window. This is not about making DevOps slower. It is about making elevated access observable and revocable at the point where automation actually acts.
Zero standing privilege becomes the practical control objective once automation scales. The article makes clear that embedded secrets and permanent permissions turn automation into persistent exposure. Organisations that keep treating machine-driven privilege like human admin access will continue to over-extend PAM into patterns it was never designed to absorb. The conclusion is that identity lifecycle for non-human access now sits at the centre of DevOps security.
Machine identities are now part of privileged governance, not a side case. Applications, pipelines, and service accounts are increasingly the actors doing the work, which means PAM and IGA programmes need to govern non-human privilege directly. That shifts the discipline from user-centric administration to machine-centric control over issuance, scope, and revocation.
Privilege recording and central policy are the audit layer DevOps needs. When elevated work is performed by automation, organisations need evidence at the session and policy level, not just at the account level. The practitioner takeaway is to treat recorded machine activity as a core governance signal, especially where production change is continuous.
From our research library:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Just-in-Time Access and Zero Standing Privilege Guide
What this signals
Ephemeral privilege is becoming the control boundary for DevOps. When pipelines and automation tools are the actors performing elevated work, the old account-centric PAM model becomes too blunt to govern risk effectively. Security teams should expect privilege issuance, not just password rotation, to become the key control point across CI/CD and infrastructure automation.
Standing access is a governance debt, not an engineering convenience. The longer a secret, token, or permission persists, the more it behaves like an exposed control surface rather than a bounded operational asset. Programmes that still depend on reusable credentials will need to shift toward lifecycle-based controls for machine identities if they want durable auditability.
For practitioners
- Issue ephemeral credentials for CI/CD Remove long-lived secrets from deployment workflows and replace them with dynamic credentials that expire when the deployment completes.
- Convert Kubernetes admin rights to task-scoped access Grant kubectl permissions only for specific maintenance or deployment tasks and record the privileged session for later review.
- Replace static Ansible secrets with short-lived certificates Stop storing reusable SSH keys or API tokens for automation and use ephemeral certificates or vault-issued credentials instead.
- Govern service accounts as privileged identities Inventory pipeline and workload identities, define their permitted actions, and revoke access as soon as the task or workflow ends.
Key takeaways
- DevOps privilege is shifting from static human administration to ephemeral access for pipelines, service accounts, and automation tools.
- Persistent credentials and permanent permissions create avoidable exposure because they outlive the task that needed them.
- Task-scoped issuance, session recording, and central policy control are the practical controls that align PAM with automated delivery.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and 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-05 — Overprivileged NHI | The article centres on excessive standing privilege across pipelines, service accounts, and automation tools. |
| NHI-07 — Long-Lived Secrets | Static SSH keys, tokens, and embedded secrets are the core exposure discussed in the article. | |
| Recommendation — Reduce standing privilege for pipelines and service accounts by issuing only task-scoped access. Replace reusable secrets with short-lived credentials and remove persistent secret storage from automation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is central when ephemeral access replaces standing credentials. |
| Recommendation — Apply authenticator lifecycle controls to rotate, expire, and revoke machine credentials promptly. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Persistent automation secrets expand credential abuse and lateral movement opportunities. |
| Recommendation — Map exposed automation secrets to credential access and lateral movement risk in detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing entitlements for non-human privileged activity. |
| Recommendation — Govern access permissions so machine identities receive only the entitlements needed for the task. | ||
Key terms
- Ephemeral Privilege: Ephemeral privilege is access that exists only for a short task or runtime window, then should disappear. In cloud and container environments, the challenge is not granting it, but proving it was created, used, and removed within the intended boundary before it becomes a lingering exposure.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org