Does Your Small Business Still Need a VPN? A Practical Guide to Secure Remote Access

Does your small business still need a VPN? Secure remote access now includes more than choosing between SSL VPN and IPsec. The right approach depends on what employees need to access, the devices they use and how the business environment is designed.

Updated August 2026

A few years ago, setting up a VPN was one of the standard ways to give employees secure remote access to business resources. If someone working from home needed a file from the server, access to an accounting application or another system that lived inside the office network, they connected to the VPN first. I still manage environments where a VPN has an important job, and there is nothing inherently wrong with that. What has changed is the number of businesses that no longer operate entirely inside the four walls of an office.

Microsoft 365, SharePoint, OneDrive, cloud accounting platforms and other software as a service applications have changed what remote work looks like. Employees may work from home, job sites, client locations or multiple offices. Some businesses still have an on premises server or application that employees need to reach, while others have moved most of what employees use into cloud services. I have also worked in environments where a VPN remained in place because it was how remote access had always been handled, even though the technology and workflow around it had changed considerably.

That is why I think the better question for a small business today is not simply, “Which VPN should we use?” It is, “What do our employees actually need to access remotely, and what is the appropriate way to give them that access?”

The answer may still be a VPN. It may be a different type of secure remote access. In some environments, employees may no longer need network level remote access for their normal work at all. Before replacing one technology with another, I want to understand why the remote access exists in the first place.

“The question I ask is not simply which VPN should a business use. I want to know why the VPN exists, what employees are using it to reach, and whether that is still the best way to provide that access.”Shay, SNL-Tech Services

Does My Small Business Still Need a VPN?

Possibly. A VPN is not automatically outdated simply because a business uses cloud technology. The answer depends on what employees, owners and outside vendors still need to reach.

If your accounting application, ERP system, file server, database or another important application still lives on a private network, employees working outside the office may need some form of secure remote access to reach it. A traditional VPN can still be an appropriate way to provide that access when it is properly designed, secured, patched and managed.

The situation looks different when most of an employee's work happens in cloud services. If email is in Microsoft 365, files are in SharePoint and OneDrive, the accounting platform is cloud based and the employee's other applications are delivered through the Internet, connecting that employee back into the office network may no longer be necessary for those particular resources. That does not mean security goes away. It means the security strategy increasingly needs to account for the identity signing in, the device being used, the application or data being accessed and the controls surrounding those resources.

This is one reason I do not recommend removing a VPN simply because it seems old. I first want to understand what depends on it. The same thinking applies when I help a business decide whether moving more of its environment to the cloud makes sense. Changing the technology without understanding the workflow can create a new problem instead of solving the original one.

A useful question for an owner is surprisingly simple: If I turned our VPN off tomorrow, what would stop working?

If the answer is an accounting system, ERP application or file server, you have identified a real dependency. If nobody knows the answer, that tells us something too. The first job is understanding the environment before changing it.

What Is Happening to SSL VPN?

SSL VPN is one of the reasons I originally wrote this article, and the technology around it has continued changing.

Fortinet provides a particularly useful example. Beginning with FortiOS 7.6.3, Fortinet replaced SSL VPN tunnel mode with IPsec VPN. Fortinet also changed the name of what was previously SSL VPN web mode to Agentless VPN. Those distinctions matter because saying simply that “Fortinet removed SSL VPN” does not accurately describe what changed.

This is also a good example of why businesses cannot assume that a remote access configuration installed several years ago will remain unchanged forever. Firewall vendors update products, retire features, discover vulnerabilities and change recommended migration paths. A configuration that works today still needs someone paying attention to the product and its lifecycle.

If you use a FortiGate, I would want to know the model, FortiOS version, which remote access features are actually configured, who uses them and what business systems depend on them before recommending a change. The same principle applies to other firewall and VPN vendors.

Is SSL VPN Still Secure?

There is not a responsible universal answer of simply yes or no.

