Security model

This page covers the trade-offs FortSwift makes on security. It is written for whoever has to explain to IT or compliance why this thing is allowed into the company.

The core trade-off: no shared password

Most remote desktop tools work on "know the ID and the password and you are in". Once that password leaks, the blast radius is everything — and you usually do not know it leaked.

FortSwift does not use that model. Access is a named record with an expiry that can be revoked:

• every controller device is authorized on its own; there is no widely reusable secret;
• each device grant names exactly which controller device may do remote control;
• grants expire after 30 days by default (configurable, 90-day ceiling) — narrowing by default rather than persisting by default;
• they can be revoked at any time; new connections are refused at most about 60 seconds after confirmation, but a session already in progress is not ended by revocation — end it on the host;
• after revocation, the same key cannot simply request again.

The upshot: getting hold of someone's sign-in password does not let an attacker reach any machine — they also need the authorized device itself.

Where private keys live

Private keys never reach the API or the web servers.

The private key of a controlling device (a device that starts a remote session) is generated on that device and sealed by its hardware security module: once sealed, it can only be unsealed and used on that same device; a copy taken elsewhere cannot be decrypted. When used, it is unsealed in the device's memory and the signature is computed there.

Platform	Hardware that seals the key
macOS	Secure Enclave
Windows	TPM (with an additional OS data-protection layer)
Android	StrongBox; the Trusted Execution Environment (TEE) on devices without StrongBox

The identity key of a host (the machine being remotely controlled) is currently stored as a file in that machine's user profile, not in a hardware security module (on macOS the file is readable by its owner only; on Windows, from 4.1.28, only the current user and SYSTEM can access it and it no longer inherits the user profile's default permissions; a Linux host is not yet provided). It is generated on the machine itself, and the private key is never uploaded to the API or the web servers.

The root trust material used for issuance is held by components separate from the business services. The topmost root is anchored by a device that is never connected to a network — it takes no part in day-to-day operation and is used only in the rare cases where trust has to be rebuilt.

Separation of duties: two credentials

The authorization path is deliberately split in half, each guarded by a different credential:

Layer	Credential	Governs
Daily authorization	Account code (TOTP)	Whether this controller may do remote control
Account governance	Key-machine time-based code (not independent of the sign-in code in the current release)	Which controllers enter the account's governance set

Device grants and the governance set are separate records. In the current release the codes they depend on are not independent of each other, and a compromised web backend may be able to misuse both, so we do not claim that a single leaked credential is not enough for a privilege escalation.

Beyond the plan quota, the issuing side also enforces an absolute ceiling independent of billing — raising an account's quota does not get past that boundary.

The web backend is not the trust authority

Issuance decisions are made by a separate issuing component that verifies the account code itself, rather than trusting what the business backend reports.

The v4 trust snapshot

A host does not ask the server "may this person connect?" on every connection. It holds a signed trust snapshot — a versioned list of the grants currently in effect.

The snapshot has three segments (top level / governance / device) and is signed by the account signing key. The host:

1. verifies the signature and validates the structure;
2. projects the governance keys and the live device grants into the set of controllers it accepts;
3. rejects any snapshot whose version goes backwards (rollback protection).

The result:

• the host can decide locally whether a connection request is legitimate, without a live lookup each time;
• the snapshot refreshes about every 30 seconds, so both approvals and revocations land within at most about 60 seconds; a revocation that has landed blocks new connections but does not end a session already in progress;
• a tampered snapshot is rejected.

There is a further check at the access nodes: a node overrides the controller set a host reports about itself with the authoritative set from the issuing side — a host cannot claim a permission for itself.

Network path

FortSwift runs several access nodes; clients connect to the nearest.

Nodes handle rendezvous, relaying and admission checks. A direct connection is preferred where one is possible; relaying is the fallback.

Why this matters for teams spread across regions

If a team is spread across regions, a remote desktop over the public internet typically behaves as "fine sometimes". Nearby access plus federation between nodes exists for exactly that case.

The transport is encrypted, and input injection goes over an encrypted channel too.

Data handling and PDPC

FortSwift is operated by the Singapore company FOOKSTAR TECH PTE LTD. Singapore's Personal Data Protection Act (PDPA) applies; we follow the PDPC's nine obligations and have appointed a Data Protection Officer.

What is stored

• Account and device data — account identifiers, device names and device public keys, grant records, audit records; held on servers operated by Fookstar Tech Pte. Ltd., a Singapore company — their location has not yet been checked against our hosting contracts, so we make no statement about it for now;
• Access-node logs — remote connections use access nodes in several regions to find each other and to check access, and their traffic is relayed through a node when a direct connection is not possible; nodes handle device identifiers and network addresses, and record some of them in their local logs;
• Session records — the session-recording feature is not enabled today, so no session records are generated or stored.

What we do not do

• No silent updates — every version is an explicit, versioned release package;
• We do not sell any data.

About session content

The access nodes relay traffic and perform admission checks; they are not the trust authority. For the specific retention and encryption boundaries around session content, our formal data-processing statement is authoritative — if your procurement process needs a written answer, contact sales@fortswift.com and we will answer point by point against your compliance requirements, rather than leaving you to infer it from a documentation page.

Your rights

As a data subject you may request access to, and correction of, the personal data we hold about you. Full terms are in the privacy policy and the PDPC compliance statement on the website.

Verifiable releases

• macOS — Developer ID signed and notarized by Apple;
• Windows — EV code signed;
• Android — release signed;
• every version ships a SHA-256 checksum, and download URLs carry an explicit version number — there is no latest alias that changes quietly.

Verify the checksum before installing; the steps are in get started.

Next

• Device grants — the day-to-day surface of this model
• Controller governance — what the second credential governs