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, taking effect at most about 60 seconds after confirmation;
• 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.

Device keys are generated and held on the device itself. On supported platforms the operating system's hardware security holds them:

Platform	Key custody
macOS	Secure Enclave
Windows	TPM
Android	StrongBox

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	Keymachine operator code + owner's account code	Which controllers enter the account's governance set

Whoever approves grants day to day cannot change the governance set, and vice versa. A single leaked credential is not enough to complete 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 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 access nodes in three locations: Singapore, Hong Kong and mainland China. 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 cross-border teams

If a team spans mainland China and elsewhere, 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 in Singapore;
• Session metadata — session start and end times and byte counts, used for usage accounting and troubleshooting;
• Diagnostic telemetry — a client setting, aggregated.

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