Self-hosted DocuSign alternative for qualified electronic signatures: the short answer
If your EU contracts need advanced or qualified signatures under eIDAS, the first thing to know is that DocuSign's pricing page places advanced and qualified signatures only on Enhanced plans sold through sales, while simple electronic signatures appear on its Personal, Standard and Business Pro plans. The European Commission describes three levels: simple signatures, advanced signatures (AdES), which must let the signatory keep control and make later changes detectable, and qualified signatures (QES). A self-hosted Documenso or DocuSeal instance, signing with its own signing certificate, can produce simple signatures and, with the right certificate, key handling and audit controls, advanced signatures. That is a technical and procedural claim you must verify against your own legal assessment, not a legal conclusion the software gives you.
A qualified electronic signature is an advanced signature created by a qualified signature creation device and based on a qualified certificate. The certificate must come from a qualified trust service provider that has been audited, granted qualified status by a national authority and listed in the national Trusted List. The open-source platform cannot make a signature qualified by itself, and a self-generated certificate such as the self-signed .p12 option Documenso documents in its SIGNING.md file does not meet that test. Before you migrate, ask your legal team which signature level each contract type requires, confirm with your candidate trust service provider that it is on the Trusted List, and check whether the provider offers an API or signing flow that your Documenso or DocuSeal instance can call.
Practically, the decision splits into two paths. For agreements that only need simple or advanced signatures, a self-hosted instance with a properly managed certificate may be enough, and you keep signer data and audit trails on your own servers. For agreements that legally require a QES, plan for a qualified trust service provider as a separate contract with its own onboarding, identity verification and recurring fees, and confirm how those signing events are recorded in your archive. Ask any implementation partner to document which contract types map to which level, so auditors and counterparties can trace each signature to its basis.
What eIDAS requires for each signature level
eIDAS sets three signature levels, and each adds requirements on the signing tool, the certificate and the provider behind it. The cards below separate what a self-hosted Documenso or DocuSeal instance can produce from what only a qualified trust service provider can supply, so you can decide which level each workflow needs before you choose a setup.
Simple electronic signatures
A simple signature is the lowest eIDAS level and covers data in electronic form that a signer attaches or associates with other data. It carries no particular technical requirement, so a self-hosted Documenso or DocuSeal instance can produce it with email verification, an audit trail and a signed record. Check which internal workflows accept this level, because a simple signature shifts more evidentiary weight onto your own logs if a signer later disputes it.
Advanced electronic signatures (AdES)
An advanced signature must uniquely link to the signatory, identify the signatory, be created under the signatory's sole control and make later changes to the signed data detectable. A self-hosted instance can meet these properties when signers authenticate strongly and the document is sealed with a signing certificate you control. Confirm with your legal team that the signer identification method is strong enough for the contract type.
Qualified electronic signatures (QES)
A qualified signature is an advanced signature created by a qualified signature creation device and based on a qualified certificate. It has the equivalent legal effect of a handwritten signature across all EU Member States. Self-signed certificates and a signing key held on your own server do not meet this definition, so a QES workflow needs a certificate issued by a qualified trust service provider.
Qualified trust service provider status
Qualified certificates come from qualified trust service providers, which are audited, granted qualified status by a national supervisory authority and listed in the national Trusted List. Before you engage one, confirm that the provider appears in the Trusted List of the Member State where it operates and that its qualified services cover signature certificates. Ask for the current audit conformity assessment report and check the listing date, because status can change.
Integrating a provider with your instance
A qualified trust service provider issues the certificate and typically controls the signing device, so your self-hosted platform must call that provider's remote signing interface rather than sign with a local file. This integration is extra project work that recurs whenever the provider changes its API or certificate profile. Ask the provider for its integration documentation, supported signature formats and test environment before you commit to a platform.
Verifying signatures later
Long-term validity depends on keeping the signed PDF, the certificate chain and the revocation evidence together. Verification should be possible for years after signing, even if the provider or platform changes. Test that your chosen platform's PDF signature verification reads the qualified signature, and archive the validation report alongside each executed contract in your own storage.
Which self-hosted option fits each signature level
Simple electronic signatures are the broadest category under eIDAS and cover most internal approvals, acknowledgements and low-risk agreements. Both self-hosted options handle this level well, because the signing workflow, recipient emails, field placement and completion records do not depend on a qualified certificate. The practical work is in the workflow design and the evidence you keep, not in cryptography.
- Documenso workflow: Documenso sends documents to recipients in a defined order, collects fields and stores the completed file on your PostgreSQL and file storage.
- DocuSeal workflow: DocuSeal's WYSIWYG PDF field builder places signature, date and text fields on existing forms, and the free on-premises edition covers this use.
- Evidence to keep: Store the completed PDF, the audit record and the recipient email log together so you can show who signed, when and from which address.
- Certificate step: Documenso still needs a signing certificate to digitally sign the finished document, so configure a self-signed .p12 or KMS-backed certificate even at this level.
- Integration: Use the DocuSeal API and webhooks or the Documenso API to connect signing events to your HR or contract systems.
Before relying on simple signatures for a given contract type, confirm with your legal team that no national formality or the ESIGN Act exclusions apply to that record.
An advanced electronic signature under eIDAS must uniquely link to the signatory, allow the signatory to keep sole control, and make later changes to the signed data detectable. A self-hosted system can meet the technical shape of this level when the signing certificate is tied to your organization and the document is sealed after signing. Whether your implementation satisfies the legal definition is a determination for your legal team and, where needed, your supervisory body.
- Sealing with a certificate: Documenso's signing certificate options, including a self-signed .p12 generated with OpenSSL or signing through Google Cloud KMS, let you seal documents so later edits are detectable.
- Signature verification: DocuSeal includes PDF signature verification, which helps recipients and auditors check that a file has not changed after signing.
- Identity of signers: Both tools verify signers by email link by default, so decide whether that is sufficient or whether you need stronger identification before signing.
- Key custody: With a self-signed certificate, your organization controls the key, which also means you own its rotation, storage and loss scenarios.
- Documentation: Record how each signer is linked to the signature, how the key is protected and how changes are detected.
Ask your legal team and your security team to confirm that the chosen certificate and signer identification method meet the advanced-level requirements for each contract type before you use the term in documentation.
A qualified electronic signature is an advanced signature created by a qualified signature creation device and based on a qualified certificate. The certificate must come from a qualified trust service provider that is granted qualified status by a national authority and listed in the national Trusted List. This is the level that carries the equivalent legal effect of a handwritten signature across EU Member States, and it is the level a self-hosted instance cannot produce by itself.
- Qualified certificate: A certificate issued by a provider on the national Trusted List is the element that a self-signed or KMS-backed Documenso certificate does not supply.
- Qualified device: The signing key must sit in a qualified signature creation device, which is usually a service or hardware controlled by the provider.
- Integration pattern: Keep Documenso or DocuSeal as the workflow and document layer, and connect a qualified trust service provider for the signing step, subject to the provider's API and contract terms.
- Documenso options: Confirm with Documenso's documentation and your legal team whether any documented certificate option is accepted as a qualified signature for your use case.
- Cross-border use: Check that the provider's trusted status applies in each Member State where your counterparties sign.
Do not describe a Documenso or DocuSeal signature as qualified until your legal team and your chosen trust service provider have confirmed the arrangement in writing.
Documenso, DocuSeal and DocuSign compared for eIDAS levels
This table compares DocuSign eSignature, self-hosted Documenso and self-hosted DocuSeal by the eIDAS signature levels each can support, what a qualified trust service provider adds, and the trade-offs. Read each row as a question to confirm with the vendor and your own signing design, not as a claim of feature parity. The main takeaway is that a self-hosted instance with its own certificate covers simple or advanced signing in your control, while qualified signatures depend on a qualified trust service provider.
| Option | Signature levels it can support | What a qualified trust service provider adds | Trade-offs |
|---|---|---|---|
| DocuSign eSignature | Simple on Personal, Standard and Business Pro. Advanced and qualified listed only on Enhanced plans sold through sales. | Qualified certificates and qualified signature handling are included in the Enhanced offering. Confirm the trust service provider and terms in the sales contract. | Level depends on plan and contract. Signing data and audit records sit with the vendor under its terms. Confirm the exact qualified scope in writing. |
| Self-hosted Documenso (AGPL-3.0) | Simple and advanced signing are possible when you supply a signing certificate, such as a self-signed .p12 or a key in Google Cloud KMS. Confirm how your design meets the advanced requirements. | A qualified trust service provider issues the qualified certificate and must be on the national Trusted List. Integrating its certificate and signature device is a separate project to scope. | You control the instance and data. Self-signed certificates do not give qualified status. Enterprise options, including Part 11 modules, are priced on request. |
| Self-hosted DocuSeal (AGPLv3 with Section 7(b) terms) | Simple and advanced signing are possible when you configure your own signing approach. Confirm certificate support and the advanced controls with the vendor before relying on it. | A qualified trust service provider must issue the qualified certificate and be listed on the national Trusted List. Ask the provider how its certificate and device connect to DocuSeal. | Free on-premises edition has no SSO, bulk send or embedded signing. Pro adds them at a per-user yearly rate. Confirm which edition gives the signing features you need. |
How to deploy Documenso or DocuSeal for eIDAS signing in the EU
This sequence takes an EU team from a legal decision on signature level to a tested, self-hosted signing system, with a clear point where a qualified trust service provider becomes necessary.
Confirm the signature level for each document type
Legal counsel or the compliance owner maps each document type to the signature level it needs: simple, advanced (AdES) or qualified (QES) under eIDAS. Record the decision per document type, including any national rules that require a specific form of signature. Qualified signatures carry the equivalent legal effect of a handwritten signature across EU Member States, so the decision drives every later step. The output is a signed-off table of document types and required levels that the rest of the sequence refers to.
Deploy the platform with Docker Compose and PostgreSQL
The platform team deploys Documenso from its official images with Docker or Docker Compose and a PostgreSQL database, or DocuSeal from the docuseal/docuseal image with PostgreSQL or MySQL set through the DATABASE_URL variable. DocuSeal defaults to SQLite, which suits trials rather than production records. Run the instance inside your own EU cloud account or data center, with TLS, a managed backup target and restricted administrative access. The check that closes this step is a working login on an internal hostname and a database that survives a container restart.
Provision the signing certificate
Documenso needs a signing certificate before it can digitally sign documents. Options in its documentation include a self-signed .p12 certificate generated with OpenSSL, or signing through Google Cloud KMS. A self-signed certificate supports simple or advanced signatures under your own control but is not a qualified certificate. If you use Google Cloud KMS, select the key location deliberately, because the key region determines where signing operations and key material sit. Store the .p12 file and its passphrase in your secrets manager. The output is a test document that shows the expected certificate details.
Contract a qualified trust service provider where QES is required
Where a document type requires a qualified electronic signature, the organization contracts a qualified trust service provider that issues qualified certificates and operates a qualified signature creation device. Confirm that the provider is listed in the national Trusted List of the relevant Member State before signing a contract. Integrate its signing service with the platform through the integration the provider supplies, and confirm with the provider and your counsel which signer identity checks apply. Ask the provider for its certificate policy, its signer onboarding process and its data location terms. The output is a signed contract and one successful qualified signing test.
Configure audit logs, backups and EU storage location
The platform owner sets where documents, signer data, audit trails and backups are stored, and confirms that all of them remain in the EU region you chose. Enable application and database logging, restrict who can export or delete completed envelopes, and define retention periods that legal counsel approves. Test a restore of the PostgreSQL database and a completed document into a separate environment. The output is a written storage map covering the database, file storage, backups, certificate material and email delivery, with a restore test record.
Verify signed PDFs with signature verification
Test the output before any real contract is signed. Sign sample PDFs at each level used in step one, then run the signed files through a signature validation tool and DocuSeal's PDF signature verification where applicable. Check that the signer, timestamp and certificate chain are readable and that any change to the document after signing is detected. For qualified signatures, confirm with the trust service provider that its validation result is accepted by the counterparties you deal with. The output is a verification report for each document type.
Run pilot envelopes before cutover
Run a small set of real but low-risk envelopes through the new system alongside the existing commercial process. Involve the legal, procurement and records owners who will rely on the output, and have them review the completed PDFs, audit trails and archived records. Keep the commercial service active until open envelopes close and the migrated archive is validated. The output is a signed pilot acceptance record that names the document types approved for production use and the date each one moved over.
Where self-hosting does not give a qualified signature
A self-hosted Documenso or DocuSeal instance can produce simple or advanced signatures under your own control. Qualified status depends on things the software alone cannot supply: a qualified certificate, a qualified signature creation device, and a trusted provider. The cards below mark where that boundary sits and what to verify before you rely on a signed record.
Self-signed certificates are not qualified
A signing certificate you generate with OpenSSL as a self-signed .p12 file, or one held in your own cloud key service, does not come from a qualified trust service provider. Documenso documents these options for signing, but a signature made with them is not a QES. Treat them as a basis for simple or advanced signatures and confirm with counsel which records they can support.
QES needs a qualified device
A qualified electronic signature must be created by a qualified signature creation device and rest on a qualified certificate. Both requirements sit with a provider that has been audited and granted qualified status by a national authority. Ask any vendor or provider to show the device, the certificate chain and the status in the national Trusted List before you describe a signature as qualified.
Legal effect outside the EU
The eIDAS levels apply within the EU. The US ESIGN Act does not deny electronic records legal effect merely for being electronic, but it excludes wills, codicils and testamentary trusts, state family law records such as adoption and divorce, most of the Uniform Commercial Code, and court orders. Records in those categories and cross-border signers need a separate legal review before you rely on any signature type.
Platform does not certify conformity
Documenso and DocuSeal are software. Their licenses and code do not make your deployment conform to eIDAS, and no open-source project issues a qualification or attestation for your instance. Your organization, or a qualified provider it contracts with, must document the configuration, key management and retention. Ask your legal team which evidence a counterparty or court will expect from your setup.
Counterparty verification depends on trust lists
Whether a recipient accepts a signature as qualified depends on whether they check the certificate against the national Trusted List. A signature that validates in your own system may still be treated as advanced or simple by another party. Agree the signature level and verification method with each counterparty before sending, and record the verification result alongside the signed file.
Qualified providers add recurring cost
Qualified certificates and devices are typically bought from a qualified trust service provider on terms set by that provider, which means fees you pay on top of your hosting. Ask each provider for the per-signature or per-certificate pricing, validity period, identity verification steps and integration method in writing. Those terms drive the cost of QES far more than the open-source license does.
Why keeping EU signer data in the EU changes the provider decision
Where signer data sits decides which transfer rules apply, so the hosting location and the qualified provider belong in the same assessment. Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet the conditions of Chapter V. The EDPB's Guidelines 05/2021 (version 2.0) treat two situations as transfers: remote access from a third country, even only to display data on a screen for support, and storage in a cloud outside the EEA. A signing platform handles names, email addresses, IP data and signed contracts, so a SaaS tenant or a support session from outside the EEA can bring the flow under Chapter V even when the servers are in Europe.
The second exposure is the law that governs the provider, not only the server location. The CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data is inside or outside the United States. Following the Court of Justice's Schrems II judgment (Case C-311/18), the EU-US Privacy Shield was invalidated while standard contractual clauses survived. The Data Privacy Framework adequacy decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Confirm the current status of that appeal with counsel before you rely on it. The EDPB's Recommendations 01/2020 also state that where a provider needs data in the clear and a foreign authority's powers go beyond what is necessary and proportionate, no effective technical supplement is expected to close the gap.
For this reason, assess a self-hosted Documenso or DocuSeal instance in an EU data center together with the qualified trust service provider that issues the certificate. A self-hosted instance keeps documents and audit records under your control, but the certificate provider, email delivery and any vendor support access are separate processing paths. Ask each party where data is stored, who can access it, and whether any non-EU law can compel disclosure. Document the result as a transfer assessment, and have your data protection officer and counsel decide whether the flows need standard contractual clauses or can stay within the EEA. This section does not constitute legal advice.
What do buyers ask before moving EU signing off DocuSign?
Does a self-hosted Documenso or DocuSeal instance produce a qualified electronic signature?
No. A qualified electronic signature under eIDAS must be created by a qualified signature creation device and based on a qualified certificate issued by a qualified trust service provider listed in a national Trusted List. Documenso and DocuSeal can sign documents with a certificate you supply, such as a self-signed .p12 certificate, which gives you a simple or advanced signature depending on how identity and control are handled. Reaching the qualified level means engaging a qualified trust service provider, and that decision should be confirmed with your legal team before the workflow goes live.
What does a self-hosted EU signing setup cost, and what drives it?
Costs fall into several components. The software itself is free under AGPL-3.0 for Documenso and for DocuSeal's On-Premises Open Source edition. DocuSeal's On-Premises Pro costs $240 per user per year, or $20 per user per month billed annually, according to its pricing page as read in October 2026, and it adds SSO and embedded signing. Documenso's paid plans, from Individual at $25 per month to Platform at $250 per month, are cloud pricing, and its Enterprise plan covers self-hosted licensing on custom terms. Recurring costs include hosting, backups, email delivery and staff time. One-time costs include deployment, template rebuilding and certificate setup. A qualified trust service provider charges its own fees, which you should request in writing.
How long does a self-hosted deployment take in an EU environment?
The duration depends on scope, the number of templates, the identity verification process, the integrations you need and how fast your internal approvals move. No timeline is set by the platforms themselves, so ask your implementer to state a duration in the written scope and confirm the assumptions behind it, including the hosting region, the certificate source and the date your legal team signs off on signature levels. If you need a qualified provider, add the provider's onboarding time, which is not controlled by the software project.
What does our team need to provide for an EU signing project?
Several inputs come from you rather than from the software. Legal needs to decide which documents require simple, advanced or qualified signatures and document that decision. Your compliance and identity team needs to define how signers are verified before they sign, because advanced and qualified levels depend on that process. Infrastructure teams need to name an EU hosting location for the application, the PostgreSQL or MySQL database, backups and signing keys. Procurement needs to confirm which third-party services, such as email delivery, touch signer data. Confirm each of these early, since they shape the scope.
Can our own engineers run a Documenso or DocuSeal deployment without a partner?
Some teams can. Both projects are open source and ship Docker images, and DocuSeal runs from the docuseal/docuseal image with SQLite by default. Documenso supports Docker Compose, Kubernetes and manual installation and uses PostgreSQL. The harder parts are certificate management, signing key protection, identity verification design, backups, upgrades and documenting evidence for an assessor. Assess whether your team has these skills in-house, and make sure someone owns each control. Teams without that capacity often bring in an implementer under a fixed-scope written agreement.
What should we ask a qualified trust service provider to include in a quote?
Ask for a written list of the signature levels the provider supports, the document types and signer identity methods it covers, and how its certificates are issued and revoked. Confirm that the provider is a qualified trust service provider listed in the national Trusted List of the relevant Member State, since the European Commission describes the list as the basis for qualified status. Ask for per-signature or per-certificate fees, setup charges, minimum commitments, support terms, and the process and cost for integrating its service with your Documenso or DocuSeal instance. Request the data location and any third-country access exposure in writing.
What evidence to keep for an eIDAS signature review
An eIDAS review starts with the signing certificate and the record of how it was issued. For a self-hosted Documenso or DocuSeal instance, the certificate that signs documents is one you generate or source yourself, so keep the issuance record: who requested it, the key length and algorithm, the validity period, and the approval that authorized its use. If you signed with a self-signed .p12 certificate, be clear with the reviewer that it proves integrity and control of your own system, not that the signer's identity was verified by a qualified provider. If the key sits in an external service such as Google Cloud KMS, keep the key policy, the access grants and the key creation and rotation logs alongside it. Confirm with your supervisory authority or auditor which of these records they expect for simple or advanced signatures and which they expect for qualified ones.
Where you use a qualified trust service provider, the Trusted List entry becomes part of the evidence file. Under the European Commission's eSignature guidance, a qualified certificate must come from a provider listed in a national Trusted List, so store the provider's status as it stood on the signing date, not only today. Keep the qualified certificate, the signer identification records the provider holds, and the provider's contract and assessment references. Keep also the audit trail and completion records, the signature verification results and the access logs for the platform, all stored on EU servers and backed up within the same jurisdiction. Ask your provider and your auditor how long each record must be retained and in what format it must be produced.
Key management and access records are what most reviewers test first. Keep the change history for signing keys and certificates, the list of administrators who could read or use them, and the logs showing each signing operation tied to a document and a user account. Keep the platform's audit log export and check that its timestamps are synchronized with a trusted time source. Run a test verification on a sample of completed documents and file the results, so you can show that the stored evidence still validates after upgrades. Documenso and DocuSeal each run with a PostgreSQL or MySQL database, so back up the database and the audit records together to keep them consistent.
How DeployOpen deploys self-hosted signing under eIDAS constraints
DeployOpen plans, implements, hardens and documents self-hosted Documenso or DocuSeal inside your own cloud accounts, data centers or air-gapped networks. For qualified signatures, we also define how the signing certificate, the qualified trust service provider and your evidence records fit together, so your team knows exactly which signature level the system produces.
How we scope
- Written scope fixes which eIDAS signature levels the system will produce, and which ones it will not.
- We map each document type to a signature level and record which ones need a qualified trust service provider.
- Scope names the hosting location, certificate source, email delivery path and integrations before any build work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.
How we build
- We deploy Documenso or DocuSeal with PostgreSQL or MySQL, using the container images and configuration your platform team approves.
- We configure a signing certificate, such as a self-signed .p12 or a managed key service, and document what it does and does not prove.
- We test signing, verification and audit trail output against documents your legal team has chosen as representative samples.
- We run security testing on the signing application and its APIs, and record the results with remediation owners.
How we hand over
- You receive architecture, configuration and certificate records, so auditors and counsel can trace each signature to its source.
- Runbooks cover backup, restore, certificate renewal, upgrades and the procedure for moving a signed record to long-term storage.
- We prepare control evidence for compliance assessments. We do not issue audit reports, attestations or certifications, which independent auditors provide.
- Your team gets a documented list of items to confirm with a qualified trust service provider and with your legal advisers before go-live.
How we support
- Retainers cover upgrades, patching and continuous testing of the signing platform after handover.
- When a new Documenso or DocuSeal release is published, we assess its changes against your configuration and test in staging first.
- Periodic reviews check certificate validity, key custody, backup restores and the trust list status of any external provider you use.
- Changes to signature policy or legal requirements are scoped in writing and delivered as fixed-scope work.
