SASE for SMBs shifts remote access from appliances to policy

At a glance

What this is: This article frames SASE for SMBs as a way to replace fragile perimeter hardware with cloud-delivered policy enforcement for remote access, web filtering, and firewall control.

Why it matters: It matters because IAM and network teams have to treat remote access as an identity and device policy problem, not as a VPN box to patch after exposure appears.

By the numbers:

• 31% of breaches started with exploitation, overtaking stolen credentials for the first time in Verizon's 2026 Data Breach Investigations Report.
• 58% of the ransomware claims it saw in 2024 started with attackers compromising a perimeter security appliance, according to Coalition's Cyber Threat Index 2025 cited by Todyl.

Context

SMB remote access often still depends on a firewall at the office edge and a VPN for everyone outside it, which leaves security tied to appliances that are easy to forget, hard to patch, and overly broad in what they allow. Remote access identity should be governed as a policy problem rather than a hardware maintenance problem.

SASE changes the control plane by moving enforcement into the cloud so the same access and web policy follows the user and device wherever they connect. For MSPs and small internal teams, that shifts the work from perimeter upkeep to access design, logging, and exceptions management.

The article is typical of the market shift now under way: perimeter-centric remote access still dominates small environments, but it is increasingly out of step with how attackers enter and how staff actually work.

Key questions

Q: What breaks when small businesses keep using VPNs as their main remote access control?

A: The failure mode is broad network admission. A VPN often turns one valid login into access to the whole subnet, so a phished account or compromised appliance can expose far more than the user needs. That creates lateral movement opportunity, slower containment, and a much larger blast radius when a flaw or stolen credential is abused.

Q: Why do perimeter appliances increase ransomware risk in SMB environments?

A: They combine public exposure with high trust. Attackers only need to compromise one internet-facing box or one set of credentials to reach internal systems, and small teams often patch more slowly than the exploit window lasts. That makes the appliance both an entry point and a multiplier for downstream impact.

Q: How should security teams decide between ZTNA and VPNs for remote access?

A: Security teams should choose ZTNA when they need resource specific access, strong least privilege enforcement, and better cloud alignment. VPNs still fit smaller environments with modest remote access needs, but they create broader network exposure once a user is authenticated. The practical decision is to match the access model to the risk profile, application mix, and scale of remote users.

Q: What should MSPs prove before retiring a client VPN?

A: They should prove that every required application has been mapped, that each user group has a replacement access rule, and that the VPN listener is fully gone after cutover. The test is not whether users complain less, but whether there is no longer a public entry point that broadens internal trust.

Technical breakdown

Why perimeter appliances stay exposed

A perimeter appliance creates a public attack surface by design. VPN concentrators and firewalls accept inbound traffic from the internet, which makes them attractive targets for vulnerability exploitation, credential abuse, and session hijacking. In an SMB, the problem is not only the software risk but also the operational lag: patching, upgrade windows, and exception handling all compete with day-to-day support. When the appliance is the trust boundary, every weakness on that box becomes a potential entry path into the internal network. That is why the control model fails even when the device is nominally hardened. Read Top 10 Network Security Misconfigurations.

Practical implication: Treat internet-facing remote access appliances as a shrinking transition state, not as the long-term control model.

How SASE and ZTNA change the enforcement point

SASE moves policy enforcement into a cloud service, while ZTNA changes the access model from network-level admission to application-level authorisation. Instead of giving a remote user a broad subnet path after a successful login, the system evaluates identity, device posture, and context before allowing a specific application. That means the control lives with the user session rather than the office perimeter. The important architectural distinction is that the network no longer becomes the object of trust. Access is granted per request, per application, and per posture signal, which reduces the blast radius of a valid login. See the Conditional Access Guide.

Practical implication: Define access at the application level and tie it to identity and device context rather than to network location.

Why policy has to replace subnet logic

Traditional firewalls and VPNs are often written around IP ranges, static sites, and implicit internal trust. SASE requires a different model: user groups, device compliance, and application intent. That matters because SMBs usually have flatter networks and fewer dedicated security staff, so a policy that is easy to understand and audit matters more than a complex appliance rule base. Once policy is identity-aware, you can isolate the accounting app, the file share, and the management interface without giving each user the same implicit route into the whole environment. The architecture is less about owning more controls and more about making the trust decision explicit.

Practical implication: Rewrite access policy around roles and device posture, not around office subnets and legacy exceptions.

