E signature security checklist

A useful e signature security checklist is organised by when you can act. Before sending, you decide how strongly each signer is verified and what the invitation reveals. While the link is live, you protect it and watch for failures. After signing, you confirm the evidence is intact and store the file somewhere controlled. The signing service enforces a lot on its own, but it cannot choose the right check for you, spot a lookalike email address, or decide where the signed contract lives.

This checklist assumes the documents are ordinary business agreements. Regulated documents may have their own rules on identity and storage.

Before sending: verify identity at the right level

Start with your own account. Anyone who gets into it can create envelopes, void them and download signed documents. The Australian Cyber Security Centre calls multi-factor authentication one of the most effective ways to protect accounts against unauthorised access, so turn it on for the email account and the sign-in you use.

Then confirm each signer’s address from somewhere other than the thread you are replying to. The ACSC describes business email compromise as criminals using email to abuse trust in business processes, and a changed character in a counterparty’s address is the classic version. Every check that follows starts from that address.

Now choose the check by what the document is worth:

Email link only for low value documents to addresses you already deal with.

Emailed one-time code for contracts to personal addresses. The mutual NDA envelope uses it for both companies: a six digit code, valid ten minutes, redeemable once.

Access code where you will speak to the signer anyway. In the residential lease, the agent read each tenant’s code out by phone. The code is at least four characters and the service never returns it, so it only works if it travels by a different route than the link.

The trade-offs between the three are set out in full in how to verify a signer’s identity.

Finally, write a plain title and message. When a code is set, the page a signer reaches before passing it shows the title and the recipient’s name and email, and nothing about the document. That page is visible to whoever holds the link, and the message is visible to whoever reads the invitation email.

While it is live: protect the link

A signing link is a credential. The invitation says so in its footer: the link is personal and should not be forwarded. Three habits keep it that way.

Resend, never forward. Resend issues the signer a new link, so the one in the old email stops working. It also clears a lockout and records a resent event.

Read failures. The audit trail records each failed verification with its time and IP address. Five wrong codes lock that recipient for fifteen minutes. One lockout is usually a signer mistyping. Several, or a lockout on a signer who says they never tried, means someone else may have the link, and the fix is to void and send a new envelope.

Void mistakes at once. Voiding expires every outstanding link, records a voided event and emails the people still holding a live link. Anyone opening one then sees that the document was withdrawn by the sender.

Guessing is throttled per recipient. Five failed access code or one-time code attempts lock that recipient for 15 minutes, at most five one-time codes are issued per ten minutes, codes are stored as salted scrypt hashes, and a signing session lasts 30 minutes before the check is repeated. NIST SP 800-63B requires a verifier to limit consecutive failed attempts on one account to no more than 100, so the lockout here is far stricter, and it applies per recipient.

Links also end on their own. Every envelope expires 30 days after creation, and an expired link returns a message that the signing request has expired.

In person signing deserves care. When you host a signer’s turn from the status page, as the lender does in the loan agreement envelope, the emailed check is waived for that session and the event records who hosted it. Use it only with the signer in front of you.

After signing: check the certificate

The certificate of completion is the quickest security review. For each signer, confirm the identity method is the one you chose, printed as Email link, Email link + access code, or Email link + emailed one-time code. Check the IP address is plausible and the consent timestamp sits just before the signing time.

Then read the certification line. PAdES-SHA256-DocMDP means the PDF was certified. The words “with RFC 3161 timestamp” appear only when a timestamp authority attached a token, and in the current setup none does. Do not describe a signed file as independently timestamped.

Do not compare the certificate’s two document hashes with a hash of the file you downloaded. “Document hash as sent” is the uploaded file, and “Fully signed hash” is the stamped file before certification, so neither will match the final download.

Verify the file itself

Open the signed PDF in a reader that shows signatures. Certification at DocMDP P=1 means no changes are permitted after certification, so an edited copy shows as altered. The steps for common readers are in how to check if a PDF is signed. If a counterparty later sends you back a copy, open that one too rather than assuming it is the file they received, because a certified file only protects you when someone actually checks it.

Certification never degrades quietly. If it fails, the envelope is marked failed and the sender is emailed, rather than an uncertified PDF being sent out.

Audit the trail

The status page walks the audit trail and shows either “Hash chain verified” or “Chain broken at event n”. Each row stores a sha256 hash computed over the event and the previous row’s hash, so altering one row breaks every link after it. SHA-256 is one of the hash algorithms specified in FIPS 180-4, whose stated purpose is detecting whether a message has changed. The hash chain page explains the mechanism.

The trail also settles who typed what. A sender cannot pre-fill any field, so every typed value is entered by the recipient it belongs to, under that recipient’s own signing event. In the vehicle sale envelope, the odometer reading sits in the seller’s field and the amount paid in the buyer’s, so neither side can later claim the other wrote it.

Know the gap: downloads are not recorded in the trail. Who opens the signed file later is invisible to it.

Store the file

The completion email sends the certified PDF to every signer and the sender. Save it with the certificate in storage with access control and a backup, not in a personal inbox. APP 11 asks for reasonable steps, technical and organisational, to protect personal information from misuse, loss and unauthorised access, and for it to be destroyed or de-identified once no longer needed unless a law requires keeping it.

The sixteen checks below put all of this in order, from before you send to after you file.

Common mistakes

Pasting the access code into the covering email. Both halves then sit in one inbox.

Forwarding the invitation to a signer who lost it. Two live copies of a credential.

Trusting the reply-to address. Confirm addresses out of band.

Ignoring a lockout. Treat an unexpected one as a possible compromise.

Calling the PDF timestamped. It is certified, not timestamped.

Leaving signed files in email. Every recipient’s inbox is now part of your storage.

Build it

The e-sign security page describes what the service enforces. Access codes and one-time codes are salted scrypt hashes compared in constant time. A verified signer’s session lasts 30 minutes. The trail records 18 event types on a sha256 hash chain, and the finished PDF is certified at DocMDP P=1. There is no approver or cc role, and the expiry is fixed at 30 days. The e-signature tutorial covers setting identity checks when you add each signer.