SOC 2 Remote Access for MSPs: Mapping WireGuard, MFA, and Audit Logs to the Trust Services Criteria

If your MSP is pursuing a SOC 2 report, or a client is asking to see one before they sign, remote access is one of the first things an auditor pulls apart. It sits exactly where privileged access, encryption, monitoring, and vendor risk all meet. SOC 2 does not hand you a list of approved products. It asks you to show that the controls you claim are designed well and operating over time. A remote support tool that works against those controls turns your Type II observation window into a running source of exceptions.

What SOC 2 Actually Asks For

SOC 2 is built on the AICPA Trust Services Criteria: the 2017 criteria, with revised points of focus issued in 2022. There are five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security, the Common Criteria (CC1 through CC9), is mandatory in every report; you scope in the others based on what you promise clients. For a remote access workflow, three areas do most of the work:

• CC6, logical access controls. Who can reach which system, how they authenticate, and how data is encrypted in transit. This is the criterion that generates the most audit exceptions, so it is the one to get right first.
• CC7, system operations. Detecting and responding to security events, which in practice means monitoring and a usable record of activity.
• CC9, risk mitigation. Managing the vendors and subservice organisations in your service chain, remote access included.
• If you scope in the Availability category, the access path also has to be reliable enough to meet whatever commitment you make to clients.

An auditor will not accept "the vendor handles it." They want to see the mechanism and the evidence, sampled across the observation period.

Where Mainstream Tools Create Exceptions

Agent-based remote support works against CC6 and CC9 at the same time. Every managed endpoint running a remote control agent is another access path to authenticate and review, another piece of software to keep patched, and another attack surface to defend. TeamViewer and AnyDesk were both breached in 2024, which is exactly the supplier risk CC9 expects you to weigh. Routing sessions through a vendor's global network adds a second question under CC9: you now have a third party carrying client data that you have to assess and document.

How ProxyLink Lines Up With the Criteria

ProxyLink was built EU-first, and its architecture supports the relevant criteria instead of fighting them:

• Encryption in transit (CC6). The transport is WireGuard, a modern, audited, open VPN protocol with a fixed cipher suite. You are evidencing a defined algorithm, not attesting to a proprietary black box.
• Strong authentication (CC6.1). Two-factor authentication is available on every account, so engineer access to client systems is never a password alone.
• Least privilege (CC6). Teams, client groups, and per-engineer scoping let you grant an engineer only the sites and devices they support. An employee-level technician can be limited to individual devices, and every grant is visible for access review.
• Network segregation. WireGuard peer isolation is enforced at the kernel level with per-team firewall sets, so one client's tunnel can never reach another's. A shared platform does not become a shared blast radius.
• Monitoring and logging (CC7). Every session is logged with engineer identity, target IP and port, timestamp, and duration. RDP and SSH sessions can be recorded per link, giving you replayable evidence to sample during a Type II window.
• Reduced attack surface (CC6). The tunnel dials outbound and holds itself open, so the client network keeps zero open inbound ports. A scan of the site's ISP range finds nothing to connect to, whether the site is on a static IP, a dynamic line, or CGNAT.

A Shorter Vendor Chain for CC9

CC9 rewards keeping your supplier picture short and legible, and ProxyLink's model helps twice. First, you install one WireGuard tunnel on the client site's router or gateway, MikroTik, pfSense, OPNsense, EdgeRouter, or any Linux box, and nothing is installed on the individual devices you reach. An NVR, a PBX, a managed switch, and a Windows server are all reachable through the same peer, so there are fewer assets to inventory, patch, and account for. Second, the relay runs on Hetzner infrastructure in Germany, on an open protocol, with no third-party remote-access network in the path, so the subservice picture you have to describe stays short.

What a Tool Cannot Do For You

Be straight with your auditor and yourself: no product gives you a SOC 2 report, and ProxyLink is not itself SOC 2 certified. The report describes your controls operating over time, and you still need the policies, the access reviews, the change management, and the evidence to back them. What ProxyLink provides is infrastructure that supports the relevant criteria rather than undermining them: open encryption, MFA, scoped access, kernel-level segregation, a session audit trail, and a data-minimising architecture that keeps your control environment smaller. That is less for an auditor to question, not more.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. One tunnel per client router, every device reachable from a browser, every session logged. Setup guides for MikroTik, pfSense, OPNsense, and OpenWRT are in the docs.