Notifications
Clear all
Topic starter
14/09/2026 10:09 am
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.
NHIMG editorial — based on content published by SSH Communications Security: ephemeral privileged access for DevOps and infrastructure automation
Questions worth separating out
Q: How should security teams remove standing privilege from CI/CD and automation workflows?
A: Start by replacing embedded secrets, static SSH keys, and permanent role grants with task-scoped access that expires after the job completes.
Q: Why do long-lived Kubernetes credentials increase security risk?
A: Long-lived credentials extend the window in which stolen or over-scoped access can be reused across cluster resources.
Q: What are the signs that privileged automation is still relying on unsafe access patterns?
A: Look for reusable pipeline tokens, permanent cluster-admin roles, service accounts with broad scope, and automation systems that can act without a fresh authorization event.
Practitioner guidance
- Replace standing pipeline credentials Issue deployment permissions dynamically for CI/CD jobs and remove embedded SSH keys, static API tokens, and permanent role grants from build workflows.
- Grant ephemeral Kubernetes privileges Limit kubectl and cluster-admin access to task-scoped sessions, and tie elevation to the specific operational action rather than the operator’s default role.
- Move automation onto short-lived certificates Use certificate-based authentication for Ansible, service accounts, and machine-to-machine workflows so compromised secrets expire before they can be reused at scale.
What's in the full article
SSH Communications Security's full article covers the operational detail this post intentionally leaves for the source:
- How PrivX PAM applies ephemeral access across GitLab, Kubernetes, Ansible, CI/CD, and hybrid cloud workflows
- How short-lived certificates and vault-free workflows change the mechanics of privileged automation
- How centralized auditing and session recording work for machine-driven privileged activity
- How to integrate privileged access policy into infrastructure-as-code and DevOps delivery flows
👉 Read SSH Communications Security's analysis of ephemeral privileged access for DevOps →
Ephemeral privileged access for DevOps: are your controls keeping up?
Explore further
14/09/2026 10:10 am
Standing privilege is the wrong default for DevOps-era machine access. Traditional PAM was built around human administrators and relatively static systems. That assumption fails when pipelines, service accounts, and orchestration tools are the actors actually performing privileged work. The result is not just broader exposure, but a governance model that cannot see privilege as a task-bound event. Practitioners should treat persistent access as the exception, not the operating model.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
A question worth separating out:
Q: What is the difference between IAM and PAM for machine identities?
A: IAM establishes who or what can authenticate and what baseline access it should have. PAM controls elevated access, especially when a service account or workload can reach production, infrastructure, or sensitive data paths. For machine identities, the two must work together because a credential can be legitimate and still be dangerously over-privileged.
👉 Read our full editorial: Ephemeral privileged access is replacing standing access in DevOps
