Building defensible e-signing software is hard because it is an evidence-engineering problem that mixes law, cryptography, standards, and production-grade systems engineering. You are not just capturing a click, you are producing a reproducible record that can survive a legal challenge years later. The hardest parts show up in six places: legal admissibility, cryptography and key management, document format handling, identity proofing, audit trail durability, and operational reliability under real-world load.
TL;DR:
- ESIGN requires electronic records to remain accessible and reproducible; archive signed files outside production databases and preserve metadata needed to reconstruct each signing event.
- Capture certificate chains and revocation records when signing, then apply a trusted timestamp; later expiration will not undermine a signature that was valid then.
- Email links provide the weakest identity evidence; government eID or knowledge based authentication better suits high value or regulated agreements.
- Make webhook handling idempotent and use exponential backoff, because duplicate deliveries and retry storms can corrupt downstream signing states during outages.
- Embed an API when contracts carry financial or regulatory risk, or no engineer can maintain PKI; build internally only with long term ownership capacity.
What an e-signing system actually has to do
A simple web form can capture a checkbox and call it a signature. A defensible e-signing system has to produce an evidence package that a court, auditor, or counterparty can inspect and trust on its own, long after the transaction closed. That distinction drives almost every engineering decision downstream.
The capability list is longer than most teams expect going in:
- Capture signer intent and identity in a way that maps to a specific document version
- Authenticate the signer at a level appropriate to the deal's risk
- Generate cryptographic signature values tied to document hashes
- Comply with standards for PDF embedding and long-term validation
- Store evidence immutably, with timestamps and certificate data intact
- Support verification years after signing, even if certificates expire
Each of those areas has its own failure modes, and they interact. A retention requirement forces a storage decision. A storage decision affects how you handle certificate revocation later. None of this is optional once a signed document matters to someone.
Legal constraints that force engineering trade-offs
US federal law under ESIGN is technology-neutral. It does not mandate a specific signing method, and it generally does not deny legal effect to a record just because it is electronic. But it does require that records be retained and reproducible for later reference, and it allows agencies to set performance standards for accuracy and integrity. That one clause turns into a pile of engineering requirements.
Translating the statute into a build plan means:
- Choosing file formats that remain readable and verifiable for years
- Keeping archival copies accessible independent of your production database
- Logging enough metadata to reconstruct the signing event on demand
- Treating certified timestamps as part of the record, not an afterthought
Retention is not a storage afterthought, it is a legal requirement baked into the statute itself, per Title 15 of the US Code. Teams that treat retention as a database backup problem tend to discover gaps only when a dispute forces them to produce a specific record years later.
Cryptography and PKI behind non-repudiation
Underneath every signed document is a chain of cryptographic operations. The system hashes the document, signs that hash with a private key, and produces a signature value tied to a certificate. Verifying the signature later means checking that chain end to end, not just confirming a name appears on a page.
The operational burden lives in a few recurring tasks:
- Managing certificate authorities and validating the full certificate chain
- Checking revocation status through OCSP or CRL lookups at signing time
- Handling the case where a certificate has since expired or been revoked
- Applying trusted timestamps so validity can be anchored to the signing moment, not the verification moment
Legal and technical guidance both stress that revocation information and certificate chains need to be captured when the document is signed, not fetched later when an audit happens, according to ETSI's PAdES guidance. A certificate that has since expired should not invalidate a signature that was valid at signing time, but only if you anchored that validity with a timestamp in the first place.
Document formats and standards for long-term validation
PDF signing is more involved than dropping an image of a signature onto a page. A valid signature lives inside the PDF's byte range and signature dictionary, and small differences in how a PDF renderer handles fonts or layout can create verification mismatches that look like tampering when they are actually rendering quirks.
Standards bodies address this through PAdES, the ETSI profile for PDF advanced electronic signatures. PAdES levels define what has to be embedded for long-term validation (LTV), including timestamps, revocation data, and certificate chains, per ETSI EN 319 142-2. Planning for LTV from day one, rather than bolting it on later, changes how you:
- Structure signature dictionaries and DocMDP permissions
- Decide what gets exported alongside the signed file
- Test cross-reader validation across different PDF viewers
Developer tooling confirms how much this varies in practice: PDF signature APIs document separate behaviors for PAdES versus PKCS7 formats and flag limitations like maximum file size and unsupported encrypted PDFs, according to Adobe's PDF Services documentation. Those limitations become product decisions you have to communicate to customers.
Identity checks and how much legal weight they carry
Every authentication method you offer carries a different evidence strength, and the right choice depends on what is at stake in the document. Email links are low friction and low assurance. Government eID and knowledge-based authentication (KBA) sit at the high end, with SMS OTP, third-party OAuth, and two-factor approaches filling the middle.
A practical way to sort them:
- Email-only access: fastest for the signer, weakest evidence of identity
- SMS or app-based OTP: moderate assurance, adds a second channel to log
- OAuth through an established identity provider: useful when the signer already has a trusted account
- KBA or government eID: strongest assurance, appropriate for high-value or regulated agreements
Higher-value contracts and regulated industries generally warrant the stronger end of that list, since the signature's evidentiary value needs to match the size of the risk if the agreement is ever disputed.
Pro Tip: Match authentication strength to deal risk, not to what is easiest to implement first. A $5,000 order form and a $5 million MSA should not share the same identity bar.
Audit trails, timestamps, and the fault modes to design against
The audit trail is the actual evidence package. If it is incomplete, the cryptographic signature behind it loses most of its practical value, since legal practitioners treat an e-signature system as a package of proof, not just a mark on a page, according to Keough Law's analysis of e-signature validity. A thorough package needs:
- Document hashes and the final signature values
- Signer metadata, including IP address and user agent
- Delivery and viewing receipts timestamped at each step
- Proof of a trusted timestamp applied at signing
- The full certificate chain used to validate the signature
Common failure modes include lost logs, clock drift between servers, and missing revocation data that should have been captured at signing time. Mitigations are straightforward in principle: immutable storage, signed backups, and timestamping that does not depend on your own servers' clocks. Verification testing should simulate dispute scenarios directly, pulling an old evidence package and confirming it still validates cleanly against the original certificate chain. Our own breakdown of audit trail components covers what belongs in that package in more detail.
Production engineering: rendering, webhooks, scale, and monitoring
Prototypes tend to work fine in a demo and fail quietly in production. Document rendering is the first place this shows up: font substitution, layout shifts across PDF viewers, and inconsistent signature field placement can all make a document look different to the signer than it does to your backend. Treat rendering as a first-class dependency, not a cosmetic detail, and test across the actual PDF libraries and devices your signers use.
Webhook reliability is the second recurring source of pain. Delivery failures, duplicate deliveries, and retry storms during an outage can corrupt downstream state if you have not built for them.
- Use idempotency keys so a retried webhook never double-processes an event
- Apply exponential backoff on retries instead of fixed intervals
- Alert on delivery failure rates, not just on total request volume
Cryptographic operations add their own latency, since certificate validation and signature generation are computational work that slows under load. Batching signature requests and running signing operations in the background, rather than inline with the user request, keeps response times predictable as volume grows.
Pro Tip: Build a dashboard that tracks webhook delivery success rate separately from signing success rate. The two fail independently and hide different problems.
Choosing between embedded, hosted, or server-side signing
The integration pattern you choose shapes both security and user experience. Embedded iframe or redirect flows keep signers inside your product but add complexity around styling and session handoff. Hosted signing pages are the fastest to stand up but send signers off your domain. Server-side signing APIs give you the most control but push more compliance responsibility onto your own infrastructure.
Whichever pattern you pick, plan for these API features before you commit:
- A signature request URL that can be generated and revoked programmatically
- Reliable callback or webhook events for completion and failure states
- Idempotency support so retries do not create duplicate signing sessions
- Options for long-term validation data, not just a basic signature
Before going live, an integration should pass sandbox tests for malformed documents, expired signing links, and webhook retries under simulated failure. Our developer guide to implementing e-signing walks through these integration choices in more depth.
A practitioner's checklist for building or embedding e-signing
Before writing code, decide what you will log, how you will package evidence, and what retention and export formats you need to support. At minimum: document hashes, signer metadata, delivery receipts, trusted timestamps, and full certificate chains, stored immutably and tested against simulated disputes. A smart data retention policy is worth reviewing early, since retention rules shape your storage architecture from day one.
Whether to build or embed usually comes down to three factors: how fast you need to ship, how much legal risk your contracts carry, and whether you want ongoing maintenance of cryptographic infrastructure on your own team.
A practical read on build versus embed
Most teams overestimate how much of this they can skip. The legal and cryptographic requirements are the same whether you build or embed, so the real decision is who maintains them over time.
If your contracts carry real financial or regulatory risk, or your team has no one dedicated to PKI maintenance and standards tracking, embedding a developer API is usually the faster and safer path. If signing is central to your product and you have the engineering bandwidth to own certificate management long term, building in-house can make sense. Few early-stage teams actually have that bandwidth to spare.
— Alex
How Formable handles the hard parts for you
We offer an embedded e-signing API to simplify certificate management, revocation checks, and audit trail architecture for teams. Our embedded e-signing API gives developers a signature request flow with webhook callbacks and audit trail generation built in, and it sits alongside our redlining API for teams that need negotiation before signing.
Beyond signing, we offer:
- A contract creator that combines templates with generative AI
- AI contract review that flags risk and missing clauses automatically
- Browser-native contract negotiation for redlining before signature
Our security and legal posture page covers how we structure evidence packages for defensibility. If you want to see pricing for teams or developers, check our plans or our developer and API pricing.
FAQ
What are the advantages and disadvantages of electronic signatures?
Electronic signatures speed up signing and cut paper handling, but they shift the burden onto the system's evidence package: identity proofing, audit trails, and certificate management all need to be done correctly for the signature to hold up if challenged. Weak implementations without proper audit trails risk losing enforceability, according to legal analysis on e-signature validity.
Is DocuSign easy to set up?
Setting up a hosted e-signature product is generally straightforward for simple documents, since most providers offer templates and guided signing flows. Complexity increases once you need custom branding, embedded signing inside your own app, or specific long-term validation requirements for regulated documents.
Are e-signatures legally binding?
Yes, in the United States electronic signatures are generally legally binding under ESIGN, which does not deny legal effect to a record solely because it is electronic. Enforceability still depends on proper retention, reproducibility, and an audit trail that can prove signer identity and document integrity.
How do you do electronic signing?
Electronic signing involves capturing signer intent, authenticating the signer at an appropriate assurance level, hashing the document, and generating a cryptographic signature value tied to a certificate chain. The resulting evidence package, including timestamps and signer metadata, needs to be stored in a way that supports verification years later.
What makes building e-signing software from scratch risky?
Building from scratch means owning certificate management, revocation checking, standards compliance like PAdES, and audit trail architecture indefinitely, which is a significant ongoing engineering commitment. Many teams choose to embed an existing e-signing API instead, trading some control for faster time to market and lower maintenance load.
