How Secure Forms encryption works

When you create a form, your browser derives a long-lived identity — a hybrid of ML-KEM-1024 and X25519, combined with HKDF-SHA-256 — from your unlocked account. The public half is served with the form; the secret half is wrapped by your account key and stored so only you can recover it.

When a respondent submits, their browser serialises the answers into one blob and seals it to that public identity using the open-source @shieldfive/crypto core. Only ciphertext is sent to ShieldFive. The post-quantum half (ML-KEM) is always on — it is not a paid tier. The form’s questions are separately encrypted with a key that lives in the link, so the questions aren’t readable on our servers either.

We are honest about the limits of any hosted, browser-delivered tool. The server can see: the size of each sealed response, the times a form was created, opened, and submitted to, and the IP address that connected (hashed for abuse-prevention, never stored raw). It also holds the encrypted question labels, which it cannot read, and it delivers the JavaScript that runs the encryption.

What the server cannot see: the answers, the questions, or your secret keys. Those stay on the devices of your respondents and you. There is no readable copy of any response to leak, sell, or hand over.

Because the encryption code — and the public key respondents seal to — are served by us each time the page loads, a compromise of ShieldFive could in principle serve malicious code or a substituted key. We reduce that risk with a strict Content-Security-Policy and no third-party scripts on the form and inbox pages, and the crypto core is open source so it can be reviewed independently. This is the honest ceiling of any web-delivered end-to-end tool. Our claim is “encrypted in the browser, ciphertext at rest” — not that no server could ever be subverted.

Each form carries a response cap, an optional close date, and per-IP rate limits on the public submit endpoint, so a shared link can’t be turned into an abusive write endpoint. The submit route recomputes an integrity proof over the received ciphertext before it is stored, so a corrupted body is rejected rather than persisted.

On a paid seat, your firm’s decryption identity is sealed to each member’s account keys, so colleagues share one response inbox without ever sharing personal keys. Removing a member blocks new access, but a member who already cached the firm key can still read responses received before removal until the firm identity is rotated — and rotation does not re-encrypt already-received responses.

Ciphertext and metadata are stored in the EU, and a GDPR data-processing agreement is included on every seat. There is no third-party tracking on the form or inbox pages. For the full company security posture, see /security.