Security

Encryption in transit

All traffic between a browser and eSoppari is encrypted. The service accepts TLS 1.2 and TLS 1.3 and negotiates the highest version the client supports, with a cipher suite list restricted to modern authenticated-encryption suites. HTTP Strict Transport Security is enforced across the service and its subdomains.

Where the data is held

Documents, signatures and personal data are hosted in the European Union. What the service stores, it stores there.

Strong identification of every signer

Signers are identified through national electronic identification schemes: Finnish bank credentials, Swedish and Norwegian BankID, and MitID. Each of these identifies a person at the eIDAS High assurance level.

eSoppari has no weaker alternative. There is no email-link or one-time-code signing tier to fall back on, so no signature in the system rests on a weaker identification than the one described here. Identification is carried out through an electronic identification broker that connects the service to these schemes.

Custody of the signing key

The organisational signing key is held in a cloud hardware security module certified to FIPS 140-2 Level 3. The key is generated inside the module and never leaves it; the service asks the module to sign and receives the signature back. There is no exportable copy to lose.

Timestamps

Every signature carries an RFC 3161 timestamp issued by an EU-qualified timestamping authority. The timestamp establishes that the signature existed at a given moment, independently of any clock we control.

Long-term validity

Each finished document is a PAdES-B-LT PDF: the data needed to validate its signatures — certificates and revocation information — is embedded in the file itself, and can be renewed over time so that the document stays verifiable as the underlying certificates age.

The practical consequence is that a document can be checked years later, offline, in any PAdES-aware PDF reader. Verification does not require our servers to answer, or our company to exist.

The signing-event history

Every signing request keeps a full signing-event history: who acted, what they did and when. Sent, opened, authenticated, signed, declined, reminded and expired are all recorded, each with a timestamp and the technical evidence collected at that moment. The history is read-only and is retained for as long as the request itself.

Separation between customers

Each organisation's data is isolated from every other organisation's, and that isolation is enforced structurally in the database rather than by application code remembering to filter. A query that arrives without an organisation context returns nothing.