Daily audit checkpoints

Quick answer for InfoSec questionnaires

Each day, an independent third-party Time Stamping Authority signs the day's seal on your audit chains. The resulting certificate can be verified offline by anyone, without access to CaseFlow systems or any trust in CaseFlow. The two chains are covered by different plans: the trust-account chain on any plan that includes the monthly close, and the activity-log chain on the Multi-Practice plan and the Trust Close plan. The free trial carries both. See Which chain, on which plan.

What this feature does

Each night, an automated process takes the final cryptographic seal of that day's chain and submits it to a public Time Stamping Authority over an encrypted connection. Two independent authorities are used: FreeTSA (primary) and DigiCert (fallback). Each authority applies its private key to produce an RFC 3161 TimeStampResp token, a binary certificate that records what your chain seal looked like at that moment in time. The token is stored in CaseFlow alongside metadata describing which day and which chain it covers. Anyone with the token, the chain seal, and the authority's published public certificate can verify the proof offline using OpenSSL.

Why this matters for an audit

Your firm's records sit in a system you control. Your audit log is sealed by software you operate. An auditor's first question is: "How do I know you didn't alter the records after the fact?" A cryptographic chain inside CaseFlow partially answers that question, but a determined insider with write access could reconstruct the chain after modifying records. The daily checkpoint addresses that limitation. The TSA's private key is held by an outside organization that has no relationship to your firm or to CaseFlow. Neither your firm nor CaseFlow can produce its signature.

Bar disciplinary investigation. A state bar investigator subpoenas your trust accounting records. You produce the trust audit log export with no filter other than a date range, described in Trust audit trail, which proves every entry for those dates end to end, carries its own standalone verifier and needs nothing from CaseFlow to check, and alongside it the daily signed checkpoints for the trust chain covering those dates. If the investigator also asks about workspace activity, you add the activity-log checkpoints for the same dates. Their office downloads FreeTSA's public certificate from FreeTSA's own servers and runs the verification itself. Your word and CaseFlow's word are not part of any of it.

Enterprise client InfoSec questionnaire. An AmLaw-100 client's IT security team sends a SIG questionnaire during vendor onboarding. One question asks about audit-trail tamper-evidence controls. You describe the RFC 3161 daily checkpoint mechanism, link this page, and attach a sample .tsr token from a recent day. The question is closed on the first review cycle because the verification path is public, standard, and does not require trusting the vendor.

Discovery in litigation. Opposing counsel asserts that records were altered before production. You produce the audit-log export alongside the daily checkpoint tokens covering the relevant period. Their forensic expert recomputes the day's chain seal from your export and runs it against the TSA-signed token. If the recomputed hash matches what the TSA signed, the records existed in that state at the time recorded inside the token, which for a checkpoint taken on schedule is shortly after that day ended. If anything was changed after the checkpoint was issued, the verification fails and the discrepancy is visible.

In plain terms: the daily checkpoint is an outside witness. Your firm does not run it. CaseFlow does not run it. An outside organization signs the day's seal and publishes its public key for anyone to use. Three years from now, anyone with the .tsr token, the chain seal and your export can show what had been logged by the time the token records, without needing access to CaseFlow systems.

Finding and reading the page

The checkpoint viewer is at Utilities in the sidebar, then Audit checkpoints. It is available to firm administrators on any plan whose chains are timestamped, which means the Trust Close plans and Multi-Practice. On Solo and Growth, a lock badge appears on the sidebar entry. The chain filter on the page lets you show one chain at a time.

The listing shows one row per calendar day, newest first. Each row displays the date, the chain it covers, a status pill, the number of audit entries covered that day, the first 12 characters of the chain seal (hover for the full value), and the TSA that responded. Two filters narrow the listing: a chain-kind dropdown and a date range with a from-date and to-date input. The actions column on each row shows a .tsr download button on signed rows and a .json manifest button on all rows.

Status	What it means	What you do
Signed	The TSA returned a valid signature for that day's chain seal	Download the .tsr token when an auditor or forensic expert requests proof
TSA unavailable	Both FreeTSA and DigiCert were briefly unreachable when the nightly process ran	The following night's run retries automatically; no action needed
Empty chain	No audit events were recorded on that calendar day	A sentinel row is still written so the absence itself is on record; there is nothing to verify
Error	A different problem occurred; the row shows the cause inline	Contact CaseFlow support if the status persists beyond one day

What the two downloads contain

	Manifest (.json)	Signed proof (.tsr)
What it is	A plain-text label file listing what the signed proof covers	A binary cryptographic certificate from an independent Time Stamping Authority
Who reads it	You, your auditor, or anyone reviewing the records	Cryptographic verification software, typically openssl ts -verify
What it proves on its own	Nothing on its own; it labels and describes the proof file	Nothing on its own; it needs the chain seal to verify against
What you do with it	Open it to confirm which day and which chain seal it covers	Hand it to your IT person, outside counsel, or forensic expert along with the manifest