Threat narrative

Attacker objective: The attacker wants a reliable path from the public internet into internal systems, with enough access to steal data, deploy ransomware, or pivot deeper into the environment.

1. Entry occurs through exploitation of an internet-facing VPN or firewall appliance, or through a valid login that grants broad network access.
2. Credential abuse or appliance compromise then turns that foothold into internal reach, because the remote access layer is trusted too broadly.
3. Escalation happens when the attacker uses the permitted network path to move into systems that were never meant to be directly reachable from the internet.
4. Impact is ransomware deployment, lateral movement, or broad environment compromise after the perimeter device has effectively become the doorway into the office network.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
• CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Perimeter-centric remote access is now a governance liability: the appliance model turns patch latency into access risk, because every unpatched VPN or firewall extends the time an attacker has to find a way in. The control failure is not just technical exposure, but the assumption that the office edge is still the correct place to concentrate trust. For SMBs and MSPs, that assumption no longer holds.

SASE is less about consolidation than about relocating trust decisions: when access policy follows identity and device posture, the organisation can stop treating the network as the security boundary. That aligns the control model more closely with modern work patterns, where location tells you very little and session context tells you far more. Practitioners should see this as a governance redesign, not a packaging change.

Remote access must be governed as a privileged pathway: VPN-style access often exposes far more than users realise, which is why remote access governance belongs in identity and privilege discussions, not only in network operations. The practitioner lesson is to shrink implicit reach, because broad network admission is the wrong default for most small environments.

Long-lived appliance trust creates patch debt: every client-added firewall or VPN broadens the remediation queue and lengthens the window in which known flaws remain exploitable. The strategic implication is that small teams should prefer access models that reduce dependence on owned perimeter hardware and make policy changes faster than vulnerability cycles.

SMB security maturity now depends on policy clarity, not hardware count: a smaller environment does not mean simpler risk when the controls are still built around subnet access and shared trust. The practical conclusion is to move from box ownership to access governance, because that is where the security boundary now lives.

What this signals

Remote access governance is becoming an identity problem disguised as network change: the more access is expressed as user and device policy, the less useful the old perimeter model becomes. That means IAM, endpoint posture, and secure access design have to be discussed together, not in separate silos.

The next maturity step for SMBs is not more appliance hardening. It is reducing the number of places where a single login can open a broad internal route, and that is where cloud-delivered enforcement, conditional access, and application-specific publishing become operationally useful.

For practitioners

• Inventory every remote access path Map which users, applications, and office resources still depend on VPN access before changing anything, then translate those connections into explicit application-level rules.
• Replace subnet access with application publishing Publish only the applications each user group needs and block everything else by default, including management interfaces and legacy admin paths. See the Conditional Access Guide.
• Enforce device posture on every remote session Require compliant devices for access so valid credentials alone do not open the internal network from unmanaged endpoints.
• Retire exposed VPN listeners after cutover Disable the public listener, remove the port forward, and confirm from outside the environment that no internet-facing login page still answers.

Key takeaways

• SMB remote access is vulnerable when the network boundary is still defined by a VPN or firewall appliance that grants broad internal reach.
• The article connects that risk to exploitation and ransomware patterns, including a 31% exploitation entry rate and a 58% appliance compromise rate in cited research.
• The practical answer is to move enforcement toward identity, device posture, and per-application access, then remove the public listener entirely.

Related NHI Mgmt Group resources: Remote Access Identity Guide · Top 10 Network Security Misconfigurations · Conditional Access Guide · SASE and SSE Guide

Key terms

• Zero Trust Network: A Zero Trust Network is a network security approach that does not trust users, devices, or traffic by default. Every connection is continuously verified using identity, device posture, context, and policy before access is granted. It assumes breach, limits lateral movement, and treats network access as conditional rather than implicit.
• Secure Access Service Edge: SASE is a converged architecture that combines network connectivity with security controls such as zero trust access, secure web gateway, and firewall services. It is useful for consistent enforcement across distributed environments, but it does not replace identity governance or entitlement ownership.
• Perimeter Appliance: A perimeter appliance is a device or service that sits at the edge of an environment and mediates inbound or outbound trust, such as a VPN gateway or reverse proxy. These systems are high-value targets because compromise can expose sessions, authentication flows, or paths into protected internal services.
• Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and the control patterns that underpin modern access design. It is useful for practitioners who need to connect identity governance to access architecture and operational policy.