Signature Verification

Signature verification confirms whether an electronic signature record still covers what the record now says. The verification recomputes the record’s checksum and compares it with the value stored at signing time. The signer’s identity, timestamp, and IP address are displayed as they were recorded at signing time — they are not re-checked.

Every signature record was hashed with one of two schemes, shown as its checksum version:

• Version 2 (every signature signed from 2026-09-04 onward): an HMAC-SHA256, keyed with a server-side secret, covering the complete signed record — who signed, what was signed, the action, the meaning, the IP address and user agent, the signing timestamp, the document version binding, and the tenant. Only someone holding the server’s key could produce a matching checksum after altering any of these.
• Version 1 (every signature signed before 2026-09-04): an unkeyed checksum covering a narrower set of fields (see “What the checksum covers” below). This is a genuine, still-valid check, but a weaker assurance — it does not cover the signing timestamp, the document version, or the tenant, and does not require a secret key to reproduce.

A version-1 Signed verdict and a version-2 Signed verdict both mean the check passed, but they do not prove the same thing. The signature detail page and the register both show which version verified a given row so this difference is never hidden.

Verification is a read. Opening the verification page never changes the signature record, and every role sees the same verdict for the same record: an Admin, an auditor and the signer all get the identical result.

Verify a signature

1. On the left sidebar, select Signatures.
2. In the signatures table, locate the signature you want to verify.
3. Select Verify to open the verification page.
4. Read the Integrity check panel at the top of the page — this is the verification result.
5. Read the Signature and As recorded at signing sections below it for the record’s details. These are recorded values, not check results.
6. Select Re-run integrity check to repeat the comparison at any time.

Note

If the signature has been soft-invalidated (most commonly because the document was later re-signed, or an approval was reverted), a separate “This signature has been invalidated” notice appears above the Integrity check panel, showing the invalidation reason and when it happened. This is independent of the integrity verdict below it — an invalidated signature’s checksum can still recompute cleanly, since invalidation and integrity answer different questions. Per 21 CFR Part 11 the record is kept, never deleted.

The four verdicts

The integrity check reports one of four states. Only the first is a pass.

Verdict	Badge	What it means	What to do
Signed	Green	A checksum is stored and it recomputes exactly, over the fields the checksum covers (see below).	Nothing. This is the pass.
Integrity check FAILED	Red	A checksum is stored and it does not recompute. The record was altered after it was signed, and the signature no longer covers what the record now says.	Treat as a finding. The detection is written to the audit trail automatically; raise it with your quality team.
Cannot be verified — no checksum stored	Amber	No checksum was stored for this signature, so there is nothing to compare against.	Neither confirm nor rule out this record’s integrity. Do not present it as verified.
Cannot be verified — check could not run	Amber	The comparison itself did not complete.	Re-run the check. If it persists, report it. An unverifiable record is not a verified one.

Caution

An amber verdict is not a pass. It means the system cannot make a claim about the record either way. Only the green Signed verdict states that the record is intact.

The signatures register applies the same four verdicts to each row, so a record whose integrity failed is visible in the list without opening it.

What verification does and does not check

Record integrity is the only check the verification performs, and what it covers depends on the row’s checksum version (see above).

What the checksum covers

Version 2 (signed 2026-09-04 onward) is an HMAC-SHA256, keyed with a server-side secret, over: who signed, what resource type and id was signed, the action, the meaning of the signature, the IP address and user agent recorded at the time, the signing timestamp, and the document version binding (document_version_id), and the signature’s tenant. Reproducing a matching checksum after altering any of these requires the server’s key — not just write access to the row.

Version 1 (signed before 2026-09-04) is an unkeyed checksum over a narrower set — the signature record’s own identifying fields: who signed, what resource type and id was signed, the action, the meaning of the signature, and the IP address and user agent recorded at the time. It does not cover:

• the signing timestamp;
• the document version binding (document_version_id);
• the signature’s tenant.

Neither version covers the content of the signed document or record itself — verification says nothing about whether the document itself changed, regardless of version.

So a Signed verdict means “this signature record’s own covered fields are intact” — for version 2, that is the complete record; for version 1, a narrower subset of it, and reproducing it does not require the server’s key. A red Integrity check FAILED is always a real finding on either version. Version 1 should be treated as a corruption and accidental-alteration detector rather than as proof against a determined attacker with direct database access; version 2 additionally requires that attacker to hold the server’s signing key.

Shown on the page	Is it verified?
Record integrity (checksum)	Yes — this is the check. Scope depends on the row’s checksum version (see above).
Checksum version	N/A — stated, not checked; tells you which scope applied.
Signer name and email	No — displayed as recorded at signing time.
Signing timestamp	Version 2 only — covered by the checksum. Version 1: displayed as recorded, not checked.
Document version binding	Version 2 only — covered by the checksum. Version 1: displayed as recorded, not checked.
IP address, user agent	No, on either version — displayed as recorded at signing time, for forensic context.

Audit trail compliance

The verification system supports regulatory compliance by maintaining:

• A tamper-proof record of who signed, when, and from where.
• Cryptographic integrity verification to detect modifications to a signed record (21 CFR Part 11 §11.10(a)–(b)).
• Complete signer identity information linked to authenticated user accounts.
• Technical metadata (IP address, user agent) for forensic purposes.

When the check returns Integrity check FAILED, the system files an audit-trail entry recording the signature, the verdict, and who was reading it at the time. The signed content itself is never copied into that entry.

Practical example: Verifying signatures during a regulatory audit

During an FDA pre-approval inspection, an investigator requests evidence that the process validation protocol (PV-2026-001) was properly approved by all required signatories. The QA host demonstrates signature verification in real time.

1. The QA host navigates to Signatures and locates the signature for PV-2026-001 by the validation manager.
2. They select Verify to open the verification page.
3. The Integrity check panel shows a green Signed badge: the SHA-256 checksum was recomputed and matches the stored value.
4. The Signature section shows the record signed (Document PV-2026-001), the action (Approve), the meaning of the signature (“I approve this document for execution”), and the signing timestamp.
5. The As recorded at signing section shows the signer (Dr. Sarah Chen, s.chen@pharmatech.com), the IP address, and the user agent — labelled as recorded values, not as checks.
6. The QA host repeats the process for the remaining signatories (production director, regulatory affairs manager).

Had any of those records returned a red Integrity check FAILED, the correct response is to stop and treat it as a data-integrity finding — the record was changed after it was signed — rather than to re-run the check until it agrees.