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.
Editorial analysis by NHI Mgmt Group, based on content published by SSH Communications Security: “Stop Letting PAM Security Slow Down DevOps Productivity”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: DevOps privilege is shifting from static human administration to ephemeral access for pipelines, service accounts, and automation tools.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Ephemeral privileged access is replacing standing access in DevOps