The 2 files work as a pair. The manifest tells the verifier exactly which chain seal to expect and records the TSA URL, the entry count, and the date. The .tsr is what mathematically certifies that the seal was presented to the TSA at the recorded time. Without the manifest, the .tsr is an anonymous blob. Without the .tsr, the manifest is an unverified label.

Which chain, on which plan

There are two chains and they are checkpointed separately, because they are sold separately.

Chain	What is in it	Timestamped on
Trust-account chain	Every trust ledger entry, every statement upload, every monthly close and every attestation	Any plan that includes the monthly close, the Multi-Practice plan, and the trial
Activity-log chain	Everything else in the workspace: records created, edited and deleted, sign-ins, permission changes	Multi-Practice, the Trust Close plan, and the trial

Both chains are tamper-evident on every plan, whether or not the daily timestamp is included: every entry is sealed to the one before it, and the trust audit bundle ships the chain specification plus a standalone verifier that recomputes every row it shows in full and checks every link without CaseFlow. The daily timestamp adds the one thing a seal cannot give you on its own, a third party's statement of when the chain was in a given state.

A close you have signed is written to the trust chain, so the checkpoint for that day covers it. The reconciliation report inside your proof bundle names that checkpoint when one exists.

Days on which nothing was written to a chain are recorded too, as an explicit empty-chain entry, so a gap in the record is itself part of the record.

Each checkpoint's manifest states whether the root was taken after the day it names had ended. A root taken earlier is still exactly what the authority signed, and the certificate is still valid, but recomputing that day will not reproduce it, because entries written later that day fall outside it. The manifest says so rather than leaving your auditor to read the difference as tampering.

See Trust audit trail for what the trust bundle contains.

For your auditor or forensic expert

Forward this section to your IT person or outside counsel.

Verification command and authority public keys

To verify a daily checkpoint, you need 3 things: the chain seal from the manifest's chain_root_hash field (a 64-character hex string), the .tsr token file downloaded from the checkpoint viewer, and the TSA's public CA certificate.

Put the 64-character chain_root_hash in place of <chain_root_hash> exactly as the manifest gives it, then run:

# Verify the TSA signature against the chain root hash
openssl ts -verify -digest <chain_root_hash> -in <downloaded.tsr> -CAfile <tsa-ca>

Use -digest, not -data. The authority signed the chain seal itself, so -data would hash it a second time and report a mismatch on a genuine token.

FreeTSA's public CA certificate, the <tsa-ca> file, is available at https://freetsa.org/files/cacert.pem. Its signing certificate, https://freetsa.org/files/tsa.crt, is already inside the .tsr token, so you do not need it for this command.

DigiCert's TSA root certificate is published at https://www.digicert.com/kb/digicert-root-certificates.htm: download "DigiCert Trusted Root G4" in PEM format and use it as <tsa-ca>. A DigiCert token also depends on an intermediate certificate that it carries inside it. OpenSSL 3.0 and later find that certificate on their own; the openssl built into macOS does not, and reports a valid token as failed. To verify a DigiCert token on any version, extract the token's own certificates first and pass them with -untrusted:

openssl ts -reply -in <downloaded.tsr> -token_out | openssl pkcs7 -inform DER -print_certs > tsa-chain.pem
openssl ts -verify -digest <chain_root_hash> -in <downloaded.tsr> -CAfile <tsa-ca> -untrusted tsa-chain.pem

-untrusted only helps openssl build the path to the root; the only certificate trusted is the root you downloaded. OpenSSL 3 may print a "not a CA cert" warning for the signing certificate in that file; the line that matters is Verification: OK.

If the command returns Verification: OK, a certificate issued under the CA file you supplied signed this chain seal, and the token has not been altered since. Two more checks tie that to your records:

1. Read the signing time. Run openssl ts -reply -in <downloaded.tsr> -text and look at Time stamp:. It is shown in GMT, while checkpoint_date is a day on the firm's own clock, so convert the time to the firm's time zone first. A checkpoint is requested shortly after the firm's day ends, so the time should fall soon after the end of checkpoint_date. Some older checkpoints were taken before the day ended: their manifest says "covers_complete_day": false, explains why in note, and their time falls during that day. A much later time proves only that the seal existed at that later time.
2. Match the seal to your records. The seal is the last entry of the whole chain that day, so an export filtered by account, client, matter or event can leave that entry out. In an unfiltered export, the entry whose id is the manifest's last_row_id must carry chain_root_hash as its row_hash. For the trust chain, use the trust audit bundle (Trust audit trail), set no filter other than a date range that includes that date, and run its verifier.php, which recomputes every entry's hash; when it passes, a match ties the seal to the entries themselves. For the activity-log chain, use the activity-log export, which always covers the whole log. CaseFlow does not yet ship a standalone verifier for that chain, so there a match shows only that the hash recorded on entry last_row_id is the one that was signed, not that each entry is unchanged.