Singapore · Remote desktop for companies
Access is a named grant, not a password.
This page is written for the person who has to explain to their own IT or compliance team why this software may be installed. Each section states a mechanism and then states what that mechanism does not cover. Both are always shown; neither collapses.
Who can connect to this machine?
Passwordless by default, authorised one controller at a time.
A host runs in account_trust mode by default and accepts only trusted controller keys. Every device grant names its subject, expires after 30 days by default (configurable up to 90), and can be revoked — after which the same key cannot simply re-apply. In this mode, holding the account login password is not enough to connect to anything; the authorised controller itself is also required.
Where this one ends
A permanent password (Argon2id) and a one-time code issued by the host per connection are two mutually exclusive optional modes, so the default is not the only mode. The password mode exists for cross-account use among others. None of this means the host can be reached after a reboot before anyone has logged in. Revocation travels by snapshot refresh: on a healthy path it takes effect within about 60 seconds of confirmation. That is not a guarantee for a disconnected network, and it is not a service level commitment.
| Mode | Credential | Status |
|---|---|---|
| account_trust | Trusted controller key | Default |
| permanent_password | Fixed password (Argon2id) | Optional |
| one_time | Code issued by the host per connection | Optional |
Where does the controller's private key live?
On controllers with hardware support, it is generated and held on the machine and never uploaded to our servers.
macOS uses the Secure Enclave, Windows the TPM, Android StrongBox. The root material used for issuing is held by a component separate from the business services, and the top-level ROOT is kept on an offline ceremony machine that is never networked.
Where this one ends
This is not a claim that every private key on every device stays in hardware. The host's host.key is a plaintext file, and there is no hardware key backend on Linux at all. You cannot conclude from this that a compromised host machine's key is still safe.
| Which end | Custody |
|---|---|
| Controller · macOS | Secure Enclave |
| Controller · Windows | TPM |
| Controller · Android | StrongBox |
| Controller · Linux | No hardware backend |
| Host (all platforms) | host.key, a plaintext file |
Can the person who approves access also change governance?
Day-to-day authorisation and account governance are held by two different credentials.
Day-to-day authorisation uses an account time-based code. Account governance uses a key-machine operator code together with an owner code. The governance set decides who may take part in governing the account; a device grant decides which controller may be admitted. Holding one credential does not confer both duties. The issuing side separately enforces a hard ceiling of 255 device grants per account, which raising a plan quota cannot exceed.
Where this one ends
Separation of duties does not mean every device grant passes a human check at the key machine — that human factor was removed from the device-grant issuing path. A compromised API can therefore still mint device grants, bounded only by the 255 ceiling and by expiry, though it cannot alter the governance set. We do not claim that leaking a single credential makes access impossible, and the 255 ceiling does not undo the effect of a breach.
| Action | Credential required | Scope |
|---|---|---|
| Day-to-day authorisation | Account time-based code | Whether this controller may connect |
| Account governance | Operator code + owner code | Which controllers enter the governance set |
Does every connection ask the server first?
No. The host decides locally from a signed trust snapshot.
A v4 snapshot is a versioned list of the grants currently in force. The host verifies its signature and structure, maps the governance keys and active grants onto the set of controllers it will accept, and refuses a snapshot whose version has gone backwards. A tampered snapshot does not pass verification.
Where this one ends
Deciding locally is neither permanent offline authorisation nor instant revocation. The snapshot refreshes roughly every 30 seconds; on a healthy path an approval or a revocation travels within about 60 seconds. No such timing is promised while the network is down.
- 1Verify the signature and structure
- 2Check the version and refuse a rollback
- 3Decide from the grants in force
Whichever section you read, these hold
- There is no SOC 2, no ISO 27001 and no third-party security audit.
- The hybrid post-quantum handshake is a design description, not an audit result. It only took effect in 4.1.17, and the independent ML-KEM audit is still open ahead of GA.
- There is no self-hosted product.
- After a reboot, before anyone logs in, a host is offline — on all four platforms.