Security

How this is built, and what it does not protect against.

Cursiv holds other people’s agreements. This page describes the arrangement in enough detail to be checked, and ends with the part most security pages leave out.

Getting in

Passwords are hashed with a memory-hard function and never stored or logged in the clear.
Email ownership must be confirmed before an account can sign in at all.
Time-based one-time-password two-factor authentication, with recovery codes.
Sign-in attempts are throttled per account and per address, and every attempt is recorded.
Sessions are a single opaque, HTTP-only cookie. No token is placed in a URL or in browser storage.

Where documents live

Object storage with encryption at rest, and TLS on every connection.
Every read is scoped to the workspace that owns the document; there is no cross-workspace path in the query layer.
Signing links carry 256 bits of entropy derived from a server-side secret, and only their keyed hash is stored — a database compromise alone yields no working link.
Links are revoked on void, decline, completion and reassignment.
Retention purges working copies on the schedule the workspace sets, keeping the sealed record.

Proving nothing changed

Every event is entered into a hash chain, each link committing to the one before it.
The completed document is sealed with a keyed MAC over the exact bytes stored.
The Certificate of Completion carries the document digest, the chain head and the seal.
Verification recomputes the chain rather than trusting a stored flag, so a tampered row is detected rather than reported as intact.

Not having to trust us

Every completed agreement is published to a public, append-only Merkle log (RFC 6962).
The log signs each published state of itself with an Ed25519 key anyone can fetch and pin.
It can prove a record is included, and that no earlier state was rewritten, using arithmetic rather than our assurance.
The verifier is about two hundred lines of plain JavaScript, shares no code with what produced your document, and holds no secret.
Entries are blinded: no document, name or email address is published — only a hash.

What we do not have, and what this does not do

No SOC 2 or ISO 27001 certification. We have not been audited against either. If your procurement process requires one, we do not meet it today and we would rather you learned that here than in week three.
No advanced electronic signature. Where a statute requires a signature, section 13(1) of ECTA requires an accredited advanced electronic signature and we are not accredited. The legal guide sets out exactly when that matters.
The seal proves integrity, not identity. It shows a document has not changed since completion. It does not prove who was at the keyboard — that is what authentication, the audit trail and the disclosure record are for, and their strength depends on which options you turned on.
The seal is ours to verify. Anyone who could verify it could also forge it, because it takes the same secret either way. That is the ceiling every e-signature platform sits under and it is why the transparency log exists — that part a stranger can check without us.
Not all data stays in South Africa. Email and document analysis are handled by processors abroad. See sub-processors.
No formal penetration test has been published. When one is commissioned we will say who did it and when.
No contractual uptime guarantee on standard terms. We will agree one in writing if you need it.

What we do, and what we do not

Every capability this platform has — and every one it does not yet have — is published as a contract rather than described in prose. Each entry carries its state, whether it needs configuration before it works, and the reason when it is unavailable. It is generated from the same registry the product itself reads, so a page here cannot claim something the software does not do: the test suite fails when the two disagree.

Read it at /api/v1/capabilities — no account needed. Diff it between releases to see exactly what changed.

Reporting something

Our vulnerability disclosure policy says where to send it, what we promise in return, and that we will not pursue you for good-faith research. Machine-readable at /.well-known/security.txt.