Skip to main content

End-to-end encrypted projects

An encrypted project protects its content with keys that exist only in members' browsers. Ticket titles, descriptions, comments, checklist items, worklog notes, free-text custom fields, and file attachments are encrypted before they leave the device. The server stores and transmits ciphertext it cannot decrypt; not even a server administrator can read encrypted project content.

What is encrypted, what is not​

Encrypted (readable only by members holding the project key):

  • Ticket titles and descriptions
  • Comments
  • Checklist item text
  • Worklog descriptions
  • Free-text custom field values (short text and paragraph fields)
  • File attachments, including their real filename and type

Not encrypted (kept in plaintext so boards, filters, and reports keep working):

  • Project name, key, and description
  • Statuses, priorities, estimates, dates, assignees, and reporters
  • Labels and select-style custom field values
  • Sprint, board, column, and version names
  • Who did what and when (activity metadata without content)

The cryptography​

  • Each user has a personal keypair using the X-Wing hybrid KEM (X25519 combined with the post-quantum ML-KEM-768 from FIPS 203), following the guidance of European security agencies to deploy post-quantum cryptography in hybrid mode.
  • Each encrypted project has a random 256-bit content key. Content is encrypted with AES-256-GCM, bound to the project and the field it belongs to.
  • Your private key is protected by a recovery passphrase derived with Argon2id. The passphrase is generated in your browser, shown exactly once, and never transmitted. The server only stores the sealed private key blob.

Recovery passphrase and trusted browsers​

When you first set up encryption you receive a recovery passphrase (six groups of letters and digits). Store it in a password manager.

  • By default, TOW remembers the unlock key in the current browser profile for the lifetime of your login session. Reloading or reopening that browser unlocks encrypted projects silently.
  • TOW does not store the recovery passphrase or readable private key. The remembered browser key is non-exportable and can only decrypt the sealed private key fetched after authentication.
  • On a new browser, after logout, or after the login session expires, TOW waits until you open an encrypted project before asking for the passphrase.
  • Only remember a private browser profile. Anyone who can use that signed-in profile—and malicious browser extensions or injected page code—may be able to open encrypted projects.
  • You can disable Keep encrypted projects unlocked on this browser during setup or unlock, and use Settings → Sessions → Forget browser key and lock at any time.
  • Support cannot reset it. If you lose it, your access to encrypted content is gone; another project member with access must re-grant you after you set up new keys.
  • If all members of an encrypted project lose their passphrases, the content is permanently unreadable. This is the price of the server never holding a readable copy.

Creating an encrypted project​

  1. Create a project as usual and enable End-to-end encrypted project in the project info step. The choice is permanent; projects cannot be converted in either direction.
  2. If you have no encryption keys yet, the setup ceremony runs first: keys are generated, and you must save and confirm the recovery passphrase.
  3. Sample work items are disabled (the server cannot seed encrypted content).

Granting access to members​

Adding a member to the project grants them permission, but they also need the project key:

  1. The member opens the project and sets up their encryption keys if needed. Their access request appears automatically.
  2. A project manager who has unlocked the project opens Members → Encryption access and approves the request. The project key is re-encrypted for the member entirely inside the manager's browser.

Feature differences in encrypted projects​

Because the server only sees ciphertext, some server-side features are unavailable or degraded:

  • Search: global search finds encrypted tickets by issue key only. Board and backlog text filtering happens locally on decrypted content; the search text itself is never sent to the server for an encrypted project.
  • AI features: assistants, duplicate detection, semantic search, and automatic epic assignment skip encrypted projects entirely.
  • Automations: rules on structural fields (status, assignee, dates) work; content conditions and {{issue.title}}-style template fields resolve to [encrypted].
  • Forms and the customer portal are not available for encrypted projects.
  • Notifications and emails stay generic ("commented on TOW-12") and never embed content.
  • Sorting by title is unavailable on server-paginated lists (the server only holds ciphertext).
  • TQL text operators (~, !~ on title/description) do not match encrypted content.
  • Tickets cannot be moved or cloned across an encrypted project boundary.

Operational notes for administrators​

  • The server-wide setting E2EE_PROJECTS_ENABLED (Admin → Server settings → Security) controls whether encrypted projects can be created. Default: enabled.
  • Organisation exports include encrypted content as ciphertext plus the per-member wrapped project keys. Users' sealed private keys are tied to their accounts; after a cross-instance restore, members need their recovery passphrases to read encrypted content again.
  • Backups are safe to store anywhere: encrypted project content inside them is ciphertext.