Security

What stands behind every signature

From the signer's eID to the key in the HSM to the timestamp in the file.

  1. Signer uses a strong eID
  2. Seal key in a cloud HSM
  3. EU-qualified timestamp RFC 3161
  4. Validation data embedded PAdES-B-LT

The mechanisms behind it

  • Custody of the seal key

    The seal key is generated inside a cloud hardware security module and never leaves it.

  • Long-term validity

    Each finished document is a PAdES-B-LT PDF, with its certificates and revocation data travelling inside the file.

    When long-term validity is enabled for a request, the file is re-stamped before that data lapses (PAdES-B-LTA).

  • Signed documents cannot be quietly destroyed

    Signed PDFs live in versioned, locked storage.

  • Encryption in transit

    All traffic is encrypted with modern authenticated-encryption suites, and HSTS covers the service and its subdomains.

    TLS 1.2 / 1.3 only

  • Where the data is held

    Hosted in the European Union, encrypted at rest, and no personal data is transferred outside the EEA.

  • Strong identification, only

    Every signer uses a strong national eID, with no email-link or one-time-code tier to fall back on.

  • Independent timestamps

    Every signature is timestamped by an EU-qualified authority, independent of any clock we control.

    RFC 3161

  • Access control

    Every sign-in to the admin portal requires multi-factor authentication, a role change applies from that user's next request, and downloads and previews of documents and invoices by your users or our operators are logged.

  • The signing-event history

    Sent, signed, declined, expired, cancelled: who acted and when, read-only, with the evidence collected at that moment.

  • An append-only audit register

    Audit rows carry hashes computed by the database, and triggers refuse any update or delete.

  • Separation between customers

    Each organisation's data is isolated structurally in the database, and a query without an organisation context is refused.

Data protection

Retention windows are yours to control, and erasure means hard deletion.

retention window closes erased admins told legal hold: erasure blocked Art. 17 workbench erased receipted signup: DPA accepted time

  1. Agreed at signup Art. 28

    A Data Processing Agreement is accepted when you sign up.

  2. Retention per document category

    Pre-filled with the statutory defaults for your country where they exist, and yours to change.

  3. Hard deletion on request Art. 17

    A workbench itemises the scope before you confirm, and you can download the signed document first.

  4. Legal holds block erasure

    A legal hold blocks erasure, and every completed erasure is receipted in the activity log.

  5. Erased when the window closes

    The record is erased automatically, and your admins are told.

Documents for your procurement team

Published and versioned. The Terms and the DPA are accepted at signup, with the time and version of acceptance recorded.

How it holds up in law

Security is one half of the answer. The other is what an eSoppari signature is under eIDAS, and what it is not (yet).

Legal validity Get started
  • TLS 1.2 / 1.3
  • RFC 3161
  • PAdES-B-LT
  • GDPR Art. 28