EN
Create account
About Log in
End-to-end encryption

How end-to-end encryption works in sygnadesk

Report content is encrypted in the reporter’s browser and read only in the browser of an authorised person. The key is derived from their password and never reaches the server, so neither sygnadesk nor a partner has anything to read the content with.

AWhat the difference is: where the key livesStandard mode (default): the platform holds the keyReporter’sbrowsersygnadesk serverWarsaw, FrankfurtCase team’sbrowserTLS, then readable on the serverreadable for authorised usersThe server encrypts data in the database with its own key. Operator staff access is limited tosupport requests and logged.End-to-end mode: the key lives only in browsersReporter’sbrowsersygnadesk serverWarsaw, FrankfurtCase team’sbrowserciphertextciphertextThe server receives and returns only ciphertext. It has no key, so it cannot read the content, evenif it wanted or had to.BWhere the keys come from and why the server has nonePerson’s passwordTyped in the browser. Neversent to the server.createsPersonal keyDerived from the passwordin the browser. Stored onthe server only encrypted.opensOrganisation vaultThe organisation key lockedseparately for eachauthorised person.holdsOrganisation keyDecrypts reports. Livesonly in browser memory.readsReport contentVisible in this person’spanel, in their browser.public partReporting pageReceives the public part ofthe key. Every new reportis encrypted with it.sygnadesk serverStores ciphertexts andlocked vaults. Without apassword it opens none.ciphertextThe public part of a key can only encrypt, never decrypt.So the reporting page, the server and anyone who sees itcan put content into the vault but cannot open it.CThe path of a report: where content is readable and where it is encrypted1Reporter writesContent, files, optionally contactdetails. A page under the companybrand, no account, no login.2Browser encryptsWith the public part of theorganisation key, before sendinganything. From now on only ciphertextexists.3Server storesCiphertext in a database in the EU,backups in the EEA. It sees the casenumber, status and deadlines. Not thecontent.4Person enters passwordThe password creates the personal key,the personal key opens the vault, thevault releases the organisation key.5Team readsContent appears only in this person’sbrowser. The reply goes back the sameway, encrypted.plain textciphertextciphertextplain textTHIS IS THE SYGNADESK OPERATOR: IT SEES ONLY CIPHERTEXTDWhat happens when…An employee leavesThe administrator rotates theorganisation vault: a new key lockedonly for the remaining people. Theleaver loses access immediately.Someone forgets a passwordThey open the vault with a personalemergency code issued when access wasgranted. The code is kept outside thesystem.Everyone loses passwordsand codesNobody can recover the content, noteven sygnadesk. That is why theorganisation keeps at least two peoplewith working access.An authority demands datafrom the operatorThe operator holds ciphertext andmetadata. It has no key, so there isnothing to hand over. The request goesto the organisation.The organisation disablesE2EA 48-hour window with cancellationfrom a link in the e-mail. Afterswitching to standard mode theoriginal ciphertext is kept asevidence.Enabling the mode is the organisation’s decision: administrator, declarations of consequences, e-mail confirmations and an audit log entry. Set out in the Terms (section 3) and the DPA (section 3.2).
Four parts: where the key lives in each mode, where keys come from, the path of a report and the edge cases. On a phone, scroll the graphic sideways.

A. What the difference is: where the key lives

In standard mode (the default) report content is encrypted in the database with keys managed by the platform. That protects against leaked disks and backups, but the key sits on the server side: in exceptional, logged situations (a support request at your instruction, a legal obligation) operator staff can reach the content.

In end-to-end mode the key exists only in browsers: the reporter’s, which encrypts, and the authorised person’s, which decrypts. The server receives and returns only ciphertext. It has no key, so it cannot read the content even if it wanted or had to. You switch the mode on with one setting, and the organisation takes on responsibility for the keys.

B. Where the keys come from and why the server has none

Every authorised person has a personal key derived from their password in the browser. The password never leaves the browser, and the private key is stored on the server only in encrypted form. The organisation key, which decrypts reports, sits in an organisation vault locked separately for each authorised person: their personal key opens their copy, nobody else’s.

The reporting page receives only the public part of the organisation key. The public part can only encrypt, never decrypt. So the reporting page, the server and anyone who sees that part can put content into the vault but cannot open it.

C. The path of a report: where content is readable and where it is encrypted

The reporter writes the report on a page under the company brand. Before anything is sent, the browser encrypts the content, files and contact details with the public part of the organisation key. From then on only ciphertext exists: it passes through the edge network, into a database in the European Union and into backups in the EEA.

An authorised person enters their password in the panel. The password creates the personal key, the personal key opens the vault, the vault releases the organisation key and the content appears in their browser. The reply to the reporter goes back the same way, encrypted the same way; the reporter reads it after entering the case number and PIN. Throughout, the operator sees the case number, status and deadlines, and neither the content nor the identity.

D. What happens when…

  • An employee leaves

    The administrator rotates the organisation vault: the new key is locked only for the remaining people, and the leaver loses access immediately.

  • Someone forgets a password

    They open the vault with a personal emergency code issued when access was granted. The code is kept outside the system, for example in a company safe or a password manager.

  • Everyone loses passwords and codes

    Nobody can recover the content, not even sygnadesk. That is why the organisation keeps at least two people with working access.

  • An authority demands data from the operator

    The operator holds ciphertext and metadata. It has no key, so there is nothing to hand over; the request goes to the organisation, which decides with its own legal team.

  • The organisation disables E2E

    A 48-hour window with cancellation from a link in the e-mail. After switching to standard mode the original ciphertext is kept as evidence.

How to enable E2E mode

The organisation decides. The administrator enables the mode in the panel, submits declarations about the consequences (including that content cannot be recovered after the keys are lost), confirms by e-mail, and an entry goes into the audit log. Then they designate authorised people: each creates a personal key from their password and receives an emergency code. The rules are set out in the Terms (section 3) and the DPA (section 3.2).

Terms, section 3: E2E mode DPA, section 3.2 How the whole system works

Enable E2E on a trial account

End-to-end mode is in every plan. Create an account, go through the enabling ceremony and check that only ciphertext remains in the database.

Create account: 14-day trial Talk to us