Notifications
Clear all
Topic starter
21/08/2026 4:49 pm
TL;DR: SMBs still concentrate critical access in a few accounts and tools, while shared secrets, standing admin rights, and limited session visibility keep audit friction and breach risk high, according to Devolutions. The operational lesson is that PAM is no longer a specialist add-on; it is the control layer that makes privileged work governable.
NHIMG editorial — based on content published by Devolutions: Why essential SMB cybersecurity preparation must include PAM
By the numbers:
- More than 1.8 billion credentials were exposed in the first half of 2025, an eight-fold increase over prior periods driven largely by stealer malware campaigns.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, making poorly scoped access 4.5 times riskier.
Questions worth separating out
Q: How should SMBs reduce risk from standing privileged access?
A: Start by removing persistent admin rights from the accounts that can change core systems.
Q: Why do shared passwords and copied keys create such a large risk in smaller environments?
A: Because they turn one compromise into many.
Q: What is the difference between password storage and PAM?
A: Password storage protects the secret itself.
Practitioner guidance
- Centralise every privileged secret Move administrator passwords, SSH keys, API tokens, and database credentials into a vault so they are encrypted, brokered by policy, and rotated automatically.
- Eliminate standing admin rights Convert persistent administrator access into just-in-time elevation with approval, time limits, and automatic revocation when the task ends.
- Record all privileged sessions Require session recording and command logging for every connection that can reach domain controllers, cloud consoles, or payment systems.
What's in the full article
Devolutions' full white paper covers the operational detail this post intentionally leaves for the source:
- A practical SMB roadmap for prioritising PAM quick wins across passwords, elevation, and session control.
- Examples of how Devolutions maps privileged access into a single workflow across vaulting, brokered access, and rotation.
- Implementation patterns for handling vendors, break-glass access, and admin sessions in smaller teams.
- Platform-specific guidance on how the Devolutions stack operationalises these controls in day-to-day use.
👉 Read Devolutions' white paper on why SMB cybersecurity preparation must include PAM →
SMB privilege sprawl and PAM gaps: what IAM teams need now?
Explore further
21/08/2026 5:08 pm
Privilege is a workflow problem before it is a tool problem. SMBs often focus on where secrets are stored, but the deeper issue is that privileged work is still treated as a static entitlement. A vault helps only if it also changes how access is requested, approved, recorded, and retired. The practitioner takeaway is that governance has to follow the session, not just the credential.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Least-privileged AI access produced a 17% incident rate versus 76% for over-privileged systems, showing that scope control is still the decisive control variable.
A question worth separating out:
Q: Who should own service account governance in SMBs?
A: The business or system owner who depends on the automation should own it, not the infrastructure team alone. Service accounts need lifecycle rules, rotation, and an offboarding path just like human access. If nobody owns them, they become permanent privilege with no accountability.
👉 Read our full editorial: SMB privilege sprawl turns PAM into a baseline control
