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. 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 deletes that device's wrapped copy. Deleting a project destroys the envelopes, which is what makes the ciphertext unrecoverable — there is no 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.
Expert deep dive
Technical depth, on request
Cryptographic primitives, key derivation, recovery, revocation and operational controls are documented in a technical whitepaper. You can have it on request. It also goes into external review — until that lands it is a document by us about us, and that is how you should read it.
- 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 — scope per case, limits named
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.
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 claiming it away.
Disclosure
The metadata surface, itemised
Encryption is half a promise until you say what stays unencrypted. This is the other half.
| Readable by us | 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 | If you use the server-routed AI assistant, the content of that one request passes through our worker in the clear to reach the provider you configured. Running the model in the browser avoids this — that is the honest reason the option exists. |
| AI operational telemetry | Yes — metadata | Which provider was called, whether it failed and how long it took. No request content. |
| SIEM export | Yes — audit metadata | If your org configures a SIEM webhook, audit events go to the endpoint you name. Assessment content is not part of that stream. |
| 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. This is what enforces separation. |
| Timestamps | Yes | Created and last-changed times, so concurrent edits and version history work. |
| Audit log | Yes | 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. |
IEC 62443
IEC 62443 Foundational Requirements
Trausto maps technical controls and evidence to the seven IEC 62443 Foundational Requirements:
- 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 Swiss-operated model is enough. A lawful order served on us cannot produce readable assessments: on our side they exist only as ciphertext. It can reach the operational metadata we run the service on — which is exactly why we document that surface instead of claiming 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 SL-T targets. 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.