Core concepts
Tenants, members, transfers, upload requests, links, verification and file states.
This page defines the terms used throughout the Secure File Transfer documentation. Each maps to something concrete in the design: a role, a record, or a state a file or transfer moves through.
People and roles
Tenant. One customer company and everything that belongs to it: its people, policies, transfers, files and audit log. Isolation is enforced in the application and again by PostgreSQL row-level security. A platform operator creates each tenant.
Member. An employee of the tenant who signs in with multi-factor authentication or the company's single sign-on. A member sends transfers, creates upload requests, and sees and revokes their own.
Tenant admin. A member with the admin role, typically IT or security staff. Admins manage members, tenant policy and the DLP policy, see and revoke every transfer and upload request in the tenant, and search the audit log. They see metadata and finding counts, never file contents.
Approver. A member or admin named to decide transfers that a DLP rule holds for approval, never their own.
Platform operator. The team that runs the service. Operators provision tenants and respond to alerts, but can't read file contents. Emergency break-glass access is time-limited, audited and raises an alert.
Transfers and upload requests
Transfer. One send: a set of 1 to 50 files shared with 1 to 50 external recipients, with an expiry and an optional message and download limit. See Sending files.
Upload request. One request for a single external person to deliver files to a member. See Requesting files.
Recipient. An external person a transfer is sent to. Recipients have no account; each gets their own link.
Uploader. The external person an upload request is sent to. An uploader has no account and reaches only that request.
Transfer states
| State | Meaning |
|---|---|
draft | Being prepared; files may still be uploading. Cancelled after 7 days without activity. |
submitted | The member pressed send; files are still being scanned and inspected. The expiry clock starts here. |
awaiting_confirmation | Every file is shareable, but a DLP rule needs the sender to confirm a warning or request approval. |
pending_approval | Waiting for an approver's decision. |
held | Not sent, because a file is blocked, a DLP rule blocked it, or an approver rejected it. No recipient is notified. |
sent | Recipients have been notified and can verify and download. |
revoked, expired, cancelled | Ended. The links no longer work, and deletion of the files is due. |
An upload request is simpler: it is open until it is revoked or expired.
Links and verification
Link and token. Each recipient and each upload request gets a link carrying a 256-bit random token in the URL fragment, the part after #, which browsers never send to a server. The service stores only a hash of it. On its own, a token reveals only the kind of link, its access state and its language.
Verification. Proof that an external person controls the invited email address at the moment of access. The proof is a 6-digit one-time code emailed to that address, valid for 10 minutes. See Recipient verification.
Verified session. What a correct code creates: a session bound to that browser by a secure cookie and to that one recipient or upload request. It lasts at most 24 hours, never past the item's expiry, and ends after 1 hour idle. Revoking the transfer or request ends its sessions at once.
Download grant. The right to download one file, created and counted once per download and bound to the verified session that asked for it. Resuming an interrupted download uses the same grant, so it doesn't use up the download limit, and a forwarded download address works for nobody else.
File states
The malware scan and the DLP inspection run in one pass, so scanning covers both.
| State | Meaning |
|---|---|
uploading | Parts are going from the browser straight to storage. Resumable. |
completing | The service is assembling the parts and checking the declared size. |
scanning | Malware scan and DLP inspection in progress. |
clean | No malware found. |
infected | Malware found. Quarantined and never downloadable by anyone, including the sender, admins and operators. |
unscannable | The scanner couldn't look inside, for example a password-protected archive. Blocked by default; tenant policy can allow it, with a warning to whoever downloads it. |
scan_failed | The scan kept failing after retries. The file stays blocked and an operator alert fires. |
rejected | The upload never finished, failed a check, or arrived after its transfer or request ended. |
deleted | The contents are gone. |
Shareable means a file is clean, or unscannable and allowed by tenant policy, and its DLP inspection finished without failing. A received file must also not be blocked by a DLP rule. Only shareable files can be downloaded. Blocked covers the rest: infected, scan failed, unscannable and not allowed, inspection failed, or blocked by a DLP rule.
Inspection results
Each file also records how fully it was inspected: inspected, partial or not_inspected, with reasons such as encrypted content or an unsupported type. A file not fully inspected is never treated as having no findings; the tenant's rules decide. An inspection that keeps failing is failed, which blocks the file. See Data loss prevention.
Retention and audit
Retention. How long data is kept. A transfer's files are deleted when it expires or is revoked. Files received through an upload request are kept for the tenant's retention period (default 30 days, 1 to 90 by policy), counted from each file's upload. Once deletion is due, the target is that contents are gone from every copy, backups included, within 7 days. See Revocation and retention.
Audit record. One entry in the tenant's audit log for a security-relevant action, such as a sign-in, upload, scan result, DLP decision, verification attempt, download, revocation or policy change. It holds the actor, tenant, target, time, source IP and user agent, never a file name, message, email address, token or code. Records are kept for 365 days and, in production, archived under a lock that prevents change or deletion before then. See Audit log.
Source: PRD, Data model, Authentication and authorization