A signed contract often gets reviewed long after everyone has forgotten the signing ceremony.
A customer opens the PDF months later. An auditor checks it years later. A legal team receives it from someone outside the company. The first question is simple: can I trust this document?
That is where document sealing comes in.
After everyone finishes signing, Signater applies a final digital signature to the PDF using a trusted digital certificate. This seal protects the document's integrity and identifies who applied it. Signater's default seal uses a certificate whose trust chain is recognized through the Adobe Approved Trust List (AATL), so Adobe Acrobat and Reader can validate the signature without requiring the recipient to manually configure a certificate.
For Enterprise customers, Signater can also use your own AATL-trusted certificate, so the final PDF identifies your organization as the entity that sealed the document.
What is a document seal?
A document seal is a certificate-based digital signature applied to the completed PDF.
Think of it as a tamper-evident layer added after the signing workflow is complete. If someone changes the document afterward, the digital signature no longer matches the file. Acrobat can detect that change when the document is validated.
The seal also carries information about the digital certificate used to sign the PDF. That certificate identifies the organization behind the seal and connects it to a certificate authority that provides the underlying trust.
So there are two separate things happening:
- Integrity: the signature helps show whether the PDF was changed after it was sealed.
- Trust: the certificate chain lets software such as Adobe Acrobat determine whether the signing identity is trusted.
What does AATL mean?
AATL stands for Adobe Approved Trust List. It is Adobe's trust program for certificate-based digital signatures.
Adobe maintains a list of trusted root certificates from approved certificate authorities and trust service providers. When a digital signature can be traced through its certificate chain to a trusted certificate on that list, Acrobat and Reader can recognize the signature as trusted.
That distinction is important: AATL is not a certificate itself. A certificate authority or trust service provider issues the digital signing certificate. AATL is the trust framework that allows Adobe software to recognize certificates that meet Adobe's requirements.
For the person receiving your document, the practical difference is simple: they can open the PDF in the Adobe software they already use and validate the digital signature without having to import your certificate or configure a custom trust relationship.
Why Adobe trust matters for signed PDFs
A digital signature is only useful if the person receiving the document can understand and validate it.
Imagine sending a signed agreement to a customer. If their PDF reader reports an unknown or untrusted signing identity, your customer has to stop and figure out what that warning means. That creates friction at exactly the wrong moment.
With an AATL-trusted certificate, Adobe Acrobat has a built-in trust framework it can use when validating the signature.
That is especially useful when documents move outside your organization:
- A customer reviewing a contract.
- A supplier receiving a purchase agreement.
- An investor's counsel reviewing company documents.
- An auditor validating historical records.
- A partner opening a signed agreement years after it was created.
The recipient does not need a Signater account just to validate the document's digital signature. The trust information travels with the PDF itself.
AATL is about trust, not legal validity
It is important to separate two concepts that are often confused: electronic signature validity and certificate trust.
In the United States, the federal ESIGN Act establishes that a signature, contract, or record cannot be denied legal effect solely because it is electronic. State laws such as the Uniform Electronic Transactions Act (UETA) provide additional rules at the state level.
AATL does something different.
It gives recipients a widely recognized technical trust mechanism for validating a certificate-based digital signature. When a signed document is challenged or reviewed, that digital signature can provide evidence that helps answer important questions about the document:
- Was the document changed? The digital signature can reveal changes made after signing.
- Who applied the digital seal? The signing certificate identifies the organization or service associated with the certificate.
- Can the signing certificate be trusted? Acrobat can check whether the certificate chain leads to a trusted certificate in its trust store, including the Adobe Approved Trust List.
These capabilities strengthen the evidence associated with a signed document. They do not, by themselves, determine whether a particular contract is legally enforceable. Legal enforceability depends on the applicable law, the parties, the transaction and the circumstances surrounding the signature.
What happens when a recipient opens the PDF?
When Acrobat validates a certificate-based signature, it checks the digital certificate, the document's integrity and the certificate's trust chain.
For an AATL-trusted signing certificate, Acrobat can recognize the trust chain without the recipient having to manually establish trust for the certificate.
The result is a much cleaner experience than asking a customer to install certificates or contact your support team to understand why a signature appears as untrusted.
Signater combines that digital seal with the signing information and audit evidence generated during the signing workflow. The result is a PDF that contains both the completed agreement and the cryptographic evidence used to validate its integrity.
Where is the signing key stored?
The security of a digital signature depends heavily on how the signing key is protected.
Signater's AATL signing key is generated and stored inside a hardware security module (HSM). The private key is not exposed as a normal software key that can simply be copied to another server.
Signater uses an HSM validated to FIPS 140-3 Level 3 for its AATL signing infrastructure. The key remains protected by the hardware while Signater uses it to create document seals.
This is an important distinction between simply adding an image or visual stamp to a PDF and applying a real digital signature. A visual stamp can make a document look official. A cryptographic seal gives the PDF a mechanism that software can independently validate.
Enterprise: use your own AATL-trusted certificate
Some organizations want the final digital signature to identify their own company rather than their signing platform.
Enterprise customers using White Label can configure Signater to seal documents with their own certificate. The resulting PDF identifies your organization as the entity behind the document seal.
The private key remains in your Azure Key Vault, backed by hardware security. Signater does not receive or store the private key.
When a document needs to be sealed, Signater calculates the document hash and sends the hash to your key vault for signing. The vault performs the cryptographic operation with your protected key, and Signater uses the resulting signature to complete the PDF seal.
You configure the integration in Settings → White label → Seals:
- In Microsoft Entra, register an application and grant it the required permissions to use the cryptographic key in your Key Vault.
- In Signater, click Register vault and provide your directory ID, application ID, application secret and vault address.
- Click Connect key vault, select the signing key and provide the certificate chain.
Signater validates the certificate configuration before allowing it to be used as a document seal. This helps catch certificate or trust configuration problems during setup instead of after a contract has already been sent.
You can register multiple seals when your organization needs different certificates for different entities or business units. If you use Signater for managed accounts, those accounts can use the seals configured by your main account according to your setup.
What if you need a different certificate for Brazil?
Companies operating across multiple markets may have different certificate requirements.
For Brazilian workflows, Signater also supports ICP-Brasil document seals. This gives organizations the option to use the certificate ecosystem commonly required by Brazilian institutions and workflows while continuing to use an AATL-trusted certificate for documents intended for international recipients.
The important point is that ICP-Brasil and AATL solve different trust requirements. You do not need to treat one as a replacement for the other.
In Signater, you can select the document seal for an envelope in Details → Advanced settings → Document seal. Your account can also have a default seal configured under Settings → Account → General → Preferences → Default seal.
The selected seal is locked once the envelope leaves draft, so the document is sealed according to the configuration chosen for that workflow.
Choosing the document seal through the API
Integrations have the same control over document sealing.
The GET /v1/ecm/seals endpoint returns the seals available to your account. When creating or updating an envelope, the sealId field determines which seal should be used.
If no seal is specified, Signater uses the account's default configuration.
See the Signater Integration API documentation for the complete workflow.
Which Signater plans include document sealing?
Every Signater plan, including Free, uses a digital seal on completed documents.
Choosing a specific seal per envelope and changing the account default are available starting with Starter. Long-term validation is available on Business and Enterprise. Using your own certificates for document sealing is available with Enterprise and White Label.
If you want to see how a Signater-signed PDF validates in Adobe Acrobat, create a free Signater account. The Free plan includes up to three envelopes per month and does not require a credit card.