When I first wrote about this topic, I framed SSL VPN too broadly as a technology small businesses should move away from. I would not make that statement today. I would instead look at the specific vendor, product, software or firmware version, configuration, authentication method, exposed services and the resources a user can reach after connecting.

Remote access gateways deserve particular attention because they can be reachable from the Internet. Firewalls, VPN gateways and other edge security products have had vulnerabilities, including vulnerabilities that attackers have actively exploited. That does not mean VPNs are inherently unsafe. It means a security appliance needs to be treated like the important Internet facing system that it is.

For a small business owner, you do not need to memorize vulnerability numbers or become the person who maintains the firewall. You should, however, be able to get clear answers to questions such as:

• What firewall or remote access product are we using?

• Is the hardware and software still supported?

• Who is responsible for updating it?

• Which employees currently have remote access?

• Do former employees still have accounts?

• Do outside vendors have access?

• How are users authenticated?

• What can someone reach after connecting?

• Are remote access events logged?

• Do we still need every remote access method that is enabled?

If nobody can answer those questions, I would be more concerned about that lack of visibility than I would be about whether a configuration screen says SSL or IPsec.

Is IPsec Better Than SSL VPN?

I would not describe IPsec as universally more secure than SSL VPN. That is one of the biggest changes I would make to the advice in the original version of this article.

IPsec remains an established technology for VPN connections, and Fortinet has specifically moved its SSL VPN tunnel mode customers toward IPsec in current FortiOS releases. But choosing IPsec does not eliminate the need for secure authentication, current firmware, appropriate access rules, account management, logging and a clear understanding of what becomes reachable after the connection is established.

A poorly managed IPsec VPN does not become secure simply because it uses IPsec. A properly managed remote access environment involves much more than the tunnel protocol.

That is why my starting point is the business requirement rather than the acronym.

What Is ZTNA, and Is It Replacing VPNs?

Zero Trust Network Access, usually shortened to ZTNA, is becoming a larger part of the remote access conversation. The concept is easier to understand if we stop thinking about the marketing terminology for a moment.

A traditional remote access VPN often creates a secure path from a user's device into some portion of the business network. How much of that network becomes reachable depends on how the VPN and firewall policies are configured. A ZTNA style approach is more focused on giving an authenticated and authorized user access to the particular applications or resources that person is permitted to use rather than assuming that successfully connecting to a network should create broader trust.

NIST's current zero trust guidance reflects this broader change in thinking. Its final implementation guidance addresses secure authorized access to resources spread across on premises and cloud environments for hybrid workforces and partners. Zero trust is much bigger than VPN replacement, but the underlying idea is useful when we are designing remote access.

Traditional VPN approach	ZTNA style approach
Often provides connectivity into a private network	Focuses more directly on particular applications or resources
Access can be broad or restricted depending on configuration	Designed to support more granular access decisions
Establishing network connectivity is a major part of the process	Identity, device and resource policy play a larger role
Can still make sense for private network resources	Can make sense when resource specific access better fits the workflow
Security depends on the actual implementation	Security still depends on the actual product, configuration and management

That table is intentionally general because actual products and implementations differ. ZTNA is not one product, and it is not something every small business needs to purchase simply because the term has become popular.

What I like about the underlying concept is the question it forces us to ask:

Does this person need access to the network, or does this person need access to a particular business resource?

Those are not always the same thing.

Does My Business Need a VPN If We Use Microsoft 365?

Not necessarily for accessing Microsoft 365 itself.

If employees are using Exchange Online, SharePoint, OneDrive, Teams and other cloud services, they generally do not need to connect through the office network using a traditional VPN simply to reach those cloud resources. The Microsoft environment can have its own identity and access controls, including MFA and, where the appropriate licensing and configuration are in place, Conditional Access and device based access controls.

That does not mean purchasing Microsoft 365 automatically creates a secure remote work environment. I regularly find Microsoft environments where licensing exists but important controls have never been configured, old access methods remain enabled, devices are not properly managed or policies do not reflect how the business actually works. That is one reason my Microsoft 365 Tenant Security Review looks beyond whether a business owns Microsoft 365 and examines how the environment is actually configured and managed.

