Bring your own TSA: use your own timestamping authority in Sigill

A timestamping authority is an awkward dependency to migrate.

It may already be named in a vendor agreement, approved by security and compliance, or embedded in release and signing workflows. A team can want Sigill's evidence ledger, sealing flow, verification tools, public lookup, and SDKs without wanting a second migration project just to replace the TSA it already trusts.

That is now supported.

Paid tenants can connect their own RFC 3161 timestamping authority to Sigill. The TSA remains private to the organisation, is checked server-side before it can be saved, and can be used alongside Sigill-managed providers through the same timestamping routes.

Keep the TSA. Add the evidence layer.

Bring-your-own TSA is useful because it separates two decisions that should not have to be made at the same time:

• Which timestamping authority your organisation trusts.
• Which system records, routes, seals, and verifies the resulting evidence.

If you already have an approved TSA, you can keep it while moving your evidence workflow into Sigill. Timestamp hashes through the provider you chose. Use Sigill for the ledger trail, verification and lookup surfaces, and PAdES or CAdES seal workflows around those proofs.

It is also useful when adoption is not the issue at all. Teams that depend on a single TSA have a single external dependency in the critical path of producing timestamped evidence. Adding another eligible authority gives Sigill somewhere to route a request when a provider is unavailable or slow.

A saved endpoint has already proved it works

Connecting a TSA is not just storing a URL and hoping the first production request succeeds.

Under Settings → Timestamp authorities, an owner enters the endpoint and authentication mode, then runs verification. Sigill performs a live RFC 3161 request, parses the returned timestamp response, and verifies its token signature. A configuration that fails that check cannot be saved.

Credentials stay server-side and are protected at rest. The resulting TSA configuration belongs only to the tenant that created it; it does not appear as a platform provider for other organisations.

That server-side check matters. The platform is accepting a new source of cryptographic evidence into a tenant's workflow. It needs proof that the endpoint can produce a valid timestamp token, not a browser-side green checkmark.

Routing without provider logic in every integration

Sigill treats timestamping as a routed service. With tsaSlug: "auto", it can select from the authorities enabled for your tenant and fail over to another candidate if a request cannot be completed. A verified tenant-owned TSA joins that pool. When policy requires a particular provider, /tsa/stamp-hash and /tsa/restamp can address it explicitly by slug.

Existing integrations do not need a new code path just because a tenant adds its own provider. Code already using auto keeps using auto; the change belongs in tenant configuration, where provider policy can be managed centrally.

Seal operations use Sigill's automatic timestamp route as well. PDFs still receive PAdES signatures, other file types still receive detached CAdES signatures, and a successful TSA dispatch supplies the RFC 3161 timestamp embedded with the seal. Adding a tenant TSA therefore expands the available timestamp path for sealing without changing the document-signing model.

The SDK path becomes more practical

The same is true for the open-source sigill-python and sigill-dotnet SDKs.

sigill-python and sigill-dotnet already handle the repetitive part of AI evidence workflows: canonicalise an evidence envelope, hash it, send only that hash to Sigill for RFC 3161 timestamping, and attach the resulting proof. With a tenant-owned TSA configured in Sigill, applications using the SDK can keep that integration while the timestamp can come from a provider the organisation already uses.

That is the useful combination: your code uses an SDK instead of custom canonicalisation and timestamp glue; your organisation can retain its approved TSA; and Sigill provides the routed evidence layer between them.

The SDK envelope format remains open, and verification remains based on the proof itself. BYOT does not turn a private provider into a proprietary requirement.

What BYOT does not claim

A tenant-owned TSA is not made qualified merely by adding it to Sigill. Sigill verifies that it responds correctly and that the returned token signature is valid; it does not replace the customer's responsibility for provider selection, contractual trust, policy qualification, or regulatory assessment.

Nor does a private TSA become part of Sigill's public provider catalogue. It is scoped to the organisation that configured it.

Those boundaries are deliberate. Bring-your-own TSA is a way to use Sigill without giving up an existing trust decision, not a way to blur who made that decision.

Available now

Bring-your-own TSA is available for paid tenants under Settings → Timestamp authorities.

For teams already operating with a trusted RFC 3161 provider, this removes a practical blocker: you can adopt Sigill's ledger, routing, verification, sealing flows, and SDK-based evidence workflows without replacing your timestamping authority first.