If you build an e-signature platform, a document management system, a contract lifecycle tool or a digital onboarding product, timestamps are not a feature your customers see. They are infrastructure. Every signature your platform creates for a PAdES, CAdES or XAdES document at B-T level or above depends on a call to a Timestamping Authority (TSA), and every one of those signatures will be judged, years later, by the quality of the timestamp inside it.
That makes the choice of TSA a long-term architectural decision. Your platform will send it every signature from every tenant, your SLA will depend on its availability, your margins will depend on its pricing model, and your customers’ legal position will depend on its qualified status. Switching later is possible, but it is never free.
This checklist is written for product owners, architects and procurement teams at software vendors who need to select a qualified TSA for a multi-tenant platform. It covers what to verify on the regulatory side, what to test on the technical side, and what to negotiate on the commercial side.
1. Regulatory checks: is the timestamp really qualified?
Listed in the EU Trusted Lists. Under Article 41(2) of the eIDAS Regulation (EU) No 910/2014, only a qualified electronic timestamp enjoys the legal presumption of accuracy of date and time and of data integrity, and under Article 41(3) it is recognised as qualified in every Member State. Qualified status is not a marketing claim: it is published in the national Trusted List of the provider’s Member State, accessible through the EU List of Trusted Lists and the European Commission’s Trusted List browser. Look for a timestamping service with the service type for qualified electronic timestamps (QTST) and a granted status.
The tokens chain to the listed service. Request a sample token and check that the certificate of the timestamping unit (TSU) that signed it corresponds to the service listed in the Trusted List. A provider can operate both qualified and non-qualified services; your platform must call the qualified one.
Conformity with ETSI EN 319 421 and EN 319 422. These standards define the policy and security requirements for timestamping providers and the profile of the timestamp tokens. Conformity is assessed by an accredited Conformity Assessment Body, and the provider is supervised by its national supervisory body. Ask for the latest conformity assessment report or its attestation.
Time accuracy. ETSI EN 319 421 requires the time in each token to be synchronised with UTC within one second, with traceability to a recognised UTC source. For platforms where the order of events matters (bids, approvals, sequential signatures), this is not a detail.
Recognition in the validators your customers use. Your customers and their counterparties will open documents in Adobe Acrobat, in the European Commission’s DSS-based validators, and in national validation services. A qualified TSA listed in the EU Trusted Lists is recognised by these tools without manual configuration on the reader’s side. Test it: sign a document through the candidate TSA and open it in Acrobat on a clean machine.
2. Technical checks: will it carry your production load?
Availability. A signature that cannot be timestamped either fails or is produced at a lower level than your customer expected. Ask for the provider’s measured availability, not just a target. For a production platform, look for uptime above 99.9%.
Latency and throughput. Timestamping is on the critical path of every signing operation. Measure response times from your own infrastructure, under realistic concurrency, and ask how the service behaves during peaks such as month-end invoicing runs or bulk signing campaigns.
No quotas or throttling. Some providers impose daily or monthly caps, or throttle high-frequency clients. On a multi-tenant platform, one tenant’s bulk job must not exhaust a quota that every other tenant depends on. Ask explicitly whether any request limits apply, and get the answer in writing.
Standard protocol. The service should expose a plain RFC 3161 endpoint over HTTP(S), compatible with any standard library (EU DSS, BouncyCastle, iText, Apache PDFBox, OpenSSL, .NET and Java cryptographic APIs). Proprietary SDKs or wrappers create lock-in and make a future change of provider more expensive.
Authentication that fits a server environment. Credentials should be easy to manage in automated deployments, rotate safely and work from containers and clustered services without interactive steps.
Hash algorithms. Confirm support for SHA-256 and stronger hash algorithms, in line with ETSI TS 119 312 recommendations, so that the tokens you create today will not need early renewal because of a weak digest.
TSU certificate lifecycle. Ask about the validity period of the TSU certificates and how key rollovers are announced. This determines how long your tokens remain verifiable before archive timestamps are needed, and it should never surprise your operations team.
Hash-only processing. Only the hash of the data should ever leave your platform. This keeps customer documents out of the provider’s scope and simplifies your data protection assessment.
Test access. A serious provider lets you test against the production qualified service before you sign a contract, so you can validate tokens, latency and integration in your own environment.
3. Commercial checks: will the model scale with your platform?
Predictable cost per token at volume. On a platform, timestamp consumption grows with your customers’ document volumes, not with your seat count. Make sure the price per token decreases with volume and that you can forecast it per customer.
Prepaid packages with long validity. Short expiry periods force you to buy small packages often, or to lose unused tokens at the end of each period. A long validity window lets you buy at volume prices without the risk of waste, and smooths out seasonal peaks.
Usage visibility. You will need to meter usage per tenant for your own billing and capacity planning. Check that the provider’s reporting, combined with your own logs, gives you a reliable view of consumption.
Contract and invoicing. For vendors in the EU, check VAT treatment. Cross-border B2B services within the EU are normally invoiced under the reverse charge mechanism, with no VAT on the provider’s invoice.
Room to grow. Ask whether the provider offers tailored terms for multi-year commitments or volumes beyond its standard packages. Your platform will hopefully grow faster than your first forecast.
4. Contingency: plan for the day something changes
Even with a strong provider, a platform should not have a single point of failure on its signing path.
- Configure a fallback TSA. Implement retries with backoff and the ability to switch to a second qualified TSA if the primary one is unreachable. Tokens from any qualified TSA are verified independently.
- Monitor continuously. Track response times, error rates and token consumption, and alert before a prepaid package runs out.
- Understand the provider’s termination plan. eIDAS requires qualified providers to maintain an up-to-date termination plan (Article 24(2)). Timestamps issued while the service was qualified remain qualified, but you need to know how a change of provider would affect your operations.
- Keep long-term validation in your own hands. Embed validation data in your documents (B-LT) and apply archive timestamps (B-LTA), so that documents remain verifiable regardless of what happens to any individual provider.
How many timestamps does a platform need?
A signature at PAdES B-T level uses one timestamp. A signature extended to B-LTA, which is the recommended level for documents kept over the long term, typically uses two: one signature timestamp and one document timestamp. Multiplied across every tenant, the numbers grow quickly:
| Documents signed on your platform per month | Timestamps per year (B-T) | Timestamps per year (B-LTA) |
|---|---|---|
| 10.000 | 120.000 | 240.000 |
| 25.000 | 300.000 | 600.000 |
| 50.000 | 600.000 | 1.200.000 |
Documents with multiple signers add one signature timestamp per signature. For a platform, the timestamping budget is a direct function of success: the more your customers use your product, the more timestamps you need.
The checklist at a glance
| Area | What to verify |
|---|---|
| Regulatory | QTST service with granted status in the EU Trusted Lists; tokens signed by the listed TSU; ETSI EN 319 421/422 conformity; UTC accuracy within one second; recognition in Adobe and EU DSS |
| Technical | Uptime above 99.9%; latency under load; no quotas or throttling; plain RFC 3161; server-friendly authentication; SHA-256 or stronger; TSU certificate lifecycle; hash-only requests; test access |
| Commercial | Decreasing price per token at volume; long package validity; usage visibility; EU VAT treatment; tailored terms for growth |
| Contingency | Fallback TSA; monitoring and alerts; provider termination plan; B-LT/B-LTA under your control |
How qtsa.eu meets the checklist
qtsa.eu provides qualified electronic timestamps issued by AlfaTrust Certification S.A., a Qualified Trust Service Provider supervised under eIDAS and listed in the EU Trusted Lists for the issuance of qualified electronic timestamps. The service is built for platforms that timestamp on behalf of many customers:
- eIDAS qualified and listed in the EU Trusted Lists. Every token carries the legal presumption of Article 41(2), is recognised in all EU Member States and is validated automatically by Adobe Acrobat and Reader.
- Uptime above 99.9%. A highly available infrastructure for signing paths that cannot wait.
- Simple to use, without restrictions. A standard RFC 3161 endpoint that works with any library. No daily or monthly quotas and no throttling, so one tenant’s bulk job never blocks the others.
- 24-month validity. Every prepaid package can be used over 24 months from the date of purchase, so you can buy at volume prices without the risk of losing unused timestamps.
- Volume packages up to 1.200.000 timestamps, with tailored offers for platforms with higher volumes or multi-year commitments.
- Hash-only requests. Your customers’ documents never leave your infrastructure.
- No VAT for EU businesses. Companies registered in another EU Member State with a valid VAT number are invoiced under the reverse charge mechanism.
Test it against your own platform
The only checklist item you cannot verify on paper is how the service behaves in your environment. Request 50 free qualified timestamps, point your signing service to our TSA, and check the tokens, the latency and the validation in Adobe Acrobat and your own validators. Our integration guides cover the most common stacks, and our team can help you size a package for your expected volume.
Get 50 free eIDAS qualified timestamps → | See volume packages →
Frequently asked questions
Why should a platform use a qualified TSA?
Because your customers rely on the evidential value of their documents. Qualified timestamps carry the legal presumption of Article 41(2) eIDAS, are recognised in every EU Member State and are validated as trusted by Adobe Acrobat, which makes them the most defensible choice for a multi-tenant platform.
How do we verify that a TSA is qualified?
Look up the provider in the national Trusted List of its Member State, through the EU List of Trusted Lists. The timestamping service must appear with the service type for qualified electronic timestamps and a granted status, and the TSU certificate in the tokens you receive must belong to that service.
Should we use one TSA or several?
Use one primary qualified TSA for simplicity and volume pricing, and configure a second one as a fallback. Tokens from different qualified TSAs are verified independently, so a fallback does not affect the validity of your documents.
Can we switch TSA later?
Yes. Existing tokens remain valid and verifiable; new signatures simply use the new provider. The cost of switching lies in integration, testing and procurement, which is why the initial choice deserves care.
Do multi-signer documents use more timestamps?
Yes. Each signature normally receives its own signature timestamp, and a document timestamp is added when the document is extended to B-LTA.
Do you receive our customers’ documents?
No. Only a cryptographic hash is sent in each RFC 3161 request. The documents themselves never leave your platform.