Trust Center
Where Sigill.ai runs, how evidence is produced, which independent authorities anchor it, and what our proofs can and cannot establish.
Trust model
Sigill.ai is evidence infrastructure for digital records, and is structured as a hub. For proof of time, we relay requests to independent Timestamp Authorities under RFC 3161 and return their signed tokens — we do not run a TSA ourselves and have no plans to. For proof of origin, we produce PAdES seals for PDFs and CAdES detached signatures for non-PDF files, bound to an organisational certificate issued by an external Certificate Authority. The cryptographic trust rests on those external authorities, never on Sigill.ai alone. Every proof we return can be verified against the upstream authorities without us in the loop.
Data handling
For timestamping and verification, only a SHA hash crosses the network — the file stays on your machine. File sealing is the single exception. PAdES requires the PDF bytes to embed the signature, and CAdES requires the file bytes to produce the detached signature. Sealed outputs are processed in-memory; we retain the resulting signed artefact and its hash, not the unsigned input.
Hosting and sub-processors
Sigill.ai's primary application data plane runs in AWS eu-north-1, Stockholm. Customer evidence records, signing keys, audit logs, and database backups are hosted in that region. Limited account, billing, identity, and contact-form metadata may be processed by sub-processors outside that region — see the sub-processors page for the full list.
Standards and verification
Sigill.ai implements published IETF and ETSI standards rather than proprietary cryptographic schemes — principally RFC 3161 (timestamps), RFC 5126 / ETSI EN 319 122-1 (CAdES), ETSI EN 319 132-1 (PAdES), and the eIDAS Regulation for qualified services. Every timestamp we relay and every seal we produce can be verified independently with standard tools such as openssl ts -verify, Adobe Acrobat Reader, or the eIDAS DSS demo validator. See standards and verification model.
Key management
Signing keys are held in AWS KMS. Private-key material is non-extractable: it never appears in memory or on disk outside the KMS HSM boundary. Customers can also bring their own certificate, with the corresponding key generated and held in a tenant-scoped KMS key that only their tenant can sign with. Detail is in security architecture.
Tenant isolation
Sigill.ai is multi-tenant. Tenant isolation is enforced through database-resolved authorization, ORM-level tenant filters, and DTO-level capability boundaries. A valid token establishes identity; authorization is resolved against the database on every protected request rather than trusting role claims embedded in the token. Detail in security architecture.
Compliance posture
We state what is in place, partially in place, and planned. Marketing-grade phrasing is intentionally avoided.
Full statement at compliance posture.
What we can prove — and what we cannot
A cryptographic proof is only useful if its scope is stated honestly. Sigill.ai makes specific, narrow claims. Marketing-grade phrasing like "tamper-proof documents" is intentionally avoided.
Sigill.ai can prove
- That a specific byte-exact file existed by a specific moment in time, anchored to an independent Timestamp Authority's signing key.
- That a sealed PDF or detached CAdES signature was produced using a specific organisational certificate, and that the file bytes have not changed since.
- That a qualified-timestamp proof was issued by a TSA listed on the EU LOTL at the time of issuance.
- That a given hash was observed by Sigill.ai at a given time (account-scoped, via the tenant audit log).
Sigill.ai cannot prove
- That the contents of the file are factually true — only that they existed and have not changed.
- Who authored the file. A timestamp anchors a hash to a time, not to a human identity.
- That a file is "the original." Two parties may stamp identical bytes; both stamps are valid.
- The absence of a prior version. We can prove existence-by; we cannot prove non-existence-before.
- That a sealed PDF was approved by every individual mentioned inside it — a seal binds the document to the issuing organisation, not to its content's signatories.
Incident contact
Security issues, suspected key compromise, or suspected cross-tenant access: security@sigill.ai. Privacy and GDPR queries: raymond@sigill.ai. See responsible disclosure for scope and expected response times.
Read more
Document history
| Version | Date | Change |
|---|---|---|
| v1.0 | 2026-05-23 | Initial Trust Center publication. |
Changes that affect a contractual statement, sub-processor list, or stated control will be announced to active customers by email at least 30 days before they take effect.