Loading...
AcadiaSign eSignature Legality Guide
Experience secure, legally-binding electronic signatures today.
Sign up for freeAn electronic signature is easy to display. Building a useful and trustworthy record around it is the harder - and more important - part.
When an agreement is questioned, the relevant questions are not limited to "Is there a signature on the page?" They can also include:
AcadiaSign combines an electronic-signature workflow with transaction records and document-integrity controls intended to help organizations answer those questions. These controls can provide supporting evidence. They do not, by themselves, decide whether a signature, document, or agreement is valid, enforceable, authentic, or admissible.
Legal and jurisdictional scope:This U.S.-focused article provides general product information and a limited comparison with European Union terminology. It is not legal advice, does not create an attorney-client relationship, and provides no warranty that AcadiaSign satisfies every legal, regulatory, evidentiary, privacy, security, or retention requirement. AcadiaSign is not represented here as a certification authority, qualified trust service provider, remote-online-notarization provider, eIDAS Qualified Electronic Signature service, or qualified electronic timestamp service. Organizations should obtain advice from qualified counsel for their documents, disclosures, authentication requirements, jurisdictions, retention schedules, and operating procedures.
Electronic-signature laws are generally technology-neutral, but they do not make every click or signature image automatically enforceable.
The federal Electronic Signatures in Global and National Commerce Act (ESIGN), 15 U.S.C. Section 7001 generally prevents a signature, contract, or record from being denied legal effect solely because it is electronic. It does not remove other requirements imposed by contract law, evidence law, consumer-protection law, or transaction-specific statutes.
The Uniform Electronic Transactions Act (UETA) supplies a state-law framework for electronic records and signatures where enacted. State treatment must be checked using current law. For example:
The effect and attribution of an electronic signature remain factual questions. UETA Section 9 and enacted state versions look to whether the signature was the person's act, the efficacy of any security procedure, and the surrounding context and circumstances. AcadiaSign controls may contribute evidence relevant to that analysis, but they do not resolve it conclusively.
ESIGN's special consumer-consent process does not automatically apply to every consumer transaction. Under 15 U.S.C. Section 7001(c), it applies when another statute, regulation, or rule requires transaction information to be provided or made available to a consumer in writing.
When that provision applies, the person providing the electronic record may need to address matters such as:
The AcadiaSign consent dialog is not a substitute for all transaction-specific consumer disclosures. The sending organization remains responsible for determining whether those requirements apply and for supplying any disclosures or procedures that the current workflow does not provide.
Where ESIGN Section 101(d) applies, retaining a record is not only a matter of keeping bytes for a chosen number of years. The retained electronic record must accurately reflect the information in the original contract or record, remain accessible to entitled persons for the legally required period, and be capable of accurate reproduction for later reference.
Hashing and Object Lock may support integrity and preservation, but they do not independently establish that every accessibility, reproducibility, duration, or transaction-specific retention requirement has been met.
15 U.S.C. Section 7003 provides that Section 7001 does not apply to specified categories, including certain laws governing wills and testamentary trusts, family-law matters, portions of the Uniform Commercial Code, court documents, utility termination notices, specified primary-residence credit or tenancy notices, specified insurance termination notices, certain product-recall or material-failure notices involving health or safety, and documents accompanying hazardous-material transport.
This is not the same as saying that every document in those categories can never be executed or delivered electronically. Other federal or state law may authorize, prohibit, or separately regulate electronic execution. Other transactions - including real-estate documents, regulated filings, notarized instruments, documents requiring witnesses, and records requiring paper originals - may also have additional jurisdiction-specific formalities.
Under the current consolidated eIDAS Regulation, an electronic signature should not be denied legal effect or admissibility solely because it is electronic or does not meet the requirements for a qualified electronic signature. eIDAS separately defines advanced and qualified electronic signatures and qualified trust services.
AcadiaSign's current workflow must not be represented as an eIDAS Qualified Electronic Signature, a qualified certificate service, or a qualified electronic timestamp service. This article does not assess compliance in the European Union, United Kingdom, Canada, Australia, or any other non-U.S. jurisdiction.
In the standard email-signing interface, AcadiaSign presents an electronic-signature consent dialog. The signer must actively select a checkbox before the interface continues. The dialog explains that the signer will review and sign electronically and receive and retain an electronic copy.
Submission creates a consent record associated with the specified recipient and envelope. The record can include:
This record should be described as evidence that a consent action was submitted in the standard interface. It should not be described as independent proof of the signer's identity, proof that every required disclosure was supplied, or a universal backend prerequisite for every completion path.
The current consent record does not store the exact disclosure text, a disclosure version, or a checksum of the disclosure displayed at that moment. The current in-person signing path should not be included in claims that consent is always persisted.
Consent to use electronic records is also not identical to intent to sign a particular record. Assigned-field responses, signature application, and signing-completion activity may provide circumstantial evidence of intent, but AcadiaSign should not claim to create a separate conclusive intent record.
AcadiaSign combines several controls that may contribute evidence of attribution.
Each recipient can receive an individual access token associated with the envelope and recipient record. The server resolves protected signing activity through that token and the related recipient.
An access token expires when the envelope has a configured expiration. Because envelope expiration is optional, the links should not be described as universally expiring.
When field responses are submitted, the server resolves the recipient from the signing token and accepts only fields assigned to that recipient. This is a server-enforced document-association control.
The active signing interface also checks that the recipient's required fields have values before it calls final completion. That required-field check occurs in the client interface; the final completion action does not independently repeat it. Public content should therefore distinguish server-enforced field ownership from the interface's required-field check.
AcadiaSign includes an email one-time-code step in standard signing flows. The workflow uses temporary Redis storage with an expiry and maintains a database session containing status, request time, attempts, and resolution information. It can record request, failed-code, lockout, and successful-code events.
The current server action does not independently bind the requested destination address to the recipient email stored for the envelope. Until that trust-boundary check is implemented, this capability should be treated only as supporting workflow activity, not recipient verification or reliable evidence that the intended recipient controlled the destination. Public content must not say that an email code "proves who signed." Expired Redis entries can also appear as a general not-found or failed result rather than a distinct expiry event, so audit descriptions should not promise a separate expiry event in every case.
Eligible internal signers can be verified through Microsoft Entra ID when the organization has configured and enabled that option. The policy checks the authenticated user, organization membership, recipient email, tenant, linked Microsoft subject, plan entitlement, configuration, and freshness of the authentication evidence before treating the work-account step as satisfied.
The reviewed implementation does not provide SMS OTP, knowledge-based authentication, or a separately entered recipient access code. A token embedded in a recipient URL should not be relabeled as an access-code authentication method.
These controls may help associate activity with an intended recipient. Higher-risk transactions may require stronger identity proofing, regulated trust services, witnesses, notarization, remote online notarization, or other controls. AcadiaSign does not currently provide a notarization or remote-online-notarization workflow.
AcadiaSign stores envelope and recipient events produced by multiple workflow surfaces. Depending on the path, actual records can include:
Depending on the event, a record may include:
Some additional event names exist in the database schema without a corresponding producer in the reviewed application flow. Public copy should not promise universal envelope-expiration, signing-session-expiration, mailbox-delivery, bounce, creation, or voiding events unless those producers are implemented and verified.
Email-provider acceptance is also not the same as confirmed mailbox delivery. Delivery language should distinguish a send request accepted by a provider from a recipient mailbox-delivery confirmation.
Corrections are maintained separately from the underlying transaction history. The correction workflow can preserve a reason, before-and-after snapshots, public and private summaries, the correcting user, and a correction event. Completed recipient data is protected from casual rewriting during a correction.
Audit records may provide evidence relevant to authentication or admissibility. AcadiaSign does not guarantee that a court, regulator, counterparty, or other decision-maker will admit or accept them. Applicable evidence rules and authentication requirements remain controlling.
AcadiaSign uses SHA-256 to calculate a checksum for document bytes. SHA-256 is specified in the NIST Secure Hash Standard, FIPS 180-4. This reference identifies the algorithm; it is not a claim that AcadiaSign meets a NIST identity-assurance level or other NIST certification.
A checksum acts as a cryptographic fingerprint: if protected bytes change, a newly calculated value should no longer match a trusted checksum previously established for that version.
The platform can track distinct artifact types instead of treating a document as one mutable file:
Each version can store its own location, file size, checksum, creation time, and retention metadata. An integrity bundle links the checksum to a document, document version, optional envelope, MIME type, file size, status, and additional workflow metadata.
For an older document version that has no stored checksum, the current backfill process hashes the bytes then present in object storage and uses that value as the initial baseline. That process can detect later changes, but it cannot prove that no change occurred before the first trusted baseline was created.
SHA-256 makes changes detectable when compared with a trusted prior value. It does not prevent all modification and must not be described as making a file tamper-proof.
A hash by itself does not establish when the hashed bytes existed. AcadiaSign can therefore send a SHA-256 message imprint - not the PDF content - to one or more configured timestamp authority endpoints using the RFC 3161 Time-Stamp Protocol.
The timestamp request contains the SHA-256 message imprint, a random nonce, and a request for the TSA certificate. When an endpoint returns a successful HTTP response, AcadiaSign can preserve:
Multiple configured endpoints can be contacted in parallel.
This capability must be described precisely. AcadiaSign requests, stores, hashes, and packages response bytes. The current service does not fully parse and validate every response status, message imprint, nonce, signing certificate, chain, policy, or asserted generation time. It does not claim that every returned response is valid, authoritative, or qualified.
If no timestamp providers are configured - or none returns a response - the document can still retain its SHA-256 integrity record, but it will not contain embedded timestamp-response evidence.
When at least one timestamp response is available, AcadiaSign can package evidence into signed PDFs and successfully generated completion certificates.
The package can contain:
acadiasign-integrity-manifest.json, linking the bundle, document, version, envelope, timestamped checksum, and token filenames;.tsr attachment for each preserved timestamp response.There are two related fingerprints:
.tsr files, AcadiaSign computes a new SHA-256 checksum for the final packaged PDF.The final package is uploaded, retrieved, rehashed, and compared with its final trusted checksum. If that post-upload comparison fails, processing stops. Post-upload failures do not currently create a tamper-detection event on every surface, so the article should distinguish blocking from event creation.
AcadiaSign recomputes stored-file hashes at several consequential workflow boundaries, including:
The general verification process is:
A mismatch blocks the protected action. Several major surfaces also write a tamper_detected envelope event containing details such as the document, version, expected checksum, live checksum, reason, detection time, and workflow surface. Other surfaces stop or return an error without writing that event. The accurate public claim is therefore that a mismatch blocks the protected gate and may create a tamper-detection event, depending on the surface.
This is a tamper-evident design, not a tamper-proof guarantee. It detects byte-level changes after a trusted baseline has been established; it does not prevent every possible modification or prove who caused a change.
After the final recipient is committed as signed and the envelope is marked completed, AcadiaSign attempts subsequent signed-PDF and completion-certificate work. Those later steps are not part of the same database transaction. A completed envelope can therefore exist even if later PDF or certificate generation fails.
When certificate generation succeeds, the current certificate can include:
The implementation calculates a document count but does not currently render that count in the certificate. Public content should not claim that the certificate contains a document count until it is actually rendered.
The certificate can be stored as a separate record, receive a SHA-256 checksum, receive timestamp-response attachments when available, and be verified after final packaging. Email-send attempts can be recorded, but an accepted send request is not necessarily confirmed mailbox delivery.
A completion certificate is a generated evidence summary. It does not itself decide whether a contract is legally binding, authentic, enforceable, or admissible, and it is not a certificate issued by a certification authority. Certificate generation and the certificate's own public wording must remain consistent with those limitations.
AcadiaSign contains an archival routine for terminal envelopes. For eligible document versions and successfully generated completion certificates, the routine can apply an archival tag and request Amazon S3 Object Lock retention in COMPLIANCE mode.
Amazon S3 Object Lock documentation explains that, when compliance-mode retention is successfully applied to an object version, the object version cannot be overwritten or deleted during the retention period, including by the AWS account root user.
The reviewed code currently calculates the requested retention-until date as 2,555 days after the envelope completion timestamp. That is an approximately seven-year application setting, not seven calendar years in every case and not a universal legal retention period.
Actual WORM protection requires:
Application fields such as archival_eligible, object_lock_retain_until, or object_lock_applied_at should not, by themselves, be treated as proof that AWS accepted the lock. The current archival routine can update those fields even after an AWS tag or retention request reports failure. Public content should therefore say the routine requests retention and that actual protection must be verified in AWS.
Organizations must select a retention period based on applicable law, document type, contractual obligations, litigation holds, privacy and deletion duties, and operational policy. AcadiaSign does not claim that every signed record must or may be retained for seven years.
The reviewed application contains access checks, audit records, SHA-256 integrity controls, S3 storage, and optional Object Lock requests. Application-generated S3 object URLs use HTTPS. Amazon also states that all new S3 object uploads are encrypted at rest by default using SSE-S3 unless a different supported encryption configuration applies. See Amazon S3 default-encryption documentation.
Those facts do not establish a blanket end-to-end security or compliance conclusion for every deployed component. Source review alone does not verify production TLS settings, database and Redis transport, backups, key management, bucket access policy, monitoring, incident response, regional configuration, or operating effectiveness.
Data processing, privacy rights, and organizational practices are addressed separately in AcadiaSign's Terms of Use and Privacy Policy. That policy should be kept aligned with AcadiaSign's actual processing and product naming. This article does not claim blanket GDPR or CCPA compliance, and no SOC 2 claim should be made without a current, applicable independent report.
| Evidence need | Current AcadiaSign control | Accurate scope |
|---|---|---|
| Electronic-delivery consent | Affirmative checkbox and recipient-envelope consent record in the standard email-signing interface | Evidence that a consent action was submitted; not proof of every statutory consumer disclosure or every signing path |
| Intent to sign | Assigned-field responses, signature application, and signing-completion activity | Circumstantial evidence of intent; not a separate conclusive intent record |
| Attribution | Recipient-specific link, eligible Entra ID verification, recipient role, field ownership, and limited email-code workflow records | Supporting association evidence; current email-code records are not independently recipient-bound identity evidence and none of these controls is conclusive identity proof |
| Document association | Envelope, document, version, field, and recipient identifiers | Evidence connecting a recipient's activity to specified documents and fields |
| Integrity | Per-version SHA-256 checksums and protected verification gates | Detection of later byte-level changes after a trusted baseline exists |
| Chronology | Application event timestamps and preserved RFC 3161 response bytes | Workflow timing evidence and, after independent validation, possible external timestamp assertions |
| Change history | Correction snapshots, summaries, reasons, and events | Evidence describing corrections to a sent envelope |
| Completion evidence | Signed PDFs and a certificate when generation succeeds | A reproducible evidence package; not an enforceability or admissibility decision |
| Retention | S3 storage, archival tags, and Object Lock requests | Potential WORM protection only when AWS prerequisites are satisfied and successful lock application is verified |
This is a control mapping, not a certification matrix. Whether any control satisfies a particular rule depends on the document, parties, jurisdiction, deployment, configuration, and operating procedures.
AcadiaSign's workflow combines electronic-signature capture with transaction records and cryptographic document-integrity controls. It should not be confused with a standalone image of a handwritten signature or with a signer-held PKI digital signature.
AcadiaSign does not claim that:
Organizations remain responsible for transaction-specific legal review, consumer disclosures, signer-authentication requirements, access control, privacy and data-protection obligations, evidentiary requirements, retention policy, and operational monitoring.
No. Electronic signatures are widely recognized, and laws such as ESIGN and enacted versions of UETA generally prevent a signature or record from being denied legal effect solely because it is electronic. Enforceability still depends on intent, authority, attribution, consent, the agreement's terms, applicable exclusions, evidence, and governing law.
No. The standard interface presents a consent checkbox and records a submitted consent action. When ESIGN Section 101(c) or another law requires additional consumer disclosures or procedures, the sending organization must determine and provide what is required for the transaction.
No universal answer applies. ESIGN Section 7003 excludes specified categories from Section 7001, and other federal or state laws may authorize, prohibit, or separately regulate electronic execution. Wills, family-law documents, real-estate instruments, court filings, regulated notices, notarized documents, and records requiring witnesses or originals require transaction- and jurisdiction-specific review.
AcadiaSign provides an electronic-signature experience in which a person reviews a document and applies a signature or assigned response electronically. It also uses cryptographic integrity controls such as SHA-256 checksums and optional timestamp-response evidence. Those integrity controls do not automatically make the signer's mark a certificate-based or qualified digital signature.
The current implementation can use a recipient-specific access link, an email one-time-code step, and Microsoft Entra ID for eligible internal signers. These controls may support attribution, but they are not conclusive identity proof for every risk level. SMS OTP, knowledge-based authentication, and a separately entered access code are not currently implemented.
At a protected workflow gate, AcadiaSign retrieves the file, recomputes its SHA-256 checksum, and compares it with an allowed trusted checksum. A mismatch blocks that action. Certain gates also create a tamper-detection event; others stop or return an integrity error without creating that event.
The timestamp request contains a SHA-256 message imprint, not the PDF content. A returned response can be stored and embedded as evidence. The current implementation does not fully validate every response or claim that it is qualified.
No. Timestamp endpoints are deployment-configured. Embedded .tsr evidence is added only when at least one configured endpoint returns a response. SHA-256 version tracking and internal verification can operate without timestamp attachments.
Not necessarily. Envelope completion is committed before later PDF and certificate generation. When certificate generation succeeds, the certificate can be stored, hashed, optionally packaged with timestamp-response evidence, and verified. A later generation failure does not automatically reverse the completed envelope status.
No. The current code requests a retention-until date calculated as 2,555 days after completion for eligible artifacts. Actual Object Lock protection requires correct AWS configuration, permissions, a successful request, and operational verification. Each organization must determine its appropriate legal and operational retention period.
No such claim is made. A QES requires the elements specified by eIDAS, including a qualified certificate and qualified signature-creation requirements. Storing an RFC 3161 response or applying a visual signature does not by itself create a QES or qualified timestamp.
No. Notarization and remote online notarization are distinct, jurisdiction-specific processes and are not part of the reviewed AcadiaSign workflow.
No. This guide primarily addresses U.S. concepts and includes only a limited eIDAS comparison. It does not establish legal compliance in the European Union, United Kingdom, Canada, Australia, or another jurisdiction. Local counsel should review the intended transaction and deployment.
LEGAL DISCLAIMER: This page is general product information, not legal advice, and does not create an attorney-client relationship. Electronic-signature requirements vary by jurisdiction, transaction, document, parties, and circumstances. AcadiaSign does not guarantee that any electronic signature, workflow, evidence package, certificate, timestamp response, security control, or retention setting will satisfy a particular legal or regulatory requirement. Consult qualified counsel before relying on an electronic-signature workflow.