← Blog

EU DSS library vs. hosted validation API: which fits your build?

EU DSS is excellent open-source software. The question is how much plumbing sits between a DocumentValidator call and an answer fit for an auditor.

The EU DSS library (esig/dss on GitHub) is the reference implementation for eIDAS signature validation. It handles PAdES, CAdES, XAdES, JAdES, and ASiC containers natively, and it is maintained by the European Commission's joint research centre. If you are validating electronic signatures in Java, EU DSS is almost certainly where you start.

The question is not whether EU DSS is good -- it is -- but how much engineering lies between a DocumentValidator call and a result you would put in front of an auditor or a regulator. That gap is larger than most teams expect, and it drives most of the interest in hosted alternatives.

What EU DSS does well

EU DSS implements the full ETSI EN 319 102 validation algorithm -- the standard that defines, at a technical level, what a conformant eIDAS validator must do. It supports every AdES signature format, every baseline level (B, T, LT, LTA), and every revocation path (OCSP, CRL). The library is comprehensive, actively maintained, and free.

If your use case is a single format, a fixed trust anchor, and an internal tool where you control the environment end to end, EU DSS alone is a reasonable choice. The library's quality is not the issue.

What you build around it

Production use requires a set of supporting pieces the library itself does not provide.

Trusted-list infrastructure. Validation against the EU List of Trusted Lists -- the 31 national trusted lists that define which certificate authorities can issue qualified certificates -- requires you to schedule a LOTL refresh, manage the cache, handle network failures gracefully, and keep the JVM truststore updated with each national CA. The LOTL is not a static file; it changes when member states add or revoke trust service providers, and a stale cache means incorrect validation results.

Format detection. DSS validators are typed: you instantiate a PAdESService for PDFs, a CAdESService for CMS binary, an XAdESService for XML, and so on. You have to know the document's format before you start. In practice, documents arrive over an API or from an upload with an untrustworthy Content-Type -- magic-byte detection and routing belong to you, not the library.

TLv6 compliance. DSS 6.4 adds support for TLv6, the revised Trusted List schema that became mandatory on 28 April 2026. Teams running DSS 5.x or early 6.x needed to plan and execute that upgrade before the deadline, or their validators lost the ability to read new entries in the trusted lists. It is a migration your team owns, on a schedule set by EU regulation -- not by your release plan.

Result decoding. EU DSS returns an Indication (TOTAL_PASSED, INDETERMINATE, TOTAL_FAILED) alongside a set of SubIndication codes and qualification enumerations. There are more than 20 qualification enums covering signature format, certificate type, QC statements, and timestamp binding. Translating them into a clear, auditable verdict -- "the signing certificate had expired, but a trusted timestamp anchors the signature to before expiry; the result is valid" -- is non-trivial, and the edge cases are where the legal exposure lives.

Format gaps. EU DSS has no built-in support for KRX, the container format used in Hungarian public administration and several CEE government systems. If your documents include KRX, you write a pre-processor that unpacks the container and passes the extracted content to DSS -- or you exclude that format from scope entirely.

The cost/benefit calculation

Teams reach for a hosted alternative when the infrastructure cost exceeds the benefit of direct library access. The most common triggers:

  • The application must support multiple AdES formats, requiring routing logic and format-specific service instances to be built and maintained.
  • Trusted-list freshness is a compliance requirement, and operating a reliable refresh schedule is overhead the team is not equipped to absorb long-term.
  • The integration is not Java -- EU DSS has no first-class bindings for Python, Go, Node.js or .NET.
  • The integration needs a structured, readable report that a compliance or legal function can audit without parsing raw JAXB objects.

None of these are criticisms of the library. They are the distance between a cryptographic toolkit and a production validation service.

What a hosted API provides instead

A hosted validation API collapses the infrastructure layer into a single endpoint. You send a document -- any supported format -- and receive a structured JSON report: who signed it, when, with what certificate, and at what eIDAS level (QES, AdES or SES). The trusted lists are kept current by the service. Format detection happens server-side. TLv6 upgrades are the vendor's problem, not yours.

The trade-off is control. If you need to inspect the raw validation chain, intercept OCSP responses, or run the validator in an air-gapped environment with zero outbound calls, a cloud API is the wrong shape. Both models have a place -- the choice follows from your architecture, not from which one is newer.

On-premises without the cloud dependency

For regulated environments where documents cannot leave the perimeter -- financial institutions, healthcare systems, government deployments -- the decision is not between EU DSS and a hosted API, but between assembling the full validation stack in-house or deploying a packaged engine inside your own infrastructure.

The Sealium on-premises engine ships the DSS-based validation stack as a self-contained Docker deployment. It handles LOTL refresh, format routing, KRX support, and structured reporting inside your network -- documents never leave the perimeter, and the API surface is identical to the SaaS version. The integration is the same regardless of which deployment model you choose.

Which model fits

Build on EU DSSSaaS APIOn-prem engine
LanguageJava onlyAny (REST)Any (REST)
LOTL maintenanceYour teamManagedManaged
KRX / CEE formatsBuild itIncludedIncluded
TLv6 upgradesYour scheduleAutomaticAutomatic
Structured reportBuild itJSON, every callJSON, every call
Documents leave perimeterOCSP/CRL calls onlyYesNo
Best forJava monoliths, custom validation logicFast integrations, multi-formatRegulated, air-gapped environments

The right choice depends on what your team is prepared to own. EU DSS is the correct foundation for a team willing to build and operate the infrastructure around it. A hosted or packaged engine is the right answer when that infrastructure is not what you want to be responsible for.

Start validating for free -- 100 validations a month, every eIDAS format, no credit card.

Validate your first document free

100 validations a month, every eIDAS format, no credit card. See the full report for one of your own documents in under two minutes.

Start for free