Why you can trust us
Four things carry this product. Each one says what it means for you, and where you check it yourself. The technical detail that makes them true starts below.
Server location: Hetzner Nuremberg, Germany. Legal jurisdiction: EU / Germany (GDPR). No US provider in the data path: your files and your keys stay in the EU and never reach a US company. Transactional email is the one exception in the chain and goes via Resend, a US provider, which receives the address, the message and the invite link but never the document. See the subprocessor list on privacy.
ML-DSA-65 (FIPS 204), generated in your browser. The private key never reaches the relay. For a request you create in a browser the relay holds only ciphertext; for the hosted signing ceremony on the /v1 API it holds the document, because that is what a hosted ceremony is.
Every signature is entered into a public, append-only log. A signed document verifies without contacting us.
The relay is source-available under BUSL-1.1. You can read exactly what it does with your file and run it on your own server.
Every plan gets the same encryption, the same post-quantum signatures and the same public proof log. Pay for volume, never for security. And pay per organisation, not per user. The Community tier is not a weaker version of the product; it is the same product with lower limits. See pricing →
The limit, stated up front
Compliance documentation, not certification. The IEC 62443, NEN 7510 and NIS2 materials are architecture documents, security controls mappings and technical reference materials aligned to those frameworks. This is documentation you can use as input for your own compliance process. Paramant does not hold third-party certification for these frameworks.
Jurisdiction & privacy
A Dutch company owns this: Paramantis Solutions B.V. in Harderwijk, KvK 42115132. Several of the better known Dutch names in this market now answer to an owner abroad; this one does not. The table below is every flag that touches the product, including the one American exception, so you can check that instead of taking our word for it.
| Server location | Hetzner Nuremberg, Germany |
| Legal jurisdiction | EU / Germany (GDPR) |
| US CLOUD Act | No US provider in the data path: files and keys stay in the EU. Transactional email goes via Resend, a US provider, which never receives the document. See privacy. |
| Data retained | No plaintext, no keys. Only: transfer hash, creation timestamp, approximate encrypted size per block (up to 5 MB; exact 5 MB for the ParaSend web app), view count. Deleted after its last read. |
| IP logging | Nginx access logging is switched off in the deploy configuration (access_log off on every server block that serves the site and the relays in deploy/nginx-paramant-live.conf). Not linked to transfer content. No separate retention period is promised. A relay you host yourself is the other way round: deploy/nginx-selfhost.conf writes an access log whose first field is the client address, so switch it off if you do not want it. |
| Analytics | None. No third-party scripts on the relay or API. |
In a criminal case at the Rotterdam district court, a client had put privileged information into ChatGPT. It was the client who did so, not the lawyer. On 12 June 2026 the examining magistrate held that entering such information into an external AI service can count as disclosure, so the information loses its privileged character (ECLI:NL:RBROT:2026:9319, published 30 July 2026). That is one examining magistrate in one case, with no appeal followed. It is not settled law. What it does show is that where a document ends up is a question a court will now ask. Paramant's answer to that question is architectural, not contractual: the file is encrypted in your browser and the server never holds a readable copy, as Core principle sets out below. This is not legal advice; ask your own counsel what your matter needs.
Core principle
The relay is an untrusted intermediary. For transfers and for signing requests created in a browser it stores only ciphertext and has no access to keys or plaintext, and a fully compromised relay cannot read, forge, or retroactively recover any of them. That is not a policy, it is a cryptographic guarantee. It does not cover the hosted signing ceremony on the /v1 API, where the relay is given the document so it can run the ceremony; there the protection is a policy, and we say so rather than let the guarantee cover ground it cannot hold.
The guarantee above applies to transfers from the official SDKs (sdk-py 3.0.0, sdk-js 3.0.0) and the ParaSend web app, each of which encrypts in the client before bytes leave the device. The Chromium and Outlook extensions currently take a server-side encryption path while their client-side crypto is being finished; until that migration lands, treat extension uploads as relay-side, not zero-knowledge. Per-client status: crypto-agility § 06.
What was audited
Three external security audits in April 2026 reviewed the relay code: two by R. Zwarts, one by Ryan Williams of Smart Cyber Solutions. Together they produced 40 findings, 4 of them critical. Dates, finding counts and the commit that resolved each set are in the audit table on the docs page, and every finding is written up in SECURITY.md in the public repository.
The Smart Cyber Solutions review is published in full, finding by finding, as the April 2026 audit report. What is not published is the raw pentest output behind it. A further external review of the v3.0.0 and open-core architecture is planned.
For the cryptographic architecture in full, see the architecture page.
Cryptography
All algorithms are from NIST post-quantum standards (FIPS 203, 204, 205, 206) or established symmetric primitives. Nothing custom. No proprietary key exchange. The relay ships 3 KEMs and 17 signature schemes. The default core mode loads ML-KEM-768 and ML-DSA-65; extended mode loads all of them. Clients choose, the relay validates, and the live registry is at /v2/capabilities. See crypto agility for the wire format and full algorithm table.
| Algorithm | Role | Standard |
|---|---|---|
| ML-KEM-768 | Key encapsulation (post-quantum KEM) | NIST FIPS 203 |
| ECDH P-256 | Classical key exchange (hybrid) | NIST SP 800-56A |
| HKDF-SHA256 | Key derivation from shared secrets | RFC 5869 |
| AES-256-GCM | Symmetric encryption + authentication | NIST SP 800-38D |
| ML-DSA-65 | Digital signatures (relay identity) | NIST FIPS 204 |
| Argon2id | Password gate on a transfer (hash, optional module) | RFC 9106 |
| SHA3-256 | CT log Merkle hashing | NIST FIPS 202 |
Hybrid key exchange
Authenticated transfers from the ParaSend web app use ML-KEM-768 and ECDH P-256 simultaneously. The shared secret is the concatenation of both, so breaking one provides no advantage. This protects against store-now-decrypt-later attacks while maintaining compatibility with classical infrastructure.
Pre-shared secret (PSS)
An optional password the sender and receiver agree out of band. The sender opens a session whose commitment is the SHA3-256 of that password; the receiver's client then sends the password itself to /v2/session/join, and the relay hashes it, compares it to the commitment and only then binds the receiver's public keys to the session, first join wins. What that buys is key binding: a third party who does not know the password cannot register their own keys as the receiver's.
What it does not buy is confidentiality against us. The password is not mixed into the key derivation: hkdf_aes_key in crypto-wasm/src/lib.rs takes the ML-KEM and ECDH shared secrets and nothing else. The receiver sends the password to the relay in plain text, so a relay running code we did not write reads it, and could bind its own keys whatever the commitment says. PSS raises the bar against key injection by an outsider; it is not a defence against the relay itself. It is a relay API feature, and the web app on this site does not use it.
Relay architecture
Encrypted blobs are stored in process memory, never written to disk. A relay restart destroys all blobs. No database, no filesystem writes.
Each blob is destroyed after the last read the link allows. The web app and the extensions delete the file after the first read on every plan. Through the API a paid link can allow more reads: up to 10 reads on Firm and 100 on Enterprise. Memory is zeroed immediately. There is no second chance to retrieve it.
Authenticated uploads from the ParaSend web app are padded to a fixed 5 MB block for DPI masking. A single block reveals no file size, type or content. A transfer that needs more than one block sends its chunk count in the clear, so the number of blocks is visible and the size can be placed within an order of magnitude (audit finding 5, accepted).
Each relay generates a post-quantum signing keypair on first boot. Registrations are signed and logged in the CT chain, and verified_since proves continuous identity.
What a compromised relay cannot do
/v1 signing ceremony the relay holds only ciphertext, never keysAuthentication
Paramant has no passwords. Humans authenticate with email and a time-based code from an authenticator app. Machines authenticate with long-lived API keys. What we do not have, we cannot leak.
Sign in at paramant.app or through a browser extension with your email address and the current 6-digit code from your authenticator app. Sessions last one hour. TOTP verification accepts SHA-256 and SHA-1 HMAC, so every standard authenticator app works; SHA-1 is the RFC 6238 default and several common apps offer nothing else. Compatible authenticator apps are listed at /help/authenticator-apps.
Scripts, SDK calls, SCADA integrations, and IoT devices authenticate with an API key in the X-Api-Key HTTP header. No TOTP, no sessions, no human interaction required. Suitable for headless automation.
No passwords. No password hashes. No security questions. No password reset tokens. Our database cannot leak a password because our database does not have the concept of one.
After TOTP verification, a 256-bit session token is issued as an httpOnly Secure SameSite=Lax cookie. Lax, not Strict, so an invited signer arriving from a link in their mail client is not bounced back to the login screen; a cross-site POST still carries no cookie. The token lives in Redis with a one-hour sliding expiry. API keys never touch the browser.
Rate limiting and replay protection
TOTP codes expire thirty seconds after issue. Each code is marked used the first time it is accepted, with an atomic single-use key in Redis. If Redis cannot be reached the sign-in is refused rather than waved through, so a code is never accepted without being marked. Sign-ins are rate-limited to five per IP per fifteen minutes. An email address is never rate-limited into a lockout: failed sign-ins are counted per address and cleared by a successful one, and past ten inside fifteen minutes the next attempt has to carry a proof-of-work rather than being refused. Nobody can lock you out of your account by guessing at your address.
Compared to alternatives
Most encrypted file transfer services use password authentication with optional two-factor as an upgrade. Paramant reverses this. TOTP is required for human access from day one. The surface for credential theft is close to zero because there is nothing to phish, stuff, or reset.
Setting up your authenticator → When to use API key vs TOTP → Backup codes →
Four-layer key verification
The relay distributes public keys. An attacker who controls the relay could serve wrong keys. These four layers prevent that:
| Layer | Mechanism | Protects against |
|---|---|---|
| 1 · TOFU | First-use fingerprint stored locally. Every subsequent fetch must match. | Key swap after first contact |
| 2 · Out-of-band | Both parties compute the same SHA-256 fingerprint and compare via phone/Signal/QR. | Relay MITM on first contact |
| 3 · PSS | The receiver proves a shared password before the relay will bind their keys to the session. It is not mixed into the encryption. | Key injection by an outsider. Not the relay itself, which reads the password on join |
| 4 · CT log + ML-DSA-65 | Key registrations are signed and appended to a Merkle chain. Inserting one after the fact contradicts every signed tree head issued before it, so it shows up to anyone who kept one. | Key injection, timestamp fraud |
Responsible disclosure
Report to privacy@paramant.app, encrypted with our PGP key if the details are sensitive. Do not open a public GitHub issue before coordinating.
PGP key fingerprint, verify before encrypting:09AA 452A 69DE F4A4 EB4B 72DC 5A34 D82F DAF3 54CD
What we ask
Do not publicly disclose before we have had a reasonable chance to fix. Do not access or modify data that does not belong to you. Do not run automated scans at volume that impacts service availability. Report to us first, not to third parties.
Scope
In scope: paramant.app, *.paramant.app, browser extensions published by us, API endpoints at docs/api.
Out of scope: social engineering, physical attacks, denial of service, third-party services (Resend, Hetzner, Bunny, Mollie).
Rewards
No monetary bounty at this time. Credit on our acknowledgements page, and priority access to new features.
What to do next
Every plan gets what this page describes. ParaSign Community and ParaSend Community cost €0, forever, with no card required; the paid plans buy higher limits, API access, a dedicated relay and an SLA, never better cryptography.
Customer transparency
Security is also about knowing what the vendor can and cannot do. The Trust & Verification page documents, in plain terms, how license-check works, what Paramant can see of your relay (and what it never can), how to verify your deployment, and which remote actions are possible versus structurally impossible. Each claim there is tagged as live today or planned, with links to the public protocol specifications.