Secure, self-built remote support for MSPs
Trust becomes the question the moment a helpdesk or MSP connects to a customer's PC remotely. Did the user consent? Is there a record of what happened? Is an outside vendor's access scoped? Without all three, no amount of screen clarity makes a tool secure remote support. This guide lays out what an MSP should require when choosing or building a remote-support tool, and how NetServ's consent-based remote-support product, SupportReach, meets it.
How MSP remote support differs from ordinary remote control
An ordinary remote desktop assumes "I'm connecting to my own PC" or "connecting to a device I manage, always-on." MSP and helpdesk remote support instead connects to someone else's PC, in use right now by someone else. That changes what's allowed to open a session: not an administrator's pre-registration, but the user's consent in that moment. The industry calls this an attended (consent-based) session, distinct from the unattended session used for always-on monitoring of unmanned devices.
Four requirements an MSP should check
🤝 Explicit consent
Does a session start only when the person at the machine allows it — step-by-step, like join → view → control?
⏺️ Full session recording
Is the screen and input stream persisted keyed to a session id, and replayable for audit?
🧾 Tamper-evident audit
Is the session lifecycle (start, consent, control, end) recorded so it can be independently verified — like a hash chain that reveals tampering after the fact?
🛡️ Scoped, time-boxed vendor access (PRA)
Can an outside vendor get access with no shared credentials, scoped and time-boxed, revoked automatically on end?
Building all four yourself means designing a control-approval consent gate, session recording and replay, a hash-chained audit log, and time-boxed access tokens. SupportReach already assembles these four as a policy layer on top of ConnectKit, SessionKit, ServerKit, and DeviceKit.
Self-hosting and end-to-end encryption
MSPs handle data for many client organizations. Self-hosting the connection server and recording storage (by the org or the MSP) keeps screen, input, recordings, and audit logs from leaving your boundary. Add ConnectKit's J-PAKE / AES-256-GCM end-to-end encryption on top, and even the relay server can't see session content. For MSPs serving regulated industries (finance, healthcare, public sector), both are effectively table stakes.
How SupportReach is put together
| Component | Role |
|---|---|
| Browser web console (ServerKit ViewerGateway) | Agent attaches with no install — view · control · consent. Gated by RBAC, short-lived tokens, per-device ACL |
| Support host (SupportReach Host) | Runs on the user's PC, issues the support PIN and handles consent |
| Hash-chained audit log (ServerKit) | Records the session.* lifecycle (start, consent, control, end) tamper-evidently, independently verifiable and exportable |
| Vendor PRA | Grants outside vendors scoped, time-boxed, approval-required, always-recorded access, revoked on end |
Scaling to an MSP fleet
Separate from consent-based support (SupportReach), an MSP that also monitors unattended assets can extend to DeviceKit.Rmm for inventory, live metrics, and remote command execution. For unattended device operations itself, see the unattended device RMM guide.
Rollout, step by step
Onboarding a consent-based remote-support tool like SupportReach into an MSP environment usually follows this order.
- Define policy — decide up front which sessions require consent, how long recordings are retained, and who approves vendor access.
- Deploy the console and host — install the agent web console and the support host (for user PCs) on-prem.
- Set roles and permissions — split agent, admin, and vendor roles with RBAC, and scope each vendor's PRA to a single session.
- Wire up audit — export the hash-chained audit log to your existing security monitoring, such as a SIEM.
- Pilot, then expand — run it with a small team first to verify the consent flow and recording retention, then roll out to the full helpdesk.
Frequently asked questions
Why does consent-based (attended) support matter for an MSP?
An MSP connects to user PCs across many client organizations, so a session opening without explicit user
consent creates trust and compliance problems. A consent-based session only opens as the user allows each step
— join, then view, then control — so support happens without any risk of unauthorized access.
Is session recording and an audit log enough, or is more needed?
Recording and an audit log are the minimum for after-the-fact verification. On top of that you need a
tamper-evident (hash-chained) structure so the log itself can be independently verified as unaltered, and
scoped, time-boxed access (PRA) for outside vendors to fully meet compliance requirements.
Does the agent need to install separate software with SupportReach?
No. Agents (operators) connect from a browser-based web console (ServerKit ViewerGateway). On the user's side, a
support host is installed to issue the support PIN and handle consent.
What's guaranteed when granting PRA (privileged remote access) to an outside vendor?
SupportReach's vendor PRA grants access that's scoped, time-boxed, approval-required, and always recorded —
with no shared credentials, and access revoked automatically when the session ends.