Docs
Security and Access Control
How RemotePilot controls remote access paths, permissions, and public exposure for managed PCs.
Default access model
RemotePilot is designed for operators who need to inspect and manage registered PCs remotely. Access is controlled by registered administrator accounts, registered managed PCs, and the allowed network environment.
RemotePilot has no separate external server or cloud relay: the admin console and managed PCs communicate directly over the local network. Remote screens, remote input, and task commands all stay inside the customer's internal network, and the apps send no usage telemetry or analytics to any external service.
In local network deployments, the admin console connects to RemotePilot Client through the managed PC's private internal IP address. Addresses such as 172.16.x.x through 172.31.x.x are private network addresses and are not directly reachable from the public internet.
Admin console
-> Review registered managed PCs
-> Connect to RemotePilot Client through the internal IP path
-> Run remote sessions, status checks, power actions, and tasksIn the default local network mode, managed PCs are not exposed directly to the public internet.
Local network mode
Local network mode is the simplest fit for classrooms, training labs, offices, and similar environments where the admin PC and managed PCs are on the same internal network. It uses the customer network path instead of an external cloud relay, which keeps latency low and can run even on fully closed networks with no internet access.
- Target: registered managed PCs with RemotePilot Client installed
- Operator: authorized administrator account
- Access path: customer internal network
- Direct public internet access: not enabled by default
- Main functions: remote sessions, status checks, shutdown, Wake-on-LAN (remote power-on), task execution
When external access is needed
RemotePilot itself does not run an external relay server or cloud service; remote management always happens inside the customer's internal network. So an internal IP that works on site does not automatically work from the public internet.
When external access is required, the recommended path is not to change RemotePilot, but to provide a network route at the customer level.
- Connect through the customer's VPN, then use RemotePilot over the internal network as usual (recommended)
- For any other remote access, follow a separate network design owned by the customer's network and security team.
Directly exposing managed PCs through public IP addresses and port forwarding is not recommended. For labs with dozens of PCs, it creates operational complexity and a larger firewall risk surface.
Permission control
Actions such as remote control, shutdown, Wake-on-LAN, and task execution should be used carefully under your operating policy. RemotePilot provides the following access controls.
- Registration-based management: only PCs registered in the RemotePilot console can be managed.
- Sensitive-action protection: script execution, client updates, program removal, server log access, and data reset require admin-password confirmation before they run.
- View-only vs control modes: a remote session can stay view-only for monitoring or switch to control mode, and the managed PC can also toggle whether control is allowed from its on-screen toolbar.
- Log review: the console can show server logs (connections and messages) and the client logs from each managed PC.
- Network limits: access runs over the internal network and private IPs, with allowed firewall ports and network ranges restricted.
Wake-on-LAN requirements
When a PC is powered off, RemotePilot Client is not running, so power-on behavior depends on Wake-on-LAN support. Check these requirements before relying on remote power-on.
- BIOS/UEFI settings: Wake-on-LAN must be enabled
- Operating system settings: network adapter power and wake settings must allow wake events
- Wired LAN: Wake-on-LAN over Wi-Fi is often unreliable
- Network configuration: same broadcast domain or WOL packet forwarding must be supported
- Power state: WOL cannot work if the power strip or power source is fully off
Security review checklist
- Confirm managed PCs are not exposed directly through public IP addresses.
- Define whether access uses a direct local-network connection, or a VPN path when external access is required.
- Decide who is allowed to operate the console and hold the admin password.
- Define an operating policy for sensitive actions such as script execution, client updates, and program removal.
- Keep server logs and client logs available for regular review.
- Limit allowed firewall ports and network ranges.