What Else Is in Your VPN Agent? A Module-by-Module Review

Comparing a managed VPN agent with the operating system's built-in client starts badly when the comparison is between a tunnel and a tunnel. The installer usually brings several components, and only one of them carries private network traffic. The rest may handle visibility, posture, DNS policy or endpoint inventory, each with its own configuration and its own data flow. Ask for the installed component list before you compare anything, because the product name is not the deployment.

Ask for the component list, not the product name

For every installed component, write down five facts: its purpose, who owns its configuration, what privileges it runs with, how it is updated, and how it is removed. Those five answers turn a vague concern into a reviewable inventory. They also reveal the components nobody has looked at since the pilot.

Separate the tunnel service from any independently deployed visibility, DNS or posture function. A module that observes flows is a different thing from a module that routes them, even when both ship in the same package.

Do not infer the inventory from a logo or from a licence page. Infer it from the installed files, the running services and the configuration actually pushed to the device.

Three questions decide whether to keep the agent

First, does any required workflow depend on a module that a native profile cannot replace? Posture checks, split-tunnel DNS policy and flow visibility are the usual answers, and each one has a different replacement cost. Second, what data leaves the device, to whom, under which policy and for how long? That question is about the module's configuration rather than about its existence.

Third, who maintains the thing? A module that nobody updates is a liability whether or not it is convenient. If the answer is we will get to it, the honest comparison is between a managed capability and an unmanaged one.

Answer all three before comparing interfaces, because a smaller interface is not a smaller deployment.

What the visibility module documents, and what it does not

Cisco Secure Client's Network Visibility Module is a useful concrete example. Its administration guide for release 5.1 describes collecting flow context, including endpoint and application-related information, and it documents collection policies that decide what is gathered.

That establishes a capability of one module in one release. It does not establish that your organization installed it, enabled every field, or sends the result anywhere. Those are deployment facts, and only the deployment can answer them.

Treat vendor documentation as the boundary of what is possible, and treat the device's own configuration as the boundary of what is happening.

Comparing a native profile on the same criteria

A native profile can be the approved and simpler arrangement, and it can also be a tunnel that drops a workflow nobody thought to check. Protocol compatibility, authentication method, route and DNS policy, failure handling and management requirements are the five comparison points, and they have to be answered for both sides.

Do not remove a required module quietly. Obtain approval for the alternative and document which responsibility moves where, because a responsibility that moves nowhere is the one that becomes an incident.

Open-source availability, a familiar vendor and a smaller window are three different facts, and none of them describes the privacy of a deployed configuration.

Check the inventory on the device itself

Start from the installed artifacts and the running services rather than from a spreadsheet. The artifact list is short, it is local, and it settles arguments that policy documents cannot.

Then correlate what you found with the policy that is supposed to apply to that device.

systemextensionsctl list
ls /opt/cisco/secureclient 2>/dev/null
pgrep -fl vpnagentd

On Windows the same evidence comes from services, processes and the vendor registry key, and the module list is usually visible in the installation directory. Collect the three outputs, attach them to the review, and ask the owner to confirm which of those components is intentional. When every component has a purpose, an owner and a removal path, the choice between agent and native profile becomes a decision rather than a debate.