By NHI Mgmt Group Editorial TeamPublished 2026-06-23Domain: AnnouncementsSource: SSH Communications Security

TL;DR: Manual service account management is creating unnecessary sprawl, governance gaps, and operational risk as CI/CD, Kubernetes, and automation workloads scale, according to SSH Communications Security. The meaningful change is not just faster provisioning, but a move away from standing machine identities toward ephemeral, scoped access that better fits modern infrastructure.


At a glance

What this is: SSH Communications Security argues that machine identity management is moving away from manually maintained service accounts toward ephemeral, federated, and scoped access for automation workloads.

Why it matters: That matters because IAM, PAM, and NHI teams must govern non-human access at infrastructure speed without letting privilege sprawl, audit gaps, or delegated access boundaries drift out of control.

👉 Read SSH Communications Security's release on PrivX PAM updates for machine identity management


Context

Machine identity management is the discipline of governing access for workloads, scripts, APIs, and automation systems rather than people. The problem in this release is that many organisations still assign those identities like human accounts, even though CI/CD, Kubernetes, and other automation now create and retire access at machine speed.

That model creates avoidable NHI sprawl because standing accounts are hard to inventory, hard to audit, and easy to over-provision. The practical question for IAM and PAM teams is whether privileged access controls can keep pace with ephemeral workloads, federated identities, and delegated administration without losing governance.


Key questions

Q: How should teams reduce service account sprawl in automation-heavy environments?

A: Start by identifying workloads that do not need permanent identities. Replace standing service accounts with ephemeral or federated access wherever the workflow is short-lived, then tie each identity to a clear approval path, audit record, and retirement trigger. The goal is to make machine access temporary by design, not permanent by convenience.

Q: Why do federated identities complicate privileged access governance?

A: Federated identities shift trust to the external identity provider and the downstream approval workflow, which means governance depends on both. If role assignment, logging, or retention is inconsistent across those layers, auditors lose the ability to reconstruct who had access, when, and under what approval. Strong federation requires end-to-end evidence, not just successful authentication.

Q: What breaks when delegated role management is not tightly scoped?

A: Delegated administration can turn into privilege creep if teams are allowed to create roles outside a clearly bounded environment. The failure is not delegation itself, but the lack of enforceable scope. If local admins can expand into broader domains, central governance loses control of who can grant what access and to whom.

Q: How do security teams know if machine identity governance is working?

A: Look for fewer standing accounts, faster onboarding of automation workflows, auditable role approvals, and visible retention of access records after logout. If teams still depend on manual tracking to explain machine access, governance is only partially effective. Working machine identity governance should reduce both operational overhead and review friction.


How it works in practice

Why manually managed service accounts create NHI sprawl

Service accounts, API clients, and automation scripts often need access that is both frequent and short-lived, but manually created accounts make that access persistent by default. Each account becomes another object to provision, review, rotate, and retire, which is why machine identity estates expand faster than governance teams can track them. The core failure is not just scale, but the mismatch between human-paced account lifecycle processes and machine-paced execution. Ephemeral identity patterns reduce that mismatch by creating access only when a trusted token is present and removing it when the task ends.

Practical implication: inventory where standing machine accounts still exist and replace them with short-lived identity patterns where the workload model allows it.

How federated access changes privileged workflow control

Federated access lets a workload or user authenticate through an external identity provider rather than maintain a local account everywhere it touches. In this release, OIDC-authenticated users can request role approvals directly, while API proxy credentials and authorized SSH keys extend privileged workflows to federated identities. Technically, that moves the trust decision upstream to the identity provider and downstream to the role broker, which simplifies administration but also raises the importance of consistent approval logic, logging, and session traceability. Federation is not a control shortcut; it is a control relocation.

Practical implication: align role approval, logging, and retention settings before expanding federated access into privileged operations.

Why delegated role management needs strict scope boundaries

Delegated administration works only when the scope of authority is explicit. Allowing teams to create and manage roles within assigned groups reduces central bottlenecks, but it also increases the risk of privilege drift if boundaries are not enforced at the group, project, or environment level. The architecture here is a scoped control plane, not open-ended delegation. That distinction matters because governance failures usually start when local flexibility quietly turns into broad administrative reach. Strong scope enforcement keeps delegated access useful without turning it into shadow privilege.

Practical implication: define the smallest administrative scope that supports operations and verify that role creation cannot escape that boundary.


NHI Mgmt Group analysis

