Accounts and sign-in
Where accounts come from
FortSwift has no public self-registration. Accounts come from two places:
- your team's first account is created by FortSwift at onboarding;
- every member account after that is created by an administrator in the admin back office (see Portal guide).
Accounts form a tree: each sub-account hangs off a parent, and the parent's quota ceilings constrain the whole subtree.
Sign-in methods
Password + account code
Email and password, plus your account code. The password is only for signing in. It plays no part in any authorization decision — having someone's password does not let you connect to any machine.
Passkey
Sign in with the device's own Touch ID / Face ID / Windows Hello / security key. No password, and nothing for a phishing site to steal.
Your service may require a passkey. In that case an account that clears two-factor but has no passkey yet is asked to add one during sign-in:
- Pass two-factor with your password and account code;
- The system prompts you to add a passkey to your account (「为你的账号添加通行密钥」);
- Adding it completes the sign-in and shows 10 one-time recovery codes;
- Password sign-in is switched off for that account — from then on, sign-in is passkey + account code.
Recovery codes are shown once
Those 10 codes are the only way back in if you lose your passkey. Save them there and then, and do not just screenshot them onto the same device.
If your browser does not support passkeys, use an up-to-date Safari, Chrome or Edge.
Signing in from the desktop client
Desktop and mobile clients complete the passkey sign-in through a browser and then hand the session back to the client.
Account code (TOTP)
A 6-digit rotating code bound to your account. Enrol it by scanning the QR with any TOTP authenticator app.
It is not only a second factor for sign-in — it is the credential that approves authorization changes.
| Operation | Account code needed |
|---|---|
| Sign in | Yes |
| Enable control permission on a host | Required |
| Approve / reject a device grant | Required (and owner/admin role) |
| Revoke a device grant | Required (and owner/admin role) |
| Start a remote session | Not needed |
The code exists in memory only for the moment you submit it, is cleared straight after, and is never written to storage.
Do not confuse it with the operator code
The account code is not the keymachine operator code. That one is only used for controller governance. Mixing them up produces an "invalid code" error.
Check your phone's clock first
Authenticators generate codes from the current time. A drifting device clock is the most common cause of "invalid code" — set the phone to sync time automatically.
The same code cannot be used twice; a code you just used prompts you to wait for the next 30-second one.
Roles
What an account can do depends on its position in the tree and its role:
- Member — uses their own devices and grants. In the portal they can only view device grants, not approve or revoke them;
- Account owner / administrator — can enable control permission on hosts, approve/reject/revoke device grants, create sub-accounts, and view the audit log;
- Account governance — operations touching the governance controller set, which need a separate operator code; see controller governance.
For the exact role names and menus you see, the app itself is authoritative.
Next
- Device grants — the main thing the account code is for
- Portal guide — where these settings live