Blog · June 27, 2026

How we built cryptographic timestamps into a SOC 2 compliance tool — and why auditors can trust them

Most compliance tools timestamp evidence server-side and ask you to take their word for it. Here is how RFC 3161 trusted timestamping moves that trust to DigiCert — and how your CPA can verify every attestation with a single OpenSSL command, no Scorifya account required.

Most compliance tools timestamp evidence server-side and ask you to take their word for it. Here is how RFC 3161 trusted timestamping moves that trust to DigiCert — and how your CPA can verify every attestation with a single OpenSSL command, no Scorifya account required.

The backdating problem with self-hosted compliance tools

When a compliance tool stores a timestamp alongside an attestation, the tool controls that timestamp. If you are using a spreadsheet, the cell says what you typed. If you are using a self-hosted app, the database says what the server clock said when you clicked submit. In both cases, an auditor reviewing the evidence has to trust the vendor's word that the timestamp was not modified after the fact.

For most SOC 2 tools — cloud-hosted or self-hosted — this is not a problem auditors push on hard during Type I engagements. Type I is a point-in-time assessment. But Type II covers a period of time: typically six to twelve months. An auditor reviewing controls evidence across that window needs some basis for trusting that the attestation date is the actual date. "Our database says March 15th" is not that basis.

We built Scorifya Controls to be self-hosted specifically so your evidence never leaves your infrastructure. That design decision creates an implicit question from any auditor who has done this before: if Scorifya does not control the data, who vouches for the timestamps? The answer is RFC 3161.

What RFC 3161 actually does

RFC 3161 is an IETF standard for trusted timestamping, originally published in 2001 and updated in RFC 5816. The protocol is straightforward: you hash the document you want to timestamp (SHA-256 in our case), send just the hash to a Timestamp Authority (TSA), and the TSA returns a TimeStampToken — a signed binary blob that says "I received this exact hash at this exact time."

The TSA signs the token with its own private key. You never send the document itself, only its hash. The vendor — in this case Scorifya — is not in the signing chain at all. We hand off the hash, receive the token, and store it alongside the attestation record. The TSA's signature is what makes the timestamp trustworthy, and that signature is independently verifiable by anyone who has the TSA's public CA certificate.

The token itself is DER-encoded and carries the hash of what was timestamped, the timestamp, the TSA identity, and the signature. It is self-contained — it does not require a network call to verify, it does not expire, and it does not require trusting Scorifya to read.

Why DigiCert, not just any TSA

RFC 3161 is a standard, but TSA trust is not uniform. A timestamp is only as trustworthy as the root certificate behind the TSA that issued it. If the TSA's root is not in your auditor's trust store, verifying the signature requires additional manual steps at best and skepticism at worst.

DigiCert's Timestamp Authority root is included in the Microsoft Root Certificate Program (Windows), Apple's root certificate program (macOS and iOS), Adobe's Approved Trust List (AATL, used by Acrobat), and other trust stores that auditing firms encounter daily. When a CPA opens a signed PDF or runs a verification tool, DigiCert's root is already trusted — not because of anything Scorifya did, but because DigiCert's PKI is embedded in the operating systems and software your auditor already uses.

We use Sectigo as a fallback TSA. Sectigo carries the same broad trust posture. If the DigiCert endpoint does not respond within five seconds, Scorifya automatically retries against Sectigo. Either way, the resulting token chains to a root that CPAs encounter in the normal course of their work.

How an auditor verifies it — without trusting Scorifya

Each attestation record in Scorifya Controls stores the raw DER-encoded TimeStampToken alongside the record. Verification requires OpenSSL (installed by default on macOS and Linux, available on Windows via WSL or the Win32 OpenSSL port) and DigiCert's TSA CA certificate, which DigiCert publishes publicly.

openssl ts -verify -in token.tsr -data document.json -CAfile digicert-tsa-ca.pem

Output on a valid token: Verification: OK. The command confirms that the hash in the token matches the document, that the signature is valid, and that the signing certificate chains to the DigiCert CA cert. No network call required, no Scorifya account, no trusting anyone's API — just OpenSSL and a public CA cert.

The auditor exports the token and document from the attestation record and runs the command locally. The auditor portal in Controls is built specifically for this workflow: read-only access with token export is available from Settings → Audit Access.

Air-gapped and enterprise deployments

Some enterprise environments cannot reach public TSA endpoints. For deployments behind strict egress controls or air-gapped networks, Controls supports any RFC 3161-compliant TSA via environment variables:

• TSA_URL — your internal TSA endpoint
• TSA_NAME — display name shown in the Controls UI
• TSA_CA_CERT_URL — URL to the CA certificate auditors use to verify tokens
• TSA_ONLY=1 — skip DigiCert and Sectigo entirely

The token format, storage, and verification process are identical regardless of which TSA issued the token. Auditors verify it the same way, substituting your internal CA cert for DigiCert's in the OpenSSL command.

What this means in a SOC 2 Type II audit

SOC 2 Type II covers a period of continuous control operation — typically six months to a year. Evidence collected across that window needs to be datable. A control attested on March 15th that appears in an audit closing in September requires the auditor to trust that date.

RFC 3161 timestamps move that trust from "the system records show March 15th" to "DigiCert's TSA signed this hash on March 15th." Those are not the same thing. The first is a database entry that anyone with write access could have modified. The second is a cryptographic commitment from a third-party authority whose root cert is already in the auditor's trust store — not because of any relationship with Scorifya, but because DigiCert's root was pre-installed by Apple and Microsoft.

For self-hosted compliance tooling, this distinction is the whole ballgame. Self-hosting means your data never leaves your environment, but it also means the vendor cannot vouch for anything inside it. RFC 3161 is how you get cryptographic vouching without a vendor in the loop.

Scorifya Controls is a self-hosted SOC 2 compliance tool with 33 automated checks across AWS, GitHub, GCP, and Azure, manual control tracking with evidence file uploads, and RFC 3161 timestamps on every attestation. Flat-fee annual license, your data stays on your infrastructure.

Try a scan on scorifya.com, read how we score, or see Pro for unlimited scans and exports.