Technical explainer
How remote desktop, remote support and RMM tools actually work
Four diagrams covering the mechanics behind remote management: how a session is brokered without opening inbound firewall ports, the difference between permanent and one-time agents, the security layers wrapped around a session, and the monitoring loop that keeps a fleet healthy. Vendor-neutral explanations, with notes on how 247connect implements each part.
Diagram 1 — connection path
From click to live session in about eight seconds
A remote desktop session is not a direct inbound connection to the target machine. Both ends — the operator console and the agent on the remote device — make outbound connections to a cloud broker, which pairs them and relays the encrypted stream. That is why no port forwarding, VPN tunnel or inbound firewall rule is needed, and why the model survives NAT, mobile tethering and hotel Wi-Fi.
The handshake breaks down into four stages:
- Identity — the operator is authenticated as a named user with two-factor authentication, so the session is attributable to a person.
- Authorisation — the broker checks whether that operator is permitted to reach that specific device or device group.
- Key exchange — an AES-256 encrypted channel is negotiated between the two endpoints.
- Stream — screen frames, input, file transfers and chat all travel inside that single channel.
In 247connect the whole sequence typically completes in around eight seconds, and the region the broker runs in — the UK, the US or Germany — is chosen for data residency.
Diagram 2 — access models
Managed unattended access versus on-demand attended access
Every remote support tool sits somewhere on a spectrum between unattended access, where a permanent agent means the device is always reachable, and attended access, where a one-time agent is run by the person in front of the machine and removes itself afterwards.
- Managed devices suit assets you own and support repeatedly: servers, branch machines, kiosks and the standard fleet. Grouping them lets you patch, script and check health without anyone present.
- On-demand sessions suit devices you do not own or cannot pre-provision: a customer's laptop, a contractor's machine, a one-off incident. Consent is explicit and no standing access is left behind.
The security implication matters: unattended access is a standing privilege and should be scoped, logged and reviewed, whereas attended access is consent-bounded and self-expiring. 247connect licenses the two separately — managed devices and on-demand devices — so you can mix them per team.
Diagram 3 — session security
The layers wrapped around a single session
Encryption alone is not a security model. A defensible remote access setup layers four controls, each answering a different question:
- AES-256 transport — can anyone on the network read the session? No.
- Zero-trust authorisation — is this operator allowed on this device, checked per connection rather than assumed from network position?
- Two-factor authentication — is the operator who they claim to be, even if a password leaks?
- Audit logging — who connected to what, when, and for how long? This is the layer auditors and incident responders actually ask for.
Read the deeper write-up in our secure remote access best practice guide, or the 247connect security overview.
Diagram 4 — the RMM loop
Remote monitoring and management as a continuous cycle
Remote monitoring and management is not a one-off task list; it is a loop that runs permanently across a fleet. Each stage feeds the next, and remote control is only one step within it — the remediation step.
- Discover — build an accurate inventory of hardware, operating systems and installed software. You cannot manage what you cannot see.
- Monitor — track disk space, uptime, patch state and agent health continuously rather than at audit time.
- Alert — thresholds turn a signal into a ticket with an owner, before the user notices.
- Remediate — connect to the device, run PowerShell or Task Manager, transfer a fix, and reboot with automatic reconnect if required.
- Report — evidence for service owners, clients and auditors, which also tells you which alerts are noise.
More on this in the RMM best practice guide and the remote infrastructure management guide.
The numbers behind the diagrams
Connection anatomy, access models and firewall requirements
The same mechanics expressed as data: where the eight seconds go, how the two access models differ control by control, and what each connection method asks of your firewall. Sort the tables or open any chart's data table to read the raw figures.
- Click to live session
- ~8s
- Inbound firewall rules
- 0
- Outbound TCP port used
- 443
- Transport encryption
- AES-256
Data table
| Item | Elapsed time |
|---|---|
| Identity and 2FA check | 2s — Operator proven as a named user |
| Authorisation lookup | 1s — Is this operator allowed on this device? |
| Relay and key exchange | 3s — AES-256 channel negotiated |
| First frame rendered | 2s — Encrypted screen stream live |
Indicative breakdown of a typical 247connect handshake on a healthy broadband link. Latency, distance to the hosting region and endpoint load all move the total.
Data table
| Item | Inbound rules to open |
|---|---|
| Cloud-brokered agent (outbound 443) | 0 rules — No inbound exposure |
| Site-to-site VPN | 1 rules — Plus routing and client estate |
| RDP behind a gateway | 2 rules — Gateway plus internal allow rules |
| Port-forwarded RDP (not advised) | 3 rules — Directly exposed to scanning |
Counts are typical minimums for a single site. Outbound-only brokering is the reason the agent model needs no inbound rules at all.
Managed unattended access versus on-demand attended access
| Agent lifetime | Permanent, installed once | One-time, removes itself after the session |
|---|---|---|
| User presence | Not required | Required — the user starts the agent |
| Consent model | Standing, policy-granted | Explicit, per session |
| Typical devices | Servers, fleet laptops, kiosks, branch machines | Customer, contractor and public devices |
| Scheduled work | Yes — patching, scripts, reboots out of hours | No — session ends with the call |
| Audit trail | Per operator, per device, per session | Per operator, per session |
| Licensing | Per managed device | Per concurrent on-demand licence |
| Main risk to control | Standing privilege — scope and review it | Social engineering — verify the caller |
Select any column heading to sort, or filter with the box above.
The RMM loop, stage by stage
| 1. Discover | Inventory hardware, OS builds and installed software | Estate coverage as a percentage of in-scope devices |
|---|---|---|
| 2. Monitor | Continuously check disk, uptime, patch state and agent health | Patch compliance within the policy window |
| 3. Alert | Thresholds turn signals into owned tickets | Alert-to-action ratio |
| 4. Remediate | Connect, run scripts or tools, transfer files, reboot and reconnect | Mean time to resolution |
| 5. Report | Evidence for service owners, clients and auditors | Unplanned downtime, trended monthly |
Select any column heading to sort.
Walk the loop yourself, stage by stage
Step through collection, authorisation, action and verification to see the telemetry each stage emits and the outcome you should expect before moving on. Advance the events inside a stage to follow the timeline in order.
Interactive — RMM loop simulator
Step through collection, authorisation, action and verification
Collection — The agent gathers state
The outbound-only agent on each managed device samples hardware, OS build, patch state, disk headroom, uptime and its own health, then posts the result to the platform over TCP 443. Nothing listens for inbound connections, so collection works behind NAT and on roaming laptops without a VPN.
Telemetry timeline
- t+0sSample scheduledAgent wakes on its polling interval or on a change event.
- t+0.4sInventory readCPU, RAM, disk, OS build and installed software enumerated locally.
- t+1.1sHealth self-checkAgent version, service state and last successful check-in verified.
- t+1.6sPayload postedCompressed, encrypted sample sent outbound on TCP 443 to the broker.
- t+2.0sDevice record updatedEstate view shows a fresh timestamp for the device.
Expected outcomes
- Every in-scope device reports a current inventory record with a check-in timestamp.
- Devices that stop reporting become visible as coverage gaps rather than silent unknowns.
- Thresholds have real values to test against — disk headroom, patch age, uptime, agent version.
When it does not go to plan
A device that has not checked in is the first thing to chase. Missing telemetry is itself an alert: an agent stopped, a machine is offline, or it left the managed estate.
Signal to measure
Estate coverage as a percentage of in-scope devices
Read every stage as plain text
Collection — The agent gathers state
The outbound-only agent on each managed device samples hardware, OS build, patch state, disk headroom, uptime and its own health, then posts the result to the platform over TCP 443. Nothing listens for inbound connections, so collection works behind NAT and on roaming laptops without a VPN.
Telemetry timeline
- t+0s — Sample scheduled Agent wakes on its polling interval or on a change event.
- t+0.4s — Inventory read CPU, RAM, disk, OS build and installed software enumerated locally.
- t+1.1s — Health self-check Agent version, service state and last successful check-in verified.
- t+1.6s — Payload posted Compressed, encrypted sample sent outbound on TCP 443 to the broker.
- t+2.0s — Device record updated Estate view shows a fresh timestamp for the device.
Expected outcomes
- Every in-scope device reports a current inventory record with a check-in timestamp.
- Devices that stop reporting become visible as coverage gaps rather than silent unknowns.
- Thresholds have real values to test against — disk headroom, patch age, uptime, agent version.
If it fails: A device that has not checked in is the first thing to chase. Missing telemetry is itself an alert: an agent stopped, a machine is offline, or it left the managed estate. Signal: Estate coverage as a percentage of in-scope devices
Authorisation — The operator is proven and scoped
Before any remote action, the operator is authenticated as a named person with 2FA, then authorised against this specific device. Zero-trust means the answer is recomputed per session: being an operator is not the same as being allowed on this machine.
Telemetry timeline
- t+0s — Session requested Named operator asks to act on a specific managed device.
- t+2.0s — Identity proven Credentials plus second factor checked; the actor is a person, not a shared key.
- t+3.0s — Authorisation evaluated Group, device scope and permission level resolved for this pairing.
- t+6.0s — Channel negotiated AES-256 keys exchanged through the broker; no inbound rule opened.
- t+8.0s — Session live and logged First frame renders; the audit record opens with operator, device and time.
Expected outcomes
- A live encrypted session in roughly eight seconds from click to first frame.
- Every session is attributable to a named operator, not to a shared account.
- Out-of-scope devices are refused rather than reachable-but-unlogged.
If it fails: A refusal here is a correct outcome, not an error. Denied attempts are worth reviewing: they show where scope is wrong or where standing privilege is being tested. Signal: Sessions authorised per named operator, and denials reviewed
Action — The fix is applied
With the session authorised, the work happens: a script or patch run unattended, or a hands-on session using PowerShell, Task Manager, services and file transfer. Reboots reconnect automatically so a restart does not end the job.
Telemetry timeline
- t+0s — Action started Script, patch, file transfer or interactive session begins.
- t+3s — Elevation recorded Any privilege escalation is captured in the session log.
- t+45s — Change applied Patch installed, service restarted, registry or config change written.
- t+50s — Reboot issued If required — the agent reconnects on boot without a second call-out.
- t+95s — Action closed Exit codes, transferred files and operator notes attached to the record.
Expected outcomes
- The change is applied once and recorded, so it can be repeated across the estate.
- Out-of-hours and scheduled work lands without a user present on managed devices.
- The audit trail shows what was changed, by whom, with what result.
If it fails: A non-zero exit code or a device that fails to return after reboot must reopen the ticket. An action with no verification is a change of unknown value. Signal: Mean time to resolution, and first-time fix rate
Verification — The loop closes with evidence
The next collection pass re-reads the same properties the alert fired on. If the condition has cleared, the ticket closes against evidence rather than optimism; if it has not, the loop reopens. Reporting rolls this into trends for service owners, clients and auditors.
Telemetry timeline
- t+0s — Post-change sample Agent re-reads the properties the alert was raised on.
- t+2s — Threshold re-tested Condition evaluated again against the same policy.
- t+3s — Alert cleared or reopened Clear closes the ticket; unchanged reopens it with history attached.
- t+5s — Evidence written Before-and-after values stored with operator, device and timestamps.
- t+24h — Rolled into reporting Trends show recurrence, noisy alerts and unplanned downtime.
Expected outcomes
- Tickets close against a measured state change, not against an assumption.
- Recurring alerts surface as a pattern to fix at the cause, not repeatedly at the symptom.
- Auditors and clients get evidence produced by the work itself, not assembled later.
If it fails: If verification is skipped, the loop is not a loop. Unverified closures are how the same fault returns next month with no history behind it. Signal: Repeat-alert rate, patch compliance and unplanned downtime
See the mechanics running live
Everything on this page is how 247connect is built: outbound-only agents, managed and on-demand licensing, AES-256 with zero-trust authorisation and full audit logs, and in-session admin tooling. The trial includes 2 on-demand licences and 10 managed devices for 14 days, with no credit card.