Notifications
Clear all
Topic starter
12/06/2026 12:23 am
TL;DR: Privileged access management often stalls in SMBs because legacy tools assume on-premise environments, enterprise budgets, and specialist security teams, while modern work is cloud-first, remote, and collaborative, according to JumpCloud. The real test is whether PAM can reduce privileged risk without adding deployment friction or operational overhead.
NHIMG editorial — based on content published by JumpCloud: PAM barriers for SMBs and modern teams
Questions worth separating out
Q: How should security teams implement PAM in cloud-first environments?
A: They should start with the privileged paths that matter most, then design for cloud services, remote infrastructure, and SaaS access rather than on-premise only workflows.
Q: Why does PAM adoption stall in smaller organisations?
A: It usually stalls because the tooling assumes enterprise staffing, long onboarding, and dedicated security operators.
Q: What do teams get wrong about privileged access management?
A: They often treat PAM as a product purchase rather than a governance and operating-model change.
Practitioner guidance
- Prioritise the highest-risk privileged paths first. Start with administrator accounts, infrastructure control planes, and third-party access paths that would create the largest blast radius if abused.
- Replace standing privilege with task-scoped access. Use just-in-time access for recurring admin tasks so privilege exists only for the duration of the work, then revoke it automatically when the session ends.
- Build PAM around IT-security collaboration. Give IT admins a workable request and approval path, then preserve auditability so Security can review privileged activity without forcing every request through a specialist bottleneck.
What's in the full article
JumpCloud's full how-to covers the operational detail this post intentionally leaves for the source:
- Deployment and onboarding considerations for SMB-sized PAM rollouts across cloud and hybrid environments.
- Examples of how teams can start with their highest-risk privileged accounts before expanding coverage.
- Operational guidance on making PAM usable for IT administrators without removing security oversight.
- The source article's framing for cloud-native, device-aware privileged access workflows.
👉 Read JumpCloud's guidance on modern PAM for SMB and cloud-first teams →
PAM for SMB teams: what changes when access must fit modern work?
Explore further
12/06/2026 9:34 am
PAM fails most often when the operating model is wrong, not when the technology is absent. The article shows a familiar pattern: organisations recognise privileged risk, but the control is too expensive, too complex, or too enterprise-shaped to adopt broadly. That is a governance failure because the programme cannot spread into the environments where privilege is actually used. The implication is that PAM must be evaluated as an operational control surface, not a specialist product category.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
A question worth separating out:
Q: Who should own PAM in a shared IT and security model?
A: Ownership should be shared, but accountability must stay clear. IT needs enough access to run the environment, while Security needs the approval, monitoring, and review layer that keeps privilege auditable. The control fails when either team is excluded from the workflow.
👉 Read our full editorial: PAM for SMBs is shifting toward cloud-native, usable controls