Ephemeral machine identity is becoming the default control model for automation-heavy environments. Manual account creation no longer scales once CI/CD, Kubernetes, and scripted workflows begin operating continuously. The important shift is not simply reducing overhead, but replacing standing identity with time-bound access that matches machine execution patterns. Practitioners should treat this as a governance redesign, not a tooling convenience.

Service account burden is a named governance failure, not just an operational nuisance. The old assumption was that access could be provisioned, reviewed, and retired on a human lifecycle cadence. That assumption breaks when GitLab runners, API clients, and cloud workloads need identity on demand and then disappear. The implication is that identity programmes must stop treating machine access as a human-account variant.

Federated privileged access is changing where control lives in the identity stack. When OIDC identity, role approval, and session retention become part of the privileged workflow, the control point moves from local account management to upstream assertion trust and downstream approval governance. That does not eliminate PAM concerns; it shifts them into federation quality, auditability, and role scope discipline. Practitioners should reassess where assurance is actually created.

Delegated role management only works when scope boundaries are enforceable and visible. Local autonomy for business units can reduce central bottlenecks, but it also increases the chance of privilege creep if role creation is not constrained to a bounded domain. The result is a more distributed governance model, not a looser one. Teams should measure delegation by how tightly scope is preserved, not by how much admin work disappears.

Ephemeral access and federated identity together point to a broader NHI operating model shift. Modern infrastructure is forcing organisations to govern access by task, context, and duration rather than by long-lived account ownership. That aligns with OWASP-NHI and NIST CSF thinking, where identity lifecycle, least privilege, and traceability must be enforced continuously. The practical conclusion is that machine identity governance now sits at the centre of PAM and NHI strategy.

From our research:

What this signals

With 57% of organisations lacking a complete inventory of machine identities, the immediate programme risk is not abstract exposure but unknown ownership and incomplete review coverage, which makes access governance harder to prove and harder to sustain. The practical response is to treat inventory quality as a control dependency, not a reporting metric.

Identity sprawl debt: standing machine accounts accumulate faster than teams can rationalise them, so the governance problem becomes cumulative rather than episodic. That means PAM and IAM programmes should measure how much access can be eliminated through ephemeral patterns before they add another layer of control.

For practitioners, the next step is to align machine identity lifecycle work with Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0, especially where identity inventory, access review, and continuous control validation intersect.


For practitioners

  • Replace long-lived service accounts where tasks are short-lived Map GitLab runners, API clients, and automation scripts to workflows that can use ephemeral user creation, external identity assertions, or other short-duration access patterns instead of standing accounts.
  • Review federated approval paths before expanding privileged use Check whether OIDC-authenticated identities, API proxy credentials, and authorized SSH keys all land in the same approval, logging, and retention model so auditors can follow the full access path.
  • Constrain delegated role administration to explicit scopes Limit local role creation to defined groups or environments, and test that delegated administrators cannot expand privileges beyond the scope assigned to them.
  • Tune retention and evidence capture for reviewability Keep user records long enough after logout to support audit review, and ensure session and role activity can be reconstructed without relying on manually maintained spreadsheets.

Key takeaways

  • Machine identity governance fails when organisations manage automation with human account patterns, because standing access does not match how workloads actually operate.
  • The strongest evidence in this release is the move toward ephemeral, federated, and scoped access, which reduces sprawl while preserving privileged control.
  • Practitioners should treat service account replacement, approval traceability, and delegated scope enforcement as one governance problem rather than three separate projects.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Ephemeral identity and rotation reduce standing machine account risk.
NIST CSF 2.0PR.AC-4Scoped delegated role management depends on least-privilege access enforcement.
NIST Zero Trust (SP 800-207)PR.AC-1Federated identity and approval workflows align with continuous verification principles.

Replace persistent machine accounts with time-bound identities and verify retirement occurs after each task.


Key terms

  • Machine Identity: A machine identity is any credentialed digital identity used by a workload, script, API client, or automation tool rather than a person. It includes service accounts and other non-human access objects that need authentication, authorization, and lifecycle control to avoid persistent privilege and audit blind spots.
  • Ephemeral Identity: An ephemeral identity exists only for the duration of a task or session, then disappears once the work is complete. In machine identity governance, this reduces standing access and makes privilege more closely match actual execution time, which is especially important for automation that runs continuously.
  • Federated Access: Federated access lets an identity authenticate through an external provider and use that assertion to obtain downstream access. For privileged workflows, this shifts trust to the assertion source and the approval path, so auditability depends on how consistently those layers are logged, retained, and governed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SSH Communications Security: PrivX PAM updates for machine identity and privileged access management. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-06-23.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org