Microsoft also now offers Entra Private Access for reaching private applications and resources without relying on a traditional remote access VPN. Microsoft's current guidance includes a migration approach where a business can begin with broader access similar to its existing VPN and then move toward more granular per application access. Conditional Access can also be applied to the private applications being protected.

That is interesting technology, but I would not recommend it simply because it is newer or because Microsoft calls it a VPN replacement. Licensing, existing infrastructure, applications, devices, administrative overhead and the business requirement all matter. For a small business with a simple environment, adding another platform without a real need can create complexity instead of reducing it.

The technology should fit the business.

Should Remote Access Require MFA?

When a remote access service provides entry into the organization's network, MFA should be part of the security strategy. CISA's guidance for small and midsize businesses recommends MFA for remote network access as well as privileged and administrative access, and it encourages organizations to use stronger authentication methods where possible.

There is an important distinction here for businesses that eventually retire a VPN. Removing a VPN may also remove an MFA process that existed specifically to authenticate that VPN connection. That does not mean the business should abandon MFA for Microsoft 365, administrative accounts or other services.

The authentication strategy should follow the systems employees are actually using.

If an employee previously completed MFA to establish a VPN tunnel and now signs directly into cloud applications instead, I want appropriate identity protections applied to those cloud services. We have changed where the access happens. We have not decided that protecting the user's identity is no longer important.

Can I Limit Remote Access to Company Managed Devices?

Depending on the technology being used, yes, and this is an area I increasingly look at when businesses have sensitive information or employees working from multiple locations.

A username, password and MFA challenge can help establish the identity of the person signing in, but that does not necessarily tell me enough about the computer being used. Is it a company laptop? Is the drive encrypted? Is it receiving security updates? Is endpoint protection running? Has the device been reported lost or stolen? Is it a personal computer shared with other people?

In Microsoft environments where the licensing, technology and business requirements support it, Intune and Conditional Access can be used so device state or compliance becomes part of access decisions for protected resources. I have implemented controls in environments where I did not want possession of valid credentials and successful MFA alone to mean someone could access company information from any computer.

This is a different discussion from choosing a VPN protocol, but it illustrates why remote access is increasingly an identity, device and resource discussion instead of only a network discussion.

What About Employees Working From Job Sites or in the Field?

Field employees are one of the groups where I think businesses should be particularly careful about assuming that remote work automatically means VPN.

A construction estimator using an iPad, a technician working from a customer location, an employee working across a farm or large property, or a project manager at a job site may need access to company email, documents, schedules and line of business applications. If those resources are already delivered securely through cloud services, connecting the device back into the office network may add another step without providing anything the employee actually needs.

Other field employees may still need an application or system located on a private network. In that case, some form of secure remote access still has a purpose.

This is why I start with the workflow.

• What is the employee trying to do?

• What information do they need?

• Which application provides it?

• What type of device are they using?

• What happens if that device is lost or stolen?

Once those questions are answered, the remote access design becomes much easier to evaluate.

What About Vendors That Have Remote Access to My Network?

This is one of the areas I think small businesses should review more often.

Employees are not always the only people with remote access. An accounting software provider, security camera vendor, phone company, equipment vendor, outside IT provider or another service provider may have been given access at some point. That access may have been completely legitimate when it was created, but that does not mean it should remain available indefinitely without review.

When I evaluate vendor access, I want to understand who has access, why they have it, what resources they can reach, how they authenticate and whether the access is still necessary. I also want it documented. Six months from now, I should not have to look at an unfamiliar account or firewall rule and guess whether disabling it will break an important business system.

The same concept extends beyond the firewall. Third party access to cloud platforms, applications and other business systems should also be understood and periodically reviewed.

A VPN Can Be the Right Solution Today and Unnecessary Later

I have seen this transition happen with one of the small businesses I support.

