Remote control session security: four questions that separate the models

Remote control sits at an odd place in the MSP stack. It is the capability clients most viscerally understand — someone else can see and drive my screen — and the one whose security model gets the least scrutiny during evaluation, because every vendor's demo looks identical: click device, session opens.

The differences are underneath, and they are worth asking about directly.

1. Where is the session actually authorized?

The question is whether the decision to grant a session is made on the server, from the authenticated operator's identity and tenant, or assembled from claims the browser supplied. A console that sends the target node and tenant along with the request, and gets a session back, is trusting whatever the client asked for.

The correct shape is that session creation happens server-side, the operator must be authenticated and authorized for that tenant and that action, and browser-supplied tenant, node, or credential claims are not trusted on their own. This is the same principle as everywhere else in a multi-tenant system; remote control just makes the consequence of getting it wrong extremely legible.

2. Who holds the remote-control platform's credentials?

Most remote-control integrations are a bridge to a second system with its own account model. If that system's API credentials pass through the browser — even briefly, even only to establish the session — then the blast radius of a compromised operator browser is the entire remote-control platform, not one session.

Credentials should stay in protected server-side integration configuration and never be returned to a client. It is a small implementation detail with a very large difference in what an attacker gets from a stolen session cookie.

Ask where the remote platform's own credentials live. If the answer involves the browser, the session is not the boundary — the platform is.

3. Does the remote pane bypass your other controls?

This is the one that gets missed. A remote-control surface tends to accumulate conveniences: a password vault flyout, a script library, a file transfer. Each is genuinely useful, and each is an opportunity to route around a control that applies everywhere else in the product.

The test is specific: if you launch a script from inside a remote session, does it go through the same authorization and signing path as a script launched anywhere else, or does the remote context have its own faster route? A vault opened in a remote flyout — does it still require its own unlock and stay tenant-scoped, or does an open session imply access?

Convenience surfaces that quietly widen authority are how a well-designed permission model ends up not describing the system anymore.

4. What is auditable afterwards?

Remote sessions are the events clients ask about after the fact, usually in an uncomfortable context: who connected to the finance workstation, when, and what did they do. "We do not log that" is an answer that costs a contract.

Session lifecycle and material operator actions should produce durable records. Not a log line that rotates out in a week — a record you can still produce when somebody asks in six months.

How this is put together in Nexus

Remote control runs as a separate interactive plane, launched from the device record so the technician keeps customer and device context. Session creation is server-side and gated on tenant authorization; the remote platform's credentials stay in protected integration configuration; the vault flyout remains tenant-scoped with its own unlock; and script execution from inside a session goes through the same signed-job and capability boundary as everywhere else — the remote surface does not get a shortcut.

It is also deliberately kept separate from our endpoint agent. They share product context but not identity custody, transport, update lifecycle, or executable hosting, so a compromise in the interactive plane does not become a compromise of the agent that runs signed jobs.