TL;DR: Passwords, SSH keys, API keys, and other static privileged credentials remain easy to reuse, share, and expose, which keeps escalation paths open even when rotation policies exist, according to SSH Communications Security. The real shift is away from maintaining secrets that should not persist at all, toward temporary, policy-driven access that removes standing privilege rather than preserving it.
NHIMG editorial — based on content published by SSH Communications Security: keyless privileged access and modern PAM
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams reduce standing privilege in privileged access workflows?
A: Security teams should move from reusable credentials to policy-based, short-lived sessions that expire when the task ends.
Q: Why do static SSH keys and passwords remain a risk even with rotation?
A: Rotation helps only if the credential is still tightly controlled and clearly owned.
Q: What breaks when privileged credentials are shared across multiple systems?
A: Shared privileged credentials break ownership, revocation, and accountability at the same time.
Practitioner guidance
- Inventory and classify standing privileged credentials Identify passwords, SSH keys, API keys, and certificates that grant elevated access across cloud, production, CI/CD, and automation environments.
- Replace reusable secrets with short-lived access paths Move privileged workflows to policy-based, time-bound sessions that grant access only for the target, duration, and identity context required.
- Tie revocation to lifecycle events, not incident response Build offboarding and role-change triggers that remove privileged access when the task ends, not after a compromise is detected.
What's in the full article
SSH Communications Security's full post covers the operational detail this post intentionally leaves for the source:
- How PrivX handles policy-based access sessions across cloud and production targets
- Why the article argues for reducing privileged credentials instead of relying on rotation alone
- The practical differences between passwordless and keyless privileged access
- How session monitoring and recording fit into a modern PAM workflow
👉 Read SSH Communications Security's perspective on keyless privileged access and modern PAM →
Keyless privileged access: what it changes for IAM teams?
Explore further
Persistent privileged credentials are a governance debt, not a protection layer. Passwords and static SSH keys were built for a world where access changed slowly and ownership was easier to trace. That assumption no longer holds in cloud, container, and automation-heavy environments, where access is often temporary and distributed across many systems. The result is not just risk, but accumulated governance debt that shows up as forgotten keys, shared secrets, and unclear accountability.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: How should teams decide when to retire long-lived privileged access?
A: Teams should retire long-lived privileged access when the task can be completed through ephemeral sessions, scoped authorisation, and session logging instead. If the access is only needed briefly, keeping a permanent credential alive adds risk without adding value. The decision should be driven by task duration, ownership clarity, and revocation speed.
👉 Read our full editorial: Keyless privileged access is becoming the safer PAM model