ISO 27001 Remote Access for MSPs: Access Control, Encryption, and Audit Logs That Map to Annex A

If your MSP is certified to ISO 27001, or working toward it, every tool that touches a client system eventually lands on your Statement of Applicability. Remote access draws attention early, because it is where privileged access, cryptography, and logging all meet in a single workflow. The 2022 revision of the standard did not make this easier. Annex A now calls out secure authentication, network security, and monitoring as distinct controls you have to evidence. A remote support tool that fights those controls turns your next surveillance audit into a scramble.

Where Remote Access Meets Annex A

Several Annex A controls apply the moment an engineer opens a session on a client device:

• A.5.15 Access control and A.8.2 Privileged access rights: who is allowed to reach which system, and on what basis.
• A.8.5 Secure authentication: sign-in has to be stronger than a shared password, with multi-factor authentication where the risk warrants it.
• A.8.15 Logging and A.8.16 Monitoring activities: a record of who did what, retained and reviewable.
• A.8.24 Use of cryptography: traffic protected in transit by a defined, approved algorithm rather than a proprietary black box.
• A.8.20 Networks security and A.8.22 Segregation of networks: the access path itself is controlled and kept separate per client.

An auditor does not want to hear that these are handled by the vendor. They want to see the mechanism and the evidence behind it.

Where Mainstream Tools Add Findings

Agent-based remote support creates work for two controls in particular. Every managed endpoint that runs a remote control agent is another asset in your inventory under A.5.9, another component to keep patched under A.8.8 (management of technical vulnerabilities), and another attack surface under A.8.7 (protection against malware). Across a fleet of client sites, that is a large, drifting population of software to account for. TeamViewer and AnyDesk were both breached in 2024, which is exactly the kind of supplier risk your ISMS is meant to weigh.

Routing sessions through a vendor's global network raises a second question. The supplier relationship controls, A.5.19 through A.5.23, expect you to understand and manage the third parties in your service chain. A tool that sends client traffic across infrastructure you cannot see makes that assessment harder to write and harder to defend.

How ProxyLink Maps to the Controls

ProxyLink was built EU-first, and its architecture lines up with the controls above instead of working around them:

• Cryptography on an open protocol (A.8.24). The transport is WireGuard, a modern, audited, open VPN protocol with a fixed, well-understood cipher suite. You are not attesting to a proprietary encryption scheme you cannot inspect.
• Secure authentication (A.8.5). Two-factor authentication is available on every account, so engineer access to client systems is never protected by a password alone.
• Access control and least privilege (A.5.15, A.8.2). 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.
• Network segregation (A.8.22). 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 never becomes a shared blast radius.
• Logging and monitoring (A.8.15, A.8.16). 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 a replayable record for privileged access review.
• Network security (A.8.20). 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.

Fewer Agents, Smaller Scope

ISO 27001 rewards doing more with fewer moving parts, and ProxyLink's model is naturally lean. You install one WireGuard tunnel on the client site's router or gateway: MikroTik, pfSense, OPNsense, EdgeRouter, or any Linux box. Nothing is installed on the individual devices you reach, so an NVR, a PBX, a managed switch, and a Windows server are all reachable through the same peer with no per-device software. That means fewer assets in your inventory, fewer components to patch, and a smaller attack surface to defend at your next assessment. The relay runs on Hetzner infrastructure in Germany, on an open protocol, with no third-party remote-access network in the path, which keeps the supplier picture short.

What a Tool Cannot Do For You

Be honest with your auditor and yourself: no product certifies your ISMS. You still need a risk assessment, a Statement of Applicability, defined access review and retention procedures, and staff who follow them. What ProxyLink provides is infrastructure that supports the relevant Annex A controls rather than undermining them: open cryptography, MFA, scoped access, network segregation, an audit trail, and a data-minimising architecture. The management system is yours to run. The tooling should give the auditor less 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.