Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Least privilege is widely understood but hard to operationalise because access accumulates through role changes, exceptions, shared credentials and machine workflows, according to SSH Communications Security. The real control problem is not policy intent but eliminating standing privilege so access expires by default, not by review cycle.
NHIMG editorial — based on content published by SSH Communications Security: least privilege and PAM as an enforceable access model
Questions worth separating out
Q: How should security teams reduce standing privilege in cloud production environments?
A: Security teams should treat standing privilege as an exception and move high-risk access to just-in-time workflows with automatic expiry, contextual approval, and revocation.
Q: Why does least privilege fail in fast-changing cloud and DevOps environments?
A: Because manual access reviews and durable roles cannot keep up with changing infrastructure, temporary exceptions, and frequent role changes.
Q: What do organisations get wrong about privileged access reviews?
A: They often review named accounts instead of the actual access path that creates privilege.
Practitioner guidance
- Inventory standing privilege paths Identify permanent admin accounts, shared passwords, static SSH keys, and broad access groups across human and machine identities.
- Convert high-risk access to JIT workflows Require a task-specific request, a bounded approval or policy check, and automatic revocation when the session ends.
- Replace reusable secrets with ephemeral credentials Use short-lived certificates or tokens for workloads, scripts, and service accounts so no persistent credential remains available for reuse.
What's in the full article
SSH Communications Security's full article covers the operational detail this post intentionally leaves for the source:
- A deeper walkthrough of how PAM maps least privilege to human, machine, and service identities in practice.
- Specific examples of how JIT access, JEA, and ephemeral credentials work across different administrative scenarios.
- The vendor's explanation of how session monitoring and auditing support governance and investigation.
- Implementation-oriented guidance on moving from static credentials to temporary access without breaking workflows.
👉 Read SSH Communications Security's analysis of least privilege and PAM →
Least privilege and standing privilege: what IAM teams need to fix?
Explore further
25/08/2026 6:11 pm
Standing privilege is the governance failure that most least-privilege programmes still tolerate. The article shows that access reviews and role assignments are usually treating symptoms after privilege has already accumulated. Once temporary access, contractor access, and admin exceptions become normal, the programme is no longer enforcing least privilege, it is documenting privilege creep. The practical conclusion is that standing access must be treated as a design defect, not a review finding.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: When should teams prioritise zero standing privilege over broader access convenience?
A: Prioritise zero standing privilege whenever access supports production systems, external collaboration, or time-sensitive cloud operations. Those are the environments where persistent elevation is hardest to justify and easiest to abuse. If a workflow can be completed with temporary elevation, permanent privilege is usually a governance liability, not an efficiency gain.
👉 Read our full editorial: Least privilege fails when standing access becomes permanent
