Document verification · Digital signatures
How to validate a PDF signature without overstating what it proves
A PDF can have a valid digital signature and still contain a wrong figure. It can also show an unknown signer because your reader cannot establish trust. Before using either result in an investigation, separate five questions: which file, which signature, which trust chain, which time and which version?

First establish that there is a digital signature to check
A handwritten mark pasted into a page is visible artwork. Its appearance does not establish that the PDF contains a certificate-based digital signature. Open a preserved copy in an updated PDF reader that supports signature validation, then look for its Signatures panel. If the panel lists nothing, record that observation for that reader and file. Do not promote a photograph of a signature into cryptographic evidence.
Keep the downloaded original, its source URL and collection time. Work on a separate copy; printing to PDF, flattening or editing a document can change what you are examining. A file hash helps identify the exact original in your notes. It does not perform signature validation.
Read the result, then the properties
In the Acrobat desktop workflow documented by Adobe, open Signatures, choose Options → Validate Signatures, and inspect the validation result. Open Signature Properties and the signer’s certificate for the details behind it. Menu placement can vary by version. These steps follow the official validation guide; this article does not claim a test of your document or installation.
Record the application version and the exact message. “The document is valid” is too broad a note. “Reader X reported this signature valid on this preserved file at this check time” gives another reviewer something they can reproduce. If there are several signatures, make one record for each.
| Check | Record | Keep separate |
|---|---|---|
| Integrity | The reader’s result and any change warning | Whether the document’s claims are true |
| Trust | Certificate subject, issuer and reported trust status | Whether that person had authority for this transaction |
| Time | Displayed time and its stated source | When the underlying real-world event occurred |
| Coverage | The version associated with this signature | Approval of material added in another version |
| Context | Where this exact file came from | Authenticity inferred from a filename or logo |
Unknown trust is a question, not a forgery verdict
The name displayed on a certificate is not the entire trust decision. Adobe’s digital-signature planning documentation explains the role of trusted certificates and trust anchors. A certificate chain must connect to a source the validation environment accepts. A name that looks familiar does not resolve that requirement.
Do not import an unfamiliar certificate as trusted simply to make a warning disappear. That changes an assumption of the check. Save the unresolved result, identify what trust information is missing, and seek confirmation of the signer’s certificate through an independently established channel. For an organisational document, verifying a signer’s role remains a separate task even after technical validation succeeds.
Two machines can reach different results if their verification configuration or available certificate information differs. Adobe documents these controls under signature verification preferences, including revocation checks and the time used for verification. Record the environment instead of weakening its checks to obtain a preferred result.
Ask whose clock supplied the time
Adobe’s timestamp documentation distinguishes the signer’s computer time from a timestamp service. Check the time source and reported trust in the validation details. A plausible date printed on the page is another observation again. Write down the source of the time before putting it into an event timeline.
Offline checks may lack information needed for a complete result. Adobe’s long-term verification guidance describes certificate, timestamp and revocation information needed to support later validation. Missing information is a limitation to investigate, not proof that the signature is fraudulent. Keep the preserved original intact while investigating it.
Find the version that was actually signed
A PDF may contain more than one signed revision. Before treating a signature as approval of everything currently visible, examine its relationship to the current version. Adobe provides Compare Signed Version to Current Version from the selected signature’s Options menu. Its version-comparison instructions explain that workflow.
Use the comparison to identify changes, then read their meaning. A difference is not, by itself, a verdict about malicious editing. Nor does a green result establish that an earlier signer approved a later appendix. If the tool cannot resolve coverage, keep that question open. For ordinary text and layout differences between separate files, use the broader PDF version comparison method.
A fictional example: the signature and the delivery claim
Suppose a supplier sends a signed inspection report with a later delivery appendix. This is a constructed training scenario, not a client case. Your notes say that the reader validates one signature, trusts its certificate chain and identifies the signed revision as the inspection report before the appendix was added. The supplier argues that the signature proves the goods reached the buyer.
That conclusion skips two steps. First, the earlier signed revision does not establish approval of the later appendix. Second, even a signature covering a delivery statement would not independently establish that delivery happened. The statement still needs appropriate corroboration.
A defensible report sentence would be: “The reader validated the signature on the earlier inspection revision. The delivery assertion appears in a later appendix and is not established by that result. Receipt of the goods remains unverified.” This identifies the supported observation and the unresolved claim without accusing anyone of forgery.
Leave a record another reviewer can follow
Attach a concise validation note to the research file: original hash, source and collection time; reader and version; check time; signature identifier; exact status; certificate subject and issuer; time source; signed revision; differences requiring review; and the claim still needing corroboration. Screenshots help communicate a result, but keep the PDF and readable notes alongside them.
If the next step is a wider investigation into the issuing organisation or the document’s claim, use the OSINT Jet investigation brief to state that question precisely. “Check whether this report supports delivery on this date” is a useful scope. “Make the signature green” is not a research objective.
Published 2026-11-03 · OSINT Jet editorial team
