Trust & Security · updated 20-07-2026

Trust & Security

Everything on this page is something you can verify — open code, signed statements, raw files, named vendors. What we cannot prove, we say plainly.

Running a vendor review? Jump to the review package →

Current status

Warrant canary

July 2026 · next on or before 05-08-2026

Transparency report

H1 2026 · interim · published 17-07-2026

Independent audit

planned — self-audit and threat model published

Vulnerability contact

security@ciphera.net

01

The zero-knowledge architecture

Ciphera accounts are protected by OPAQUE (RFC 9807), an asymmetric password-authenticated key exchange: your password is proven, never transmitted. Our servers store an OPAQUE record and a wrapped vault key — not a password, and not a password hash. Account data such as your email address is encrypted on your device before it reaches us; the key that opens it exists only in your browser. We have written up how the encryption works and an itemized account of what our servers can and cannot see.

The cryptographic core is open source. Tessera — our OPAQUE implementation, server SDK, and browser SDK — is published under Apache-2.0 with a language-neutral conformance kit, so the claims above can be checked against code rather than taken on trust:

• ciphera-net/tessera (opens in a new tab) — Rust OPAQUE core and sidecar (RFC 9807 configuration #1: ristretto255-SHA-512, 3DH, Argon2id)
• ciphera-net/tessera-go (opens in a new tab) — Go server SDK
• ciphera-net/tessera-ts (opens in a new tab) — browser SDK, published on npm as @ciphera-net/tessera

On top of the cryptography, the platform ships the unglamorous controls that stop real attacks: refresh-token rotation with reuse detection, escalating account lockouts, tiered rate limiting, security alerts on sensitive account changes, and audit logs that store HMAC-hashed IP addresses only and are purged after 180 days.

02

Data handling in plain language

The short version of our privacy policy, per product:

• Ciphera ID — we cannot decrypt your vault; there is nothing useful to hand over, subpoena or not. Exactly what our servers do hold is itemized in the architecture section.
• Pulse — cookieless analytics. No cookies, no fingerprinting, no cross-visit visitor tracking, no third-party trackers on your site or ours.
• Captcha — bot protection we built and run ourselves, so no third-party CAPTCHA vendor sees your visitors.
• Relay — transactional email on our own mail servers. No third-party email provider sees who we write to or why.

The full, itemized account of what our servers can and cannot see is in what we see about you — and what we don’t.

03

Open source & audit status

Honesty over marketing: Tessera has not yet had an independent security audit. What exists today is a published self-audit (opens in a new tab) and threat model (opens in a new tab), CI-gated cross-language parity tests, and conformance vectors anyone can run. An independent third-party audit is planned; this page will state the result when it happens — whatever it finds.

The open code goes beyond the crypto core: Pulse, our analytics engine, is open source under AGPL-3.0 at ciphera-net/pulse (opens in a new tab) — the code that runs on your visitors is the code you can read.

We hold no SOC 2 or ISO 27001 certification. Rather than rent a badge, we publish the things a certification would attest to — the code, the threat model, the vendor list, the signed canary — and let you check them directly.

04

Swiss residency, Belgian jurisdiction

Your data lives in Switzerland: all services run on Swiss infrastructure in Zurich, under the Swiss FADP. The company is Belgian: Ciphera BV (KBO/BCE 1013.721.660, De Kleetlaan 2, 1831 Diegem) operates from Belgium, under GDPR and NIS2 — you can look us up in the Belgian enterprise register. Two jurisdictions, both chosen on purpose — strong data-protection law where the data sits, EU accountability where the company answers for it.

The stack is deliberately European: Swiss compute and storage, EU payment processing, CDN and DNS from an EU provider, and transactional email on our own mail servers — no third-party email provider sees account activity. One US company remains in the vendor list below: GitHub, for source-code hosting. No personal user data is stored there, and we treat jurisdiction as part of the threat model when we pick every new dependency.

05

Warrant canary & transparency reports

Legal process received, disclosed in full: we publish a biannual report of every legal request we receive, and a monthly GPG-signed warrant canary. Both are offline-signed and independently verifiable — built to outlast silent compulsion, not merely describe it.

gpg --import canary-pubkey.asc
gpg --verify \
  canary-2026-07.txt.asc \
  canary-2026-07.txt

06

Subprocessors

We minimize our reliance on third-party services. The services we use, and the data they may process, are listed below — the same list published in our privacy policy, rendered from one source so the two can never drift apart:

scroll →

This table is the whole list — there is no vendor we left out. Each one is bound by a Data Processing Agreement; full sub-processor identities, including registered addresses, are available on request at privacy@ciphera.net. We do not use:

• Google Analytics, Google Tag Manager, or any Google tracking service
• Meta Pixel, Facebook SDK, or any Meta tracking service
• Third-party CAPTCHA services (we use our own Ciphera Captcha)
• Third-party email tracking services
• Advertising networks of any kind
• Customer data platforms (CDPs) or data brokers

07

Coordinated disclosure

If you believe you have found a security vulnerability in any Ciphera service or repository, email security@ciphera.net. A machine-readable version of this policy lives at /.well-known/security.txt (RFC 9116).

We do not currently publish a PGP key. If your report is too sensitive for plain email, say so in a first message and we will arrange a secure channel.

08

Scope & safe harbor

Safe harbor — We will not pursue legal action against researchers who make a good-faith effort to follow this policy — that means avoiding privacy violations, data destruction, and service disruption, accessing only the minimum data needed to demonstrate the issue, and giving us reasonable time to remediate before any public disclosure.

09

What to expect from us

• Acknowledgement of your report within 3 business days
• An initial assessment within 7 days
• Remediation prioritized by severity, and updates as we progress
• Public credit after the fix ships, if you want it

We do not currently run a paid bug bounty program. We say so here rather than let you find out after you have done the work.

10

Our track record

We hold ourselves to the same standard we ask of researchers. In July 2026 we privately reported a server-side request forgery vulnerability in a widely used open-source service we evaluated during product research, with a proposed fix. We are coordinating with the maintainer and will publish the details once a fix is available — not before.

We will link the advisory here the day it publishes.

11

For security reviewers

Running a vendor review? The materials above are the review package: open-source cryptographic core with a published self-audit and threat model (section 03), the subprocessor list (section 06), data-handling summary (section 02), and the disclosure policy with response commitments (sections 07–09).

• A Data Processing Agreement is available on request at privacy@ciphera.net
• Security questionnaires and architecture questions: security@ciphera.net
• When the independent Tessera audit is complete, the report will be published here — not summarized, published
• Environmental footprint, measured by life-cycle assessment with no offsets: /sustainability