When I originally reviewed the environment, employees still needed remote access to resources inside the company's network. At that stage of the project, I moved the business from its existing SSL VPN configuration to an IPsec VPN and implemented MFA for that remote access. That solution fit what the business needed at the time.

Over the following year, the technology environment changed considerably. I rebuilt the company's workflow and network infrastructure around a cloud first environment. As the systems employees depended on changed, they no longer needed to establish a traditional remote access VPN connection back into the office to do their normal work. I was eventually able to retire the VPN and the separate MFA process that existed specifically for VPN authentication.

I think that progression is more useful than simply saying one VPN protocol was better than another. The IPsec VPN was not a mistake because we eventually removed it. It solved a real requirement at that stage of the business's technology environment. Later, the requirement changed.

That is what ongoing IT management is supposed to do. The technology should evolve with the business instead of becoming permanent simply because somebody configured it five years ago.

Does Cyber Insurance Care About VPNs and Remote Access?

It can. There is no single cyber insurance questionnaire that every small business receives, and requirements vary by insurer, policy and business. Remote access, MFA, privileged access, patching and other security controls can, however, appear in underwriting questions.

The important part is being able to answer accurately.

If an application asks whether MFA is required for remote access, I do not want a business owner checking “Yes” simply because employees use MFA for email when the insurer is actually asking about a VPN that has a completely different authentication configuration. Likewise, if the company no longer provides network level remote access, the business should understand its environment well enough to explain what it actually does today.

I go deeper into this in Cyber Insurance Requirements for Small Businesses: Can You Answer the IT Questions on Your Application?. My role on the technical side is to verify what is actually configured and document what I can substantiate. The insurer, broker or other insurance professional determines what the particular policy requires.

What If My Business Handles CUI or Other Regulated Information?

Remote access deserves additional attention when it can reach systems or information subject to regulatory or contractual requirements. The exact requirements depend on the information, industry, contract and environment, so I would not tell every regulated business that it needs the same VPN, ZTNA product or cloud architecture.

For a Department of Defense contractor handling Controlled Unclassified Information, or CUI, one of the architectural questions may be whether the sensitive environment should be separated from the rest of the company's technology. Current DoD CMMC Level 2 scoping guidance recognizes the use of enclaves, which can allow an organization to establish a defined assessment scope rather than automatically assuming every asset across the entire company belongs in the same CMMC assessment scope.

For a smaller contractor, that distinction can matter quite a bit. If only a handful of employees need to work with CUI, I would want to understand why the rest of the company's computers, users and everyday business systems would need access to that environment in the first place. A properly designed enclave may help establish a clearer boundary around the people, systems and workflows involved with CUI.

An enclave does not automatically make a company CMMC compliant, and it does not automatically mean everything outside the enclave is out of scope. DoD's scoping guidance specifically recognizes that people, processes, technologies and supporting systems providing security protections to an in-scope environment can themselves affect CMMC assessment scope. The actual boundary has to be determined based on the environment and applicable requirements.

Remote access becomes part of that design. Instead of asking whether every employee should connect to the company network through a VPN, the better questions may be: Who actually needs remote access to the CUI environment? Which devices should be permitted to connect? Which resources do those users need? How is that access authenticated, restricted, monitored and documented?

Those are architecture and implementation questions that need to fit the contractor's actual CUI workflow. My role is to help design, implement, manage and document the technology appropriately. Compliance consultants, assessors and the applicable contract or regulatory requirements determine the formal compliance obligations and assessment scope.

I cover the broader technology considerations in my CMMC Level 2 and Microsoft 365 guidance for small DoD contractors.

For healthcare, financial services and other regulated businesses, the same general principle applies even though the requirements are different. Do not assume that purchasing a particular VPN, firewall or security product makes the business compliant. First understand which requirements apply, where the sensitive information lives, who needs access and how that access should be controlled.

How Do I Know If Our Remote Access Setup Needs to Be Reviewed?

You do not need to wait for something to break. In fact, the best time to answer these questions is while everything is still working.

I would want a small business owner to be able to answer:

• Do we currently use a VPN or another private remote access service?

• What product provides it?

• Why do employees need it?

• Which employees and vendors currently have remote access?

• What resources become available after they connect?

• How is remote access authenticated?

• Is MFA being used where appropriate?

• Is the firewall or remote access platform still supported?

• Who is responsible for maintaining and updating it?

• Are former employees and old vendor accounts removed?

• Are remote access events logged?

• Are employees connecting from company managed devices, personal devices or both?

• Have we moved applications to the cloud that employees previously needed the VPN to reach?

• Do any compliance, contractual or cyber insurance requirements affect the way remote access needs to be handled?

• Are we maintaining remote access simply because nobody has reviewed it recently?

• If the VPN disappeared tomorrow, what business process would actually stop working?

That last question can tell you quite a bit.

If the answer is, “Our accounting system would stop working,” then we have identified an actual dependency. We can work from there.

If the answer is, “I don't know,” then the first job is not replacing the VPN. The first job is understanding the environment.

Remote Access Should Fit the Way Your Business Works Today

I do not think every small business should eliminate its VPN, and I do not think every business needs to implement ZTNA because it is newer technology. I also would not recommend moving a company to the cloud solely to get rid of a VPN.

I want the technology to make sense as a complete environment.

For one business, that may mean maintaining a properly secured VPN because an important application still lives on premises. For another, it may mean providing more granular access to a particular private application. For a cloud first company, employees may no longer need network level remote access for their normal work at all. A business with field crews may need a combination of cloud services, managed mobile devices and limited access to one private system. A DoD contractor may have an entirely different conversation because CUI, scoping and an enclave need to be considered.

The decision starts by understanding what the business has today, who needs to access it and why.

That is also why remote access is something I look at as part of the broader technology environment rather than treating it as an isolated firewall setting. If you do not know which systems your business depends on, who can remotely access them, how that access is secured or whether the current setup still makes sense, an IT Baseline Assessment and Documentation review can help establish that starting point.

Technology changes. Businesses change. The goal is not to keep replacing one product with whatever happens to be newest. The goal is to make sure the way people access your systems still fits the way your business actually operates.

ADDITIONAL RESOURCES

Fortinet: SSL VPN Tunnel Mode Replaced with IPsec VPN

Fortinet's current documentation explaining the replacement of SSL VPN tunnel mode with IPsec VPN beginning with FortiOS 7.6.3 and considerations for existing configurations.

Fortinet SSL VPN Tunnel Mode Replaced with IPsec VPN

Fortinet: Agentless VPN

Fortinet documentation explaining the change from SSL VPN web mode to Agentless VPN.

Fortinet Agentless VPN Documentation

CISA: Require Multifactor Authentication

CISA guidance for small and midsize businesses, including MFA for remote network access and privileged access.

CISA Require Multifactor Authentication

NIST SP 800-207: Zero Trust Architecture

NIST's foundational guidance on zero trust architecture and resource-focused access.

NIST Zero Trust Architecture

NIST SP 1800-35: Implementing a Zero Trust Architecture

The final NIST practice guide, published in June 2025, includes implementation examples for protecting resources across on premises and cloud environments and supporting hybrid workforces.

NIST Implementing a Zero Trust Architecture

Microsoft Learn: Microsoft Entra Private Access

Microsoft's current guidance for providing access to private applications and resources without requiring a traditional VPN.

Microsoft Entra Private Access

Microsoft Learn: VPN Replacement with Quick Access

Microsoft's current migration guidance describes using Quick Access as a bridge from traditional broad VPN access and then moving toward per-application segmentation and Conditional Access. The page was updated April 2, 2026.

Microsoft VPN Replacement Guidance

DoD: CMMC Level 2 Scoping Guide

Current DoD guidance covering CMMC Level 2 assessment scope, CUI assets, security protection assets and the use of enclaves. The guidance makes clear that using an enclave does not automatically place every enterprise asset in scope, but supporting security assets, people and processes can still affect the assessment boundary.

DoD CMMC Level 2 Scoping Guide