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, new connections from that controller are refused within about 60 seconds of confirmation. A session that is already connected is not ended by revocation; end it on the host. That timing 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?
It is generated on the device, sealed by the device's hardware security module, and never uploaded to our servers.
The sealing hardware is the Secure Enclave on macOS, the TPM on Windows, and StrongBox on Android (the TEE on devices without StrongBox). The key is unsealed in the device's memory when it signs, so this is not a claim that the key never leaves the hardware. 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. On Windows, a malicious program running as the same user can read the controller key while it is unlocked. You cannot conclude from this that a compromised host machine's key is still safe.
| Which end | Sealed by |
|---|---|
| Controller · macOS | Secure Enclave |
| Controller · Windows | TPM |
| Controller · Android | StrongBox (TEE if absent) |
| Host (all platforms) | host.key, a plaintext file |
Can the person who approves access also change governance?
They are separate actions, but in the current release they are not guarded by independent credentials.
Day-to-day authorisation (a device grant) is approved with the account time-based code, which the web backend checks. Governance changes are checked by the key machine against a time-based code of its own. The governance set decides who may take part in governing the account; a device grant decides which controller may be admitted. In the current release the key machine's code is not independent of the web sign-in code, so we do not claim that holding one credential can never 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, and it may also be able to submit governance changes. 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 | Key-machine time-based code (not independent of the sign-in code in the current release) | 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. A revocation that has arrived blocks new connections; it does not end a session that is already connected. 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 ML-KEM has not yet been security audited by a third party.
- There is no self-hosted product.
- After a reboot, before anyone logs in, a host is offline — on both macOS and Windows.