Timestamping & Multi-TSA Architecture
RFC 3161 timestamps from the authority you configure, with fallback to a secondary provider. The legal weight of a timestamp depends on the provider and on the jurisdiction.
Published TSA Providers
The timestamp authorities the platform operator has chosen to publish on this page. Whether a provider's timestamps count as qualified or accredited depends on that provider's status in your jurisdiction.
The provider list could not be loaded right now.
Multi-Provider Fallback
You can configure a primary and a fallback TSA. If the primary does not respond, the request is retried with the fallback provider.
Multi-Provider Redundancy
Connectors exist for several regional and global RFC 3161 providers; which ones are enabled is shown in the list above.
Timeouts & Retries
Configurable timeouts with retry and fallback reduce the impact of a provider outage. If no provider answers, the record stays without a timestamp until stamping succeeds.
Clear Provider Attribution in Proofs
Every evidence manifest records the exact TSA provider, serial number, and policy OID used to seal the consent.
Only the SHA-256 Digest Is Sent to the TSA
As RFC 3161 works on digests, HashEntry does not send documents, consent payloads or IP addresses to timestamp authorities — only the 32-byte hash.
1. Local SHA-256 Computation (HashEntry Server)
2. RFC 3161 TSP Request Packet (32-Byte Hash)
3. RFC 3161 TimeStampToken (.tsr ASN.1 DER)
Independent Verification Without HashEntry
The generated TSA token (.tsr) can be independently validated against official Root CA trust chains using OpenSSL without transmitting a single byte to HashEntry.
Strengthen Your Compliance Evidence Today
Start with the free plan. No credit card required.