How a Stria signature is built to hold up

Electronic-signature law is technology-neutral: it asks for intent, consent, attribution, integrity, and a record you can retain and reproduce. Here is the element-by-element mapping to the mechanism behind each one — and what we do not claim.

The elements, mapped

• Intent to sign — the signer ticks a fixed consent statement and confirms; opening a link records nothing. The sentence shown is the sentence stored.
• Consent to transact electronically — the same statement names the ESIGN Act and UETA and is retained with the signature.
• Attribution — a one-time code emailed to the signer (10-minute expiry, 5 attempts, single-use) stored only as an HMAC-SHA-256 digest under a server-side pepper.
• Integrity — a SHA-256 hash of exactly what was approved, on an append-only record that database triggers refuse to edit or delete.
• Retention and reproduction — the full request-and-approval trail exports to a print-ready PDF certificate.

What a signed record contains

Signer name, verified email, the verbatim consent text, the version number, the content hash, the server-observed IP address, the device user-agent, and a server-clock timestamp.

Which eIDAS tier this is

A Stria sign-off is a standard electronic signature (SES) with a full evidence trail. It is not an advanced (AES) signature — we do not issue signer-controlled signature-creation data — and not a qualified (QES) signature, the only tier that carries automatic handwritten-signature equivalence under eIDAS Art. 25(2).

What Stria does not claim

No identity proofing against government documents, no qualified electronic timestamps, no certificate-based signature embedded in the PDF, and no coverage of transactions ESIGN and UETA carve out. SOC 2 readiness is in progress, not certified. This is not legal advice.

See also Security, the Trust Center, and the trust roadmap.