Screen Share, Side Door: The Third-Party Session Your VPN Never Sees

The Tunnel Ends Where the Vendor Begins

Most small and mid-sized accounting firms have done the work. Staff laptops route through a business VPN. Remote access to tax software sits behind MFA. Home networks have been audited against a checklist. The perimeter, on paper, is airtight.

Then a partner calls the tax software vendor's support line about a K-1 import error. The support technician asks to "take a quick look." The partner accepts a screen-sharing request, and within ninety seconds, a return bearing a client's Social Security number, AGI, and bank routing details is streaming across a connection the firm's VPN has no visibility into whatsoever.

Nothing about that session touches the firm's tunnel. No log captures it. No policy governs it. It is, in every meaningful sense, a side door — and it opens outward, from the inside.

What a Packet Sniffer Sees During a Vendor Session

To understand the exposure, it helps to think like the network engineer we consulted for this piece. During a demonstration, he joined a mock screen-share session on a captive hotel network using a consumer-grade collaboration tool with weak transport encryption.

The screen content itself — the pixels of the shared display — was encrypted at the application layer. But the metadata was not: session identifiers, the vendor's endpoints, the duration of the connection, and in some configurations, thumbnails transmitted during connection setup. Worse, the shared screen included a browser tab left open to the firm's client portal, where the technician — a stranger with no engagement letter, no confidentiality agreement with the firm, and no background check — could read client names and balances at his leisure.

The VPN did exactly what it was configured to do: protect firm-managed traffic. The problem is that the session in question was never firm-managed traffic. It was initiated by an employee, on a firm machine, to a third party, over a channel the tunnel policy never contemplated.

Why the Standard Perimeter Model Fails Here

Traditional VPN thinking assumes two parties: the firm and the remote worker. The worker authenticates, the tunnel encrypts, the firm's resources stay protected. Third-party collaboration tools break this model in three ways:

• The session is outbound, not inbound. Firms typically secure ingress — remote access to servers and workstations. A screen share is egress to an external party, often initiated ad hoc under time pressure during busy season.
• The counterparty is unvetted. Your vendor's support technician may be a contractor on another continent. The firm's B2B relationships rarely extend down to the individual joining the session.
• The data is the screen. Encrypting the connection matters less than controlling what's on the display. A shared screen is a full copy of whatever is visible — including windows the technician never needed to see.

A Framework for Extending Policy to Third-Party Sessions

Closing this gap does not require abandoning collaboration tools; it requires governing them. We recommend a four-part framework, structured so it can be evidenced for a peer review or SOC 2 Type II examination.

1. Inventory the collaboration surface. List every tool through which an outside party can view a firm screen or drive a firm machine: vendor support portals, remote-control utilities bundled with tax and audit software, and general-purpose meeting apps. Most firms discover they have more than they expected.

2. Classify by data exposure. Sessions that could display taxpayer PII, client financials, or credentials warrant the highest tier. A session to troubleshoot a printer driver warrants a lower one. This mirrors the risk-tiering language auditors already expect.

3. Mandate a pre-session ritual. Before any high-tier session: close all client applications, use a clean browser profile, engage the VPN with a split-tunnel policy that routes the session through firm-controlled infrastructure where the tool permits it, and record the session where feasible. A one-page checklist, signed off annually, converts policy into evidence.

4. Put the vendor under contract. Require that support technicians connect from authenticated vendor endpoints, that sessions be logged by the vendor, and that technicians handling client data fall under your confidentiality terms — the same way you'd treat any subprocessor.

What Auditors Are Starting to Ask

Our conversations with reviewers suggest this topic is moving from obscure to expected. SOC 2 criteria around access control logically extend to any channel through which a third party can access systems processing client data, and we've heard of at least one peer review where the reviewer asked specifically how the firm supervised vendor screen-share sessions. The firm in question had no answer. It now does.

The uncomfortable truth is that the industry has spent the last several years encrypting the front door while propping open a side entrance for convenience. A VPN that protects your staff but not your vendors' sessions isn't a failure of the technology. It's a failure of imagination — and one that a written policy, a checklist, and a quarterly review can fix for the cost of an afternoon.

Busy season will bring the next support call. Better that the policy exists before it does.