An invalid signature — what tampering looks like.

We took a real signed Certificate of Analysis and modified a single byte in the file — the smallest possible change. Both the verify website and Adobe Acrobat Reader detect the tampering immediately, from completely independent code paths.

Important. The example below was created in a controlled test environment for documentation purposes. Production COAs at verify.purityanalytics.com are not tampered. If you see this state on a real COA, do not trust the document.

Part 1 — On the verify website

The verify website flips state from "valid" to "document modified"

On every request, the verify website downloads the linked PDF bytes from Azure storage and recomputes a SHA-256 hash. It compares that live hash against the hash recorded the moment the PDF was signed — stored on a different row in a different database table, owned by a different process. A mismatch means the bytes have changed since signing.

Full Purity Analytics verify page in the document_modified state. The status badge reads 'Document modified' on a red field; a warning panel explains that the certificate's bytes have changed since it was cryptographically signed and the signature is no longer intact. — **Full verify page — invalid state.** The same artifact ID, but with a single byte of the linked PDF replaced. The page renders *"Document modified"* in red and refuses to display the analytical content as authoritative. The "Signature valid" green pill is replaced by a red warning state.

Closeup of the red Document Modified status banner on the invalid verify page. — **Status badge.** The same component that says "Signature valid" on a clean COA reads *"Document modified"* here. The colour, dot animation, and surrounding copy all flip. The user never sees the analytical results pretending to be authoritative.

Part 2 — In Adobe Acrobat Reader

Adobe Reader independently detects the same tampering

Adobe never talks to the verify website. It parses the embedded PKCS#7 SignerInfo from the PDF directly, validates the cryptographic signature against the document's ByteRange, and reports the result. For a single-byte modification, Adobe's banner colour changes from blue to red.

Adobe Acrobat Reader window showing the tampered Purity Analytics COA. A red banner across the top of the document reads 'At least one signature is invalid.' — **Adobe's verdict.** The red banner reads *"At least one signature is invalid"*. The original PKCS#7 signature was over a SHA-512 hash of the document at sign time; modifying any byte changes that hash and invalidates the signature.

Adobe Signature Panel showing the invalid signature: 'Signature is invalid: The document has been altered or corrupted since the Signature was applied.' Red X icons next to each validation row. — **Signature panel detail.** Adobe spells out exactly what's wrong: *"The document has been altered or corrupted since the signature was applied."* The signer identity check and certificate chain are still valid — the cert that signed the document hasn't been revoked — but the document hash check failed, so the signature over *these specific bytes* is broken.

Part 3 — Why it matters

Tamper detection is a property of the math, not our system.

Single byte = total invalidation

PKCS#7 detached signatures cover the entire signed ByteRange of the PDF through a cryptographic hash (RSA-SHA512 here). Changing one byte changes the hash, which means the signature no longer mathematically corresponds to the document. There is no partial-validity state.

Two independent verifications

The verify website's Tier-1 hash binding (a single SHA-256 comparison against a value persisted in PostgreSQL at sign time) and Adobe Reader's full PKCS#7 verification share zero code, zero network calls, and zero trust. They reach the same verdict because the underlying math is the same.

Re-signing requires the private key

A tampered PDF cannot be "re-signed" to make Adobe accept it again unless you possess the original signing certificate's private key. That private key lives only on a FIPS-certified USB token in our office, behind a PIN. The token is never connected to any internet-facing system during normal signing operations.

Revocation is separate

A document with a valid PKCS#7 signature can still be administratively revoked — for example, if a downstream error is discovered after release. The verify website surfaces revocation as a distinct state ("Signature revoked") that's independent of tamper detection. Adobe alone cannot show administrative revocation; it only sees the PKI-level signature status.

Now compare with a valid example.

See what the verify page and Adobe Reader look like when nothing has been tampered with.

View valid example →

Legal disclaimer

Educational use, no reliance, and liability limits.

These pages are general analytical education only. They are not medical, safety, legal, regulatory, quality-system, purchasing, or product-use advice, and they do not state that any material is safe, effective, sterile, injectable, therapeutic, approved, compliant, or fit for human or animal use.

Official standards, signed lab records, applicable law, and qualified professional review control.
Visitors use and rely on this content at their own risk.
To the fullest extent permitted by law, Purity Analytics LLC disclaims warranties and liability for losses arising from access, use, or reliance.

Read full disclaimer