BR1
Compliance evidence without oversharing
Teams can prepare IEC 62443, NIS2, CRA and data-protection evidence without spreading plaintext assessment data across tools, exports and inboxes.
Security model
Security model
Trausto reduces business exposure from sensitive risk data, supplier evidence and industrial security decisions. The security model is built to minimise data leakage, support compliance evidence, preserve operational resilience and keep privileged project knowledge under customer control.
Business impact
Business risks reduced by design
The technical model exists for a business reason: fewer uncontrolled data copies, clearer accountability and stronger resilience when critical infrastructure is under pressure.
BR2
Data leakage prevention
Project content is encrypted before it leaves the browser. Servers, operators and infrastructure providers do not become additional readers of sensitive OT risk information.
BR3
Operational resilience
Access revocation, device loss and team changes are handled as controlled security events, not as manual cleanup exercises across copied files.
BR4
Internal AI governance
Internal AI instances can be integrated with explicit boundaries and review trails, reducing the risk that sensitive context leaks into unmanaged prompts or shadow workflows.
How it works
Customer-controlled encryption
Four principles that keep sensitive project data under customer control while preserving collaborative workflows.
01
Zero-Knowledge, end-to-end
All content encryption happens client-side using the Web Crypto API; the server stores your assessments as ciphertext only. Even if compelled, your risk content would be mathematically unreadable to us — with exactly one exception, which we name rather than bury: the server-routed AI path, for the duration of a request. We document precisely which operational metadata the platform needs to run — everything else is ciphertext.
02
Hardware-bound keys
Encryption keys are anchored in the device's secure hardware (Secure Enclave, TPM or security key). Phishing-resistant, origin-locked, unlocked only through a hardware-backed WebAuthn ceremony. Lose the device, the keys go with it.
03
Per-project encryption
Each project carries its own encryption key, wrapped for every team member and every device. Joining or leaving a project is a cryptographic operation, not a permission flag in a database.
04
Crypto-shredded deletion
Removing a member from a project rotates and re-wraps that project key; removing a device revokes that device's wrapped copy — it is no longer served, but retained. Deleting a project destroys the envelopes, which is what makes the ciphertext unrecoverable — a project deletion is not a soft-delete in the cryptographic sense. What a removed party already decrypted and kept is outside any vendor's reach, and we would rather state that boundary than promise a total forgetting nobody can deliver.
The remaining trust surface
What you still have to take on trust
The unreadability statements above hold for what sits with us — not for what we ship to you. The first is mathematics, the second is trust. So here is the full list of what you still have to believe, stated the same way the disclosure below is stated: completely.
V1
The code we deliver
The application that touches your keys is delivered by us into your browser — and whoever delivers could deliver an altered build. A lawful order aimed at the future does not reach stored ciphertext; it reaches future deliveries. Our release path is controlled internally: only builds from the main branch that have passed the full test run are deployed, and dependencies are pinned. But there is no mechanism today by which YOU could independently verify that the delivered code is the one we describe.
V2
The organisation recovery phrase
The optional organisation recovery phrase deliberately lifts the finality everything else here relies on: whoever holds it can reach the projects in its permission chain. That is the price of an organisation keeping access when a person leaves — and the reason it is optional and sits in your custody, not ours. It can be replaced at any time; for the replaced phrase to lose its cryptographic effect as well, an organisation-key rotation belongs with it.
V3
The server-routed AI path
The one named exception in which content passes through our worker in the clear. It is optional, it is the single cleartext row in the disclosure below, and the build check of this website enforces that it stays the only one.
Expert deep dive
Technical depth — published
For architecture teams there is a technical whitepaper: key model, purpose-bound AAD, threat model, post-quantum status, and the open items — named in the document itself. Version 1.1, 12 August 2026. Not yet externally reviewed; that review is one of three evidence steps, and the document says so on page one.
- Client-side encryption · no readable risk content on disk
- Hardware-bound device keys · phishing-resistant
- Offline recovery path for lost devices
- Per-project keys with cryptographic membership
- Key rotation on revocation — at project level including existing ciphertext, at organisation level triggered by an administrator
Insight
What we can see — and what we cannot
Trausto runs as SaaS, operated from Switzerland. That is the whole offer: there is no on-premise edition to evaluate and no deployment matrix to negotiate. The reason is that the question on-premise exists to answer — who can read your assessments — is already answered earlier and more strongly, in the browser, before anything reaches us.
01
One operating model
Multi-tenant SaaS, built and operated from Switzerland by a Swiss company on hardened cloud infrastructure. One code path, one set of controls, one thing to audit — for you and for us. Onboarding takes days, not a procurement cycle.
02
Isolation you can point at
Every project carries its own encryption key, wrapped for each member and each device. Separation is enforced cryptographically, not only by a filter in a query — losing access is a key operation, not a flag in a table. The organisation is the unit you contract and are billed under, and the one that can deposit a recovery phrase; the project is the cryptographic unit.
03
What we hold
Ciphertext, plus the operational metadata the service needs in order to run: who holds an account, which project a record belongs to, when it last changed, how much storage you use. We itemise that surface below instead of explaining it away.
Disclosure
The metadata surface, itemised
Encryption is half a promise until you say what stays unencrypted. This is the other half.
14 items. At exactly 1 of them content is processed in the clear — on a path you do not have to take.
- 14
- items we disclose. All of them are below; nothing is summarised away.
- 1
- path on which content passes through our worker in the clear: the server-routed AI assistant. It is optional.
- 10
- items stay readable to us so the service can run. They say who, when and how much — none of them carries a sentence from a risk assessment.
What happens to your risk assessment?
Everything you enter, everything you upload, and the keys to it. This is the answer to the question you came with.
Assessment content
No — ciphertext only
Assets, zones, conduits, scenarios and evidence are encrypted on your device before upload. The one exception is the server-routed AI path below.
Uploaded evidence
No — ciphertext only
Supplier documents and attachments follow the same path as assessment content.
The one exception
AI processing
Yes, for the duration of the request
only if you use the server-routed AI path
If you use the server-routed AI assistant, the content of that one request passes through our worker in the clear to reach the configured provider — your own endpoint or, where one is set, a platform-wide default your organisation can disable. Running the model in the browser avoids this — that is the honest reason the option exists.
Key material
No — wrapped only
Your private key is wrapped separately per device by the device's secure element; your personal recovery phrase and the optional organisation one are generated in your browser and never leave it in the clear. We hold wrapped forms only.
Reach
An organisation key can unwrap the projects in its permission chain — that is how an organisation keeps access when a person leaves, and it means the organisation recovery phrase reaches those projects too.
What stays readable to us so the service can run?
10 of 14 items. They exist because the software runs hosted, several people work in it, and evidence is supposed to come out at the end. Names, timestamps, counts.
| Item | Readable by us | How long | Why it exists |
|---|---|---|---|
| Account identity | Yes | — | Name and business email. Needed to authenticate you and to address you in support. |
| Project membership | Yes — structure, not content | — | Which record belongs to which project, and who has access to it. That controls who can retrieve; the content becomes readable only through the project key. |
| Timestamps | Yes | — | Created and last-changed times, so concurrent edits and version history work. |
| Audit log | Yes | 90 days (default) · SIEM export is the long-term archive | Who did what, when. Required for the evidence trail the product exists to produce. |
| Usage volume | Yes | — | Storage consumed and record counts, for billing and capacity. |
| Device and session metadata | Yes | Sessions valid 30 days, rows purged after 90 · device entries are revoked, not deleted | Per device: the device name you chose (plain text), its public key, when it was added and when its wrapped key was last retrieved; removed devices are revoked, not deleted. Per session: browser identifier, an IP prefix — never the full address — and which device opened the session. |
| Transactional email | Yes — sent via Mailgun (EU region) | — | Registration and recovery codes, invitations and account-change notices are delivered by the email provider Mailgun. These mails carry: confirmation codes, device name, organisation name (also in the subject line), role, and the address of the acting person; on an address change, the old address is told the new one. Recipient addresses and mail metadata therefore also sit with the delivery provider. |
| Support and administration access | Yes — metadata, never content | — | Platform administrators can read member lists including email addresses, audit logs and usage statistics; assessment content they cannot — it exists on our side only as ciphertext. Administrative writes are recorded in the audit log; reads currently are not recorded individually. |
| AI operational telemetry | Yes — metadata only if you use the server-routed AI path | 90 days (default), as part of the audit log | Which provider was called, whether it failed and how long it took. No request content. |
| SIEM export | Yes — audit metadata only with a webhook you configure | — | If your org configures a SIEM webhook, audit events go to the endpoint you name. Assessment content is not part of that stream. |
＋ − The same disclosure as one table — to paste into your supplier questionnaire
| Item | Readable by us | How long | Why it exists |
|---|---|---|---|
| Assessment content | No — ciphertext only | — | Assets, zones, conduits, scenarios and evidence are encrypted on your device before upload. The one exception is the server-routed AI path below. |
| Uploaded evidence | No — ciphertext only | — | Supplier documents and attachments follow the same path as assessment content. |
| AI processing | Yes, for the duration of the request only if you use the server-routed AI path | — | If you use the server-routed AI assistant, the content of that one request passes through our worker in the clear to reach the configured provider — your own endpoint or, where one is set, a platform-wide default your organisation can disable. Running the model in the browser avoids this — that is the honest reason the option exists. |
| Key material | No — wrapped only | — | Your private key is wrapped separately per device by the device's secure element; your personal recovery phrase and the optional organisation one are generated in your browser and never leave it in the clear. We hold wrapped forms only. An organisation key can unwrap the projects in its permission chain — that is how an organisation keeps access when a person leaves, and it means the organisation recovery phrase reaches those projects too. |
| Account identity | Yes | — | Name and business email. Needed to authenticate you and to address you in support. |
| Project membership | Yes — structure, not content | — | Which record belongs to which project, and who has access to it. That controls who can retrieve; the content becomes readable only through the project key. |
| Timestamps | Yes | — | Created and last-changed times, so concurrent edits and version history work. |
| Audit log | Yes | 90 days (default) · SIEM export is the long-term archive | Who did what, when. Required for the evidence trail the product exists to produce. |
| Usage volume | Yes | — | Storage consumed and record counts, for billing and capacity. |
| Device and session metadata | Yes | Sessions valid 30 days, rows purged after 90 · device entries are revoked, not deleted | Per device: the device name you chose (plain text), its public key, when it was added and when its wrapped key was last retrieved; removed devices are revoked, not deleted. Per session: browser identifier, an IP prefix — never the full address — and which device opened the session. |
| Transactional email | Yes — sent via Mailgun (EU region) | — | Registration and recovery codes, invitations and account-change notices are delivered by the email provider Mailgun. These mails carry: confirmation codes, device name, organisation name (also in the subject line), role, and the address of the acting person; on an address change, the old address is told the new one. Recipient addresses and mail metadata therefore also sit with the delivery provider. |
| Support and administration access | Yes — metadata, never content | — | Platform administrators can read member lists including email addresses, audit logs and usage statistics; assessment content they cannot — it exists on our side only as ciphertext. Administrative writes are recorded in the audit log; reads currently are not recorded individually. |
| AI operational telemetry | Yes — metadata only if you use the server-routed AI path | 90 days (default), as part of the audit log | Which provider was called, whether it failed and how long it took. No request content. |
| SIEM export | Yes — audit metadata only with a webhook you configure | — | If your org configures a SIEM webhook, audit events go to the endpoint you name. Assessment content is not part of that stream. |
Disclosure as of 2026-08-12. Every item is confirmed against the implementation before launch; what is not confirmed is removed rather than softened.
The chain
Who else processes — and what they see
A statement about "hosting providers and third parties" is checkable only if they are named. These are all external services the platform touches — verified against the code, not asserted.
| Service | Purpose | What it sees | Commissioned by |
|---|---|---|---|
| Cloudflare | Hosting and storage of the platform (compute, database, object storage, key-value store). | Ciphertext, the metadata itemised above, and operational logs of the workers. | us — our subprocessor |
| Mailgun (EU region) | Transactional email — registration and recovery codes, invitations, account notices. | Recipient addresses and the mail contents named in the disclosure above. | us — our subprocessor |
| AI provider of your choice | Processes server-routed AI requests against the configured endpoint — your own or, where one is set, a platform-wide default your organisation can disable. | The cleartext of the one request — the single exception named in the disclosure. | you — enters the chain only through your configuration |
| Your SIEM endpoint | Receives audit events if your organisation configures a webhook. | Audit metadata. Assessment content is not part of that stream. | you — enters the chain only through your configuration |
| Your identity provider | Federated login (enterprise SSO), if configured. Proves identity; it never unwraps a key. | That a login happened. No content, no key material. | you — enters the chain only through your configuration |
For the website itself (trausto.com), Cloudflare Pages and Resend apply — they are listed in the privacy policy. The processing location of platform data will be stated here once it is fixed.
IEC 62443
IEC 62443-3-3 · Foundational Requirements
The seven foundational requirements of IEC 62443-3-3. Trausto carries them as first-class objects: you map the controls and evidence of YOUR plant against each one, and export the result. This is the structure you work in — not a statement about a certification of our own platform.
- FR1
FR1 — Identification & Authentication Control
- FR2
FR2 — Use Control
- FR3
FR3 — System Integrity
- FR4
FR4 — Data Confidentiality
- FR5
FR5 — Restricted Data Flow
- FR6
FR6 — Timely Response to Events
- FR7
FR7 — Resource Availability
Compliance
Swiss Compliance Posture
Built to align with revFADP / nFADP, GDPR data minimisation, the EU Cyber Resilience Act, NIS2 and ENISA guidance for industrial cybersecurity. Because assessment content is encrypted before it leaves the customer browser, where the service runs is a resilience and jurisdiction question rather than a confidentiality one — which is why one operating model with a Swiss counterparty is enough. That says nothing about where data rests; that statement sits in the subprocessor chain, once it is fixed. A lawful order served on us cannot produce readable assessments: on our side they exist only as ciphertext — outside the server-routed AI path, which is optional and is the single cleartext row in the disclosure table. It can reach the operational metadata we run the service on — which is exactly why we document that surface instead of explaining it away.
- revFADP / nFADP — Swiss data protection
- GDPR — data minimisation by encryption
- EU Cyber Resilience Act (CRA) alignment
- NIS2 / KRITIS / KRITIS-DachG vocabulary
- ENISA industrial cybersecurity guidance
See Trausto against your own zones
Bring one real site — your zones, conduits and security level targets (SL-T). In a single technical session we show how Trausto turns it into audit-ready IEC 62443 evidence, with your assessment content encrypted before it ever leaves the browser.