Building a Security-First E-Signature Platform

When we founded Siglot.ai, we made a decision that shaped everything: security wouldn't be an afterthought. We'd build it into the architecture from the start. Here's how we did it.

Threat Modeling First

Before writing a line of code, we mapped out our threat model. E-signature platforms face unique challenges:

Encryption Everywhere

All documents are encrypted at rest using AES-256. But we went further with envelope encryption: each document has its own unique encryption key, which is itself encrypted with a master key stored in a hardware security module (HSM).

This means even if an attacker compromised our database, they'd get encrypted blobs that are computationally infeasible to decrypt.

In transit, everything uses TLS 1.3 with strong cipher suites. We enforce HSTS and use certificate pinning in our mobile apps.

Zero-Trust Architecture

We assume every component could be compromised. Our services communicate over mTLS, even within our private network. Each service has the minimum permissions needed to function.

Document processing happens in isolated containers that are destroyed after each job. There's no persistent state where sensitive data could leak.

Cryptographic Signatures

When a document is signed, we create a SHA-256 hash of the document content and the signature data. This hash is then signed with our platform key and embedded in the document.

Any modification to the document, even a single byte, changes the hash and breaks the signature. This provides tamper-evident sealing that can be independently verified.

Audit Trail Integrity

Our audit logs use a hash chain, similar to a blockchain. Each log entry includes a hash of the previous entry, creating an immutable sequence. Any attempt to modify or delete a log entry would break the chain.

Logs are written to append-only storage with separate access controls from the application. Even our engineers can't modify them.

Access Control

We implement attribute-based access control (ABAC) that considers user role, document ownership, organization membership, and contextual factors like IP address and time of day.

Every access decision is logged, creating a complete record of who accessed what and when.

Incident Response

We assume breaches will happen and plan accordingly. Our incident response playbooks are tested quarterly. We have automated alerting for anomalous behavior, and our security team is on-call 24/7.

We also maintain relationships with external security researchers through our bug bounty program.

Compliance as Code

Our compliance requirements (SOC 2, GDPR, HIPAA) are encoded as automated tests that run continuously. If a code change would violate a compliance requirement, the build fails.

This approach has helped us maintain our SOC 2 Type II certification with zero findings.

The Trade-offs

Security-first architecture isn't free. Some features take longer to build because of the additional constraints. Performance can be impacted by encryption overhead. But for a platform handling legally binding documents, there's no acceptable alternative.

Our customers trust us with their most important agreements. That trust is the foundation of our business, and we protect it with every architectural decision we make.