SMB privilege sprawl turns PAM into a baseline control

At a glance

What this is: This white paper argues that SMBs should treat privileged access management as a baseline identity control because shared secrets, standing admin rights, and poor session visibility create outsized operational and security risk.

Why it matters: It matters because IAM, PAM, and security teams in smaller environments often inherit the same identity attack paths as large enterprises, but with fewer controls, less staffing, and faster attacker payoffs.

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.

👉 Read Devolutions' white paper on why SMB cybersecurity preparation must include PAM

Context

Privileged access is the control point that decides who can change core systems, retrieve secrets, and reach the data that matters most. In SMB environments, that often means a very small set of administrators, service accounts, and vendor connections carrying a disproportionate share of business risk, especially when privileged access management is informal or spread across tools.

The problem is not only exposure, but governance debt. When secrets live in spreadsheets, scripts, and personal tools, and when admin rights stay permanently active, the organisation loses the ability to answer basic questions about who had access, when they used it, and whether that access was still justified.

For SMBs, this is not a scaled-down enterprise issue. It is the same identity pattern with fewer compensating controls, which makes privileged access the most important place to tighten IAM discipline before attackers or auditors do it for you.

Key questions

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. Put elevation behind approval, short time windows, and recorded sessions so access exists only for the task. Then pair that with secret rotation and offboarding so the credential does not outlive the need for it.

Q: Why do shared passwords and copied keys create such a large risk in smaller environments?

A: Because they turn one compromise into many. When credentials are duplicated across spreadsheets, tickets, scripts, and personal tools, no one can reliably prove where they are used or revoke them cleanly. That makes misuse, leakage, and delayed response far more likely than in a tightly governed model.

Q: What is the difference between password storage and PAM?

A: Password storage protects the secret itself. PAM governs the use of privilege around that secret by brokering access, enforcing approvals, recording sessions, and rotating credentials. In practice, the difference is between hiding a password and controlling every privileged action that depends on it.

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.

Technical breakdown

Why shared secrets and standing admin rights fail in SMBs

Shared passwords, copied SSH keys, and reused API tokens create a hidden web of privilege that is hard to audit and easy to abuse. Standing admin rights make the problem worse because compromise of one endpoint or one session can expose a broad set of systems. The issue is not just weak credentials. It is that the identity model becomes static while the work is dynamic, so access outlives the task that needed it.

Practical implication: remove persistent privileged access first, then centralise secrets so every elevated action is time-bound and traceable.

How session visibility changes the audit and incident response picture

When privileged work happens from a laptop with locally stored credentials, the organisation loses context. Without session recording, command logging, and correlation to ticketing or change records, incident responders cannot reconstruct what happened, and auditors cannot validate control operation. This is where PAM differs from simple password storage. PAM turns privileged activity into an observable workflow rather than an opaque login event.

Practical implication: require recorded sessions and immutable logs for every privileged pathway that can touch critical systems or data.

Why service accounts and vendor access need identity governance

Service accounts, automation jobs, and third-party connections are non-human identities, but they are often governed more loosely than human admins. In practice, they accumulate permanent permissions, stale keys, and uncertain ownership. That creates lifecycle risk: no clear owner, no clean offboarding, and no reliable rotation cadence. The result is a privilege surface that is easy for attackers to exploit because it rarely triggers human authentication workflows.

Practical implication: assign owners, expiry, rotation, and offboarding rules to every service account and third-party credential.

Threat narrative

Attacker objective: The attacker wants fast access to the systems that control operations, data theft, and extortion leverage.

1. Entry begins when attackers obtain compromised credentials, often through stolen passwords, exposed secrets, or third-party account abuse.
2. Escalation occurs when standing privileges or broad vendor access let the attacker reach high-value systems without needing additional approval.
3. Impact follows when the attacker disables defenses, exfiltrates data, or pivots to the systems that control operations and recovery.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing privilege creates identity blast radius that SMBs can least afford. When an endpoint is phished or a token leaks, always-on admin rights convert a single compromise into a multi-system event. That is why least privilege is not an abstract control here, but a containment boundary. The operational conclusion is that any account able to reach core infrastructure should be time-bound by default.

Shared secrets are a lifecycle failure, not just a hygiene issue. When passwords, keys, and tokens are copied into scripts, tickets, and spreadsheets, ownership and offboarding disappear. That pattern directly matches the identity failure mode this paper describes: access persists after the person, vendor, or automation no longer needs it. The practitioner conclusion is that lifecycle control must include non-human identities, not only employees.

Non-human identity governance is now part of SMB PAM maturity. Batch jobs, monitoring agents, and integrations are operationally essential, but they become long-lived attack paths when keys are permanent and unowned. This is where the category is moving: PAM is no longer just about admins at the keyboard, but about every privileged actor that can change state in production. The practitioner conclusion is to govern service accounts with the same rigor as human privileged users.

Named concept: privileged access drag. In SMBs, too many disconnected tools, approvals, and credential stores slow legitimate work while still failing to constrain abuse. That drag matters because security teams often preserve convenience at the expense of control, then discover during an incident that they cannot prove who did what. The practitioner conclusion is that reduced friction must come from a single governed flow, not from fewer controls.

From our research:

• 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.
• For a broader identity lens, the NHI Lifecycle Management Guide shows how ownership, rotation, and offboarding change when privileges are not human.

What this signals

Privileged access is converging with non-human identity governance. SMBs that still separate admin access, service accounts, and automation into different control conversations are building blind spots into the programme. As more infrastructure work is done by systems rather than people, the next maturity step is to govern all privileged actors through one lifecycle model, not three disconnected ones.

Privileged access drag: the more tools and handoffs a team adds, the harder it becomes to prove control and the easier it becomes to miss abuse. That is why the operational target is not just stronger authentication, but a simpler privileged workflow that can be audited end to end. Teams should expect boards, insurers, and customers to ask for proof of containment, not just policy language.

A useful benchmark is the 2026 Infrastructure Identity Survey, where only 44% of organisations had policies for AI agents even though 92% said governance was critical. The same gap appears in SMB PAM programmes when the organisation can describe the risk but cannot yet operationalise the control.

For practitioners

• 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.
• Treat service accounts as governed identities Assign each automation, connector, and integration an owner, an expiry date, rotation rules, and an offboarding path when the service changes.
• Broker vendor access through the same control plane Replace shared remote access and broad VPN permissions with scoped, time-bound access that is approved, recorded, and revoked automatically.

Key takeaways

• SMB privilege risk concentrates around a small number of identities, secrets, and tools, which makes unmanaged elevation an outsized attack path.
• The strongest control shift is from static privilege to governed workflows with vaulting, recording, rotation, and time-bound access.
• Service accounts and vendor access must be treated as lifecycle-governed identities, or they become permanent exposure points.

Key terms

• PAM — Privileged Access Management: Solutions that control, monitor, and audit privileged access for both human and non-human identities. Traditional PAM tools are being extended to cover machine identities, service accounts, and agentic AI workloads.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Session Recording: Session recording is the capture of user activity during a privileged session, such as commands, queries, or administrative actions. It gives security and audit teams a verifiable record of what happened after authentication, which is essential when access itself is not enough to prove control.

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.

👉 The full Devolutions white paper covers the SMB roadmap, implementation patterns, and operational examples.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.