SSL VPN Replacement and ZTNA Migration Planning for SMBs

There is a specific kind of silence that falls over a conference room when somebody reads the phrase "integrity checker results should not be trusted" out loud from a vendor advisory. Everyone in the room knows what it means. The box that lets the whole company work from home has been rooted, the tool that was supposed to tell you whether it was rooted cannot be believed, and the only honest answer to "are we clean" is a shrug. That conversation happened in a lot of buildings last week after the Ivanti Connect Secure zero-days were chained for root access, and it is the clearest argument I know for treating SSL VPN replacement as a planned project rather than an emergency you keep postponing.

This post is about that project. Not the panic patch, not the vendor bake-off, but the actual sequencing an SMB with forty to four hundred people can afford when it decides the remote-access concentrator has had enough second chances. The short version is that zero trust network access, done in the right order, removes the single most repeatedly exploited device class of the decade from your perimeter. The long version involves inventory, identity, an honest overlap period, and a SOC that is watching the right telemetry while both systems are live.

Why the SSL VPN keeps showing up in incident reports

Start with the uncomfortable history, because it explains why this is not a vendor problem you can solve by switching vendors. Pulse Secure CVE-2019-11510 let unauthenticated attackers read arbitrary files, including cached plaintext credentials, and it was still being exploited years after the patch shipped. Fortinet CVE-2018-13379 did essentially the same thing to FortiGate SSL VPN portals, and somebody eventually dumped credentials for roughly half a million devices on a forum for free. Citrix CVE-2019-19781 turned the NetScaler gateway into a shell for anyone with a URL. Then came Fortinet CVE-2022-42475 and CVE-2023-27997 in the sslvpnd process itself, and in January 2024 the Ivanti chain of CVE-2023-46805 and CVE-2024-21887 was bad enough that CISA issued Emergency Directive 24-01 and later told federal agencies to disconnect the appliances outright (CISA ED 24-01, https://www.cisa.gov/news-events/directives/ed-24-01-mitigate-ivanti-connect-secure-and-ivanti-policy-secure-vulnerabilities).

Different vendors, different codebases, same outcome. The reason is architectural. An SSL VPN concentrator is a complicated web application and protocol parser that sits on the public internet, accepts connections from anyone on earth, and runs a large amount of code before the user has proven who they are. MFA protects the login handler. It does nothing for a memory corruption bug in the code that parses the request before the login handler ever runs. In MITRE ATT&CK terms the attacker gets T1190, exploitation of a public-facing application, and lands on a device that by design has a leg on the internal network and a cache of session material, which turns into T1133 external remote services and T1078 valid accounts almost immediately.

And the appliance is a terrible place to do forensics. These are hardened Linux images that the customer cannot fully inspect, with logging that the attacker controls once they have root. When Ivanti shipped an external integrity checker in 2024, CISA's joint advisory AA24-060B noted that the tool could be deceived and that a factory reset might not evict a persistent actor. Fortinet customers learned a similar lesson in April 2025 when the vendor disclosed that attackers had planted a symlink in the SSL VPN language-file directory that kept read access to configuration alive after the original bugs were patched. This week's reporting on a stealthy implant living on FortiGate firewalls, and the BeyondTrust Remote Support zero-day exploited by China-nexus operators, are the same story with fresh CVE numbers. If your remote-access strategy depends on believing what the appliance says about itself, you do not have a strategy. You have a hope.

What zero trust network access actually changes

Zero trust has been marketed so hard that a lot of security people flinch at the phrase, which is fair. Strip the branding away and NIST SP 800-207 (https://csrc.nist.gov/pubs/sp/800/207/final) describes something fairly concrete. Access decisions are made per session and per resource, based on the identity of the user, the state of the device, and policy, rather than being granted once at the network edge and then trusted everywhere behind it. The policy enforcement point sits in front of the application, not in front of the whole network.

For SSL VPN replacement, three practical differences matter more than the philosophy. First, most ZTNA architectures use outbound-only connectors. A small agent inside your network dials out to the broker, which means there is no inbound listener on your public IP waiting for the next pre-auth parsing bug. That alone removes the exact attack surface every CVE above exploited. Second, authentication happens at your identity provider before any traffic reaches anything you own, so the conditional access, phishing-resistant MFA, and device compliance checks you already pay for in Entra ID or Okta actually sit in the path. Third, a user who authenticates gets access to the specific applications their role needs, not a routable IP on a flat subnet. The bookkeeper reaches the accounting app. They do not get a network path to the domain controllers, the hypervisor management interface, and the printer that still has a default admin password.

Here is the honest caveat, because I would rather you hear it from me than from your first incident. ZTNA does not make vulnerabilities disappear. It moves them. The broker is now a cloud service, the connector is software running inside your network, and the client agent runs on every laptop. Those components have had their own bugs, and a misconfigured policy that grants "all users to all apps" rebuilds the flat network you were trying to escape. The gain is real but specific. You trade an internet-facing appliance that you must patch, monitor, and trust, for a vendor-operated control plane plus an identity provider that you were already betting the company on. That is a better trade for nearly every SMB I work with, provided the migration is planned rather than improvised.

Inventory first, because nobody knows what the VPN is for

Every SSL VPN replacement project I have watched go sideways failed at the same step. The team picked a ZTNA product, published the three web applications they knew about, told everyone to switch, and then spent six weeks discovering everything else the VPN was quietly carrying. The ERP thick client that talks to SQL on a nonstandard port. The CAD workstation license server. The engineer who RDPs into a lab box. The vendor who reaches the building management system through a shared account that nobody in IT remembers creating.

So the first deliverable is not a product selection. It is a map, and the VPN already has most of the data you need to draw it. Pull ninety days of session logs from the concentrator and from your firewall, and build a picture of which users, from which groups, reached which internal destinations on which ports. NIST SP 800-53 control CM-8 asks for a component inventory, and AC-17 asks that each type of remote access be authorized and documented. In practice most SMBs have authorized exactly one type of remote access, which is "the VPN," and that single line in the policy is hiding dozens of distinct business flows.

Sort what you find into three buckets. Browser-based applications, including internal web apps, intranet portals, and admin consoles with an HTTPS front end, are the easy wins because nearly every ZTNA broker publishes them through an identity-aware proxy with no client required. Remote desktop and SSH sessions are the medium tier, handled through brokered access that records sessions and enforces MFA per connection. The long tail of thick clients, SMB file shares, legacy protocols, and anything involving a third-party vendor is the hard tier, and it is where the overlap period will live the longest. Name an owner for every flow. Flows with no owner are the ones you are going to find out about at 7:45 on a Monday when the CFO cannot reach the accounting server.

Migration sequencing an SMB can actually afford

Once the map exists, the sequencing almost writes itself, and it is deliberately boring. Identity comes first. If your identity provider does not yet enforce phishing-resistant MFA for everyone, does not have conditional access policies that check device compliance, and still has legacy authentication protocols enabled, fix that before you move a single application. ZTNA concentrates trust in the IdP. Concentrating trust in a weak IdP is just relocating the problem. CISA's Zero Trust Maturity Model (https://www.cisa.gov/zero-trust-maturity-model) puts identity as its first pillar for a reason, and it is the cheapest pillar to improve because most SMBs already own the licenses.

Phase two publishes the browser tier. Pick the web apps from your inventory, publish them through the broker, and restrict each one to the groups that actually used it in the VPN logs. This is where users first notice the change, and in my experience they notice it positively. Opening the expense app from a hotel without launching a VPN client is an upgrade, not a burden, and early goodwill buys patience for the harder phases.

Phase three moves administrative access. RDP and SSH to servers, hypervisor consoles, and network gear should go through brokered sessions tied to individual named accounts with step-up MFA. This is also the moment to stop letting IT staff do admin work from the same identity they use for email, which is a NIST AC-6 least-privilege conversation you were going to have eventually anyway. If you read our earlier post on remote access appliance security (https://thecyberone.com/blog/remote-access-appliance-security-smb-2026), this is where those privileged-access recommendations finally get a home.

Phase four is the long tail. Some thick clients will work fine through a ZTNA client that handles TCP and UDP. Some will need the application moved to a hosted desktop or a cloud instance. A few will need the vendor to modernize, which means a procurement conversation rather than a technical one. Third-party vendor access deserves its own policy with time-bound grants, session recording, and an expiration date that someone actually reviews.

Phase five shrinks the VPN rather than killing it on a deadline. Restrict the concentrator to a named break-glass group, remove it from general user provisioning, and then, when the logs show thirty quiet days, turn it off and remove the public listener entirely. For a sixty-person professional services firm in Plano with a mostly SaaS stack, phases one through five can realistically fit inside a quarter. For a manufacturer in Allen with shop-floor systems and a dozen integrators, budget two quarters and do not apologize for it. A planned two-quarter migration beats an unplanned weekend of emergency disconnects every time.

It is also worth noticing that the vendors themselves are pointing in this direction. Fortinet began removing SSL VPN tunnel mode from FortiOS in the 7.6 branch and steering customers toward IPsec and its own ZTNA features. When the company that sold the product starts walking away from the architecture, that is not subtle.

The overlap period is where attackers get comfortable

Here is the part most migration plans skip. For weeks or months, both systems will be live. The old SSL VPN is still on the internet with a smaller user base, and the new ZTNA path is carrying most of the traffic. Attention drifts to the new system because that is where the project energy is, and the old concentrator becomes the forgotten box at exactly the moment it is least supervised. Attackers notice this pattern. A legacy appliance with a dwindling user count, deferred patching because "we are retiring it anyway," and logs that nobody reviews is close to an ideal target.

So write down the rules for the overlap period before it starts. The legacy VPN keeps its full patch clock until the day it is unplugged. A device scheduled for retirement in ninety days is not exempt from a KEV listing that lands tomorrow. NIST SI-2 asks you to remediate flaws within defined time periods, and borrowing the structure of CISA BOD 22-01 for your own timelines gives you a defensible number rather than a feeling. Shrinking the user base also gives you a gift that most teams do not use. Once only twelve named accounts are allowed on the concentrator, any authentication from a thirteenth identity, any session from a country none of those twelve people live in, or any login at a time none of them work is a high-confidence alert rather than noise.

Configuration integrity matters too. Take a configuration baseline of the legacy appliance the day the overlap period starts and diff it weekly. New local admin accounts, new authentication servers, changed portal files, and modified startup scripts are all things a persistent attacker tends to touch, and none of them should be changing on a box you are winding down. If a vendor advisory later tells you the integrity checker cannot be trusted, a baseline you captured off the box, before the disclosure, is worth more than anything the appliance can tell you about itself.

What a SOC should watch during and after an SSL VPN replacement

The detection model changes when access moves from the edge to identity, and your monitoring has to follow it. During the overlap period, the highest-value signals come from places the appliance cannot rewrite. Forward VPN and firewall logs off the device to storage the appliance cannot write to, which is NIST AU-9 in plain clothes. Watch the appliance's own outbound traffic, because a concentrator has a tiny legitimate egress profile of DNS, NTP, licensing, and authentication servers, and anything beyond that is worth a ticket. Correlate VPN sessions with identity provider sign-ins, because a VPN session for a user who has no matching authentication event at the IdP is one of the cleanest indicators of session theft you will ever get. And alert on the absence of telemetry. A concentrator that stops sending logs is not quiet. It is either broken or owned, and both deserve a phone call.

After cutover, the IdP becomes the most important log source in the company. ZTNA brokers produce rich per-application access logs, and the identity provider records every authentication, device compliance check, token issuance, and conditional access decision. The attacks shift accordingly. Instead of exploiting a parser on an appliance, adversaries go after the identity itself with MFA fatigue, adversary-in-the-middle phishing kits that steal session cookies (T1539 and T1550.004), consent phishing for OAuth applications, and device registration abuse. The detections that matter are impossible travel and anomalous token use, new MFA methods registered shortly before sensitive access, sign-ins from unmanaged devices that somehow passed policy, and a user who suddenly touches applications outside their usual pattern. The ZTNA logs make that last one unusually easy to spot because every access is already scoped to a named application.

There is also a quieter benefit. On an SSL VPN, the most interesting thing an attacker does after landing is lateral movement across a routable network, and you are trying to catch it in east-west flows that most SMBs never collect. On a well-scoped ZTNA deployment, lateral movement requires new access grants or new credentials, and both of those generate identity events. You have not eliminated the attack path. You have forced it to walk through the room where the cameras are.

Making the business case without fear-based selling

When I present this to an owner or a CFO, I avoid the scary slide. The argument is better made with arithmetic. The SSL VPN concentrator is an internet-facing device that has produced emergency patch weekends from every major vendor, repeatedly, for seven years running, and its failure mode is full internal network access for whoever finds the bug first. Cyber insurance underwriting questionnaires increasingly ask specifically about remote access architecture and whether MFA protects it, and an answer that includes identity-aware access with device posture reads very differently to an underwriter than "we have a VPN with MFA." The CISA and NSA guidance on selecting and hardening remote access VPNs already acknowledged in 2021 that these devices are prime targets, and the record since then has only made that guidance look understated.

The cost side is usually more manageable than people expect. Many SMBs already own a ZTNA capability bundled in a Microsoft, Cloudflare, Zscaler, or firewall vendor license they are paying for and not using. The real cost is labor, specifically the inventory and the long-tail application work, which is exactly why the sequencing above front-loads the cheap wins and leaves the expensive decisions for when you have data.

Bringing the SSL VPN replacement home

SSL VPN replacement is not a product purchase. It is an access redesign that happens to retire an appliance at the end. Map what the VPN actually carries, harden identity before you lean on it, publish the browser tier first, move admin access to brokered sessions, work the long tail honestly, and keep the legacy box on a full patch clock with tight monitoring until the day its public listener disappears. The organizations in McKinney and Frisco that did this work over the last two years spent last week reading the Ivanti and FortiGate headlines with mild interest instead of a ruined weekend, and that is the whole return on investment in one sentence.

The overlap period is the part of this project that needs the most watching, and it is exactly the work the Managed SOC and Threat Management module in CyberSphere was built for. It pulls legacy VPN logs, identity provider sign-ins, and ZTNA access events into one place, so a session with no matching IdP authentication or a concentrator that suddenly goes quiet becomes a ticket with evidence attached instead of three alerts sitting in three consoles nobody correlates. It runs 24/7/365 with dark-web breach monitoring on top, which matters when old VPN credentials are the first thing to surface on a forum after an appliance compromise, and MSP partners can deliver it under their own brand through the white-label portal. The platform lives at https://cybersphere.thecyberone.com/, and if you are planning your own migration this quarter, it is worth having that coverage in place before the overlap starts rather than after it ends.

Frequently Asked Questions

How quickly does Innovation Network Design respond to a security incident?

Our SOC triages and notifies within 15 minutes with confirmed details and containment steps, rather than handing you a queued alert. Incident response retainer clients carry a 2-hour guaranteed response.

Do you only work with businesses in the Dallas-Fort Worth area?

We are based in McKinney, Texas and work on-site across Plano, Allen, Frisco and the wider DFW metroplex. Our monitoring and response operate remotely, so we also support organizations nationwide.

How do we get started?

Start with a free assessment. Contact us or call 512-518-4408 and we will review your current setup and give you clear, prioritized recommendations before you commit to anything.