Operating systems and images
- Windows 11
- Windows 10
- Windows 8.1 Embedded
- Linux distributions
- Yocto-built images
- Custom OS images
Full Windows PCs and Linux machines share the same account and portal as embedded devices.
Front Desk · Questions
The short answers live here. The application Q&A assistant opens from front-desk.com with the Q3 release.
Ask the Front Desk AI
Browse the public answers here today. As release access opens, the Front Desk application will add guided answers based on product documentation and your account context.
What we run on
Front Desk connects mixed fleets across operating systems, architectures, and hardware generations. When a platform needs extra engineering, our team does that work as part of the deployment.
Full Windows PCs and Linux machines share the same account and portal as embedded devices.
Small Linux boards are first-class fleet devices, RISC-V included.
Bring us the device, image, and access requirements; we make Front Desk work with the platform.
Exact support for a given device depends on its operating system, agent version, and account configuration.
Custom work
We do the work around Front Desk too. Our staff writes, tests, and integrates custom software for small Linux boards, for Windows and Linux machines, and for the systems you already run, then wires it into Front Desk.
Tell us what the device has to do and what it has to talk to. If it is a fit, we scope it, build it, test it, and hand it over working.
The full list
No. The model is outbound-only from the device to Front Desk. The site does not open inbound VNC, SSH, RDP, or admin ports.
No. Front Desk is a controlled remote-access path for specific devices and services: narrower than a VPN by design. VPNs join networks; Front Desk reaches devices. That narrower scope is easier to review, approve, and repeat across many customer premises.
No. Remote GUI is one access mode. Front Desk is aimed at field-device operations: GUI sessions, terminal access, local HTTP admin pages, logs, file transfer, commands, diagnostics, approval, and audit.
Those work for office users and attended support. Front Desk is aimed at fleets of devices installed in many places, usually with no one sitting at the keyboard.
Then the device becomes a public server, with the patching, password, and firewall exposure that brings. Front Desk exists so the device can stay private and still be reachable by the people responsible for it.
You could; plenty of fleets start there. But when no direct connection is possible, and behind customer firewalls it usually is not, each of those paths still ends up streaming through somebody's servers: the endpoint you poll, the broker you push through, or the relays a mesh or overlay network falls back to. Front Desk makes that stream the product. Its streaming system always carries the session and is designed and optimized for exactly that job: responsive interactive access, multiple simultaneous streams to the same device, and approval and audit applied to every stream on the way through. The path is protected end to end: TLS for transport, certificates and tokens for authentication and authorization. And if your security policy asks for more than that, our staff can build it as custom work.
No. Front Desk complements telemetry, billing, monitoring, and RMM systems as the secure device contact path they can rely on, not a replacement for them.
Yes. That is the design target. The customer network normally only needs to allow outbound traffic to approved Front Desk domains. No inbound rules, no address planning, no site-to-site VPN project.
The product direction covers GUI access, SSH or terminal-style access, and local service access such as a device's web admin page. Actual support depends on the device operating system, agent version, and account configuration.
Front Desk supports Windows 11, Windows 10, and Windows 8.1 Embedded, plus Linux distributions and Yocto-built images on small boards: ARM, TI and NXP families, Orange Pi, RISC-V, and low-memory devices. Custom OS images are handled as part of deployment; our team does the agent, board, OS, packaging, testing, and rollout work the platform needs.
Yes. A customer contact, store manager, supervisor, or your own support lead can review an access attempt, seeing who is asking and for which device, and approve or deny it before the session starts.
Yes, optionally, per account. Front Desk can sample an audited session's screen and have a model review it after the session ends, or while it runs. The result is a written, plain-language account of what the operator did, kept in the customer portal with the rest of the session record.
A policy you write in plain words: what an operator may and may not do on your devices. The model reviews the captured screen frames against that policy, and anything the first pass is unsure about gets a second look from a stronger model before it is called a violation.
Only if you turn that on. By default a concern just produces a flagged report for a person to read. An account can opt into ending a session on a policy violation, and can choose what happens when auditing is not available, from proceeding with a warning to refusing the session entirely.
Then no live session is possible, and that is visible. The portal shows last contact time and current status, so support knows whether the device is reachable before anyone wastes a trip or a ticket.
If a device can wake and make outbound contact, it fits. A low-power controller can check in when it has Wi-Fi, report status or usage, receive supported actions, and sleep again. The portal always shows last contact and current reachability.
That is what the Front Desk Sidecar is for: a small attachable radio module that keeps presence, status, alarms, diagnostics, and recovery commands flowing over an independent long-range radio path to a hub, even when the normal network is the thing that failed.
It can be part of that workflow. A rental controller can report usage time or activity windows when it checks in. Front Desk is not the billing system itself; it provides the secure contact path and the reported device data your billing uses.
The model is a strong conceptual fit for cash machines, kiosks, field terminals, and other customer-prem devices. Exact deployment depends on the device OS, security policy, and access method needed.
It follows a zero-trust-style direction: authenticate the device, authenticate the user, avoid broad network trust, scope access to the session, and make access visible, without treating that as a formal certification claim. There is also a one-page security overview (PDF) made to hand to a security team.
SSO, RBAC, audit export, retention controls, APIs, SIEM integration, signed installers, device groups, agent update control, and private deployment options: the product direction expects those requests.
No. Businesses with remote device fleets are the primary audience, but individuals and small teams also use it for remote machines or boards where opening ports was never an acceptable answer.
Yes. We have staff who do this work: embedded Linux and board bring-up on small single-board computers, device software for Windows and Linux, and the Front Desk integration to go with it. We do the programming, the testing, and the rollout. Tell us what you need.
Yes, and we can do that work for you. If Front Desk needs to talk to your website, your customer portal, your back-office system, or an API you already run, our staff can build and test that integration rather than leaving it to your team. Start a conversation.