A signature can look perfectly at home on a PDF page and still have no verifiable connection to pen, paper, or the person whose name it depicts.
That was the problem with Evidence Item 2 in this insurance dispute. The signer maintained that the document had been “wet signed”—signed on paper and then scanned. Our examination found an embedded signature image and a metadata timeline inconsistent with that account.
In brief: Evidence Item 2 contained a logo and a signature as embedded image objects. The signature image appeared to have been derived from the signature in another document, altered, and placed into this PDF. The file's XML metadata recorded activity on September 7, 2022, more than a year after the date asserted for the document.
This case study omits identifying details. The conclusion concerns the PDF objects examined, not the legal validity of a signature or the identity of the person who placed it.
What “wet signed” should mean in a PDF workflow
A wet-sign workflow usually follows a simple path:
- A person signs a physical document with ink.
- The signed paper is scanned or photographed.
- The resulting image becomes a PDF or is placed into one.
That process commonly leaves the signature as part of a scanned page image. A separate signature bitmap pasted into an otherwise digital document is a different technical event, even if the result looks handwritten.
The terminology can get muddy because “electronic signature” and “digital signature” are often used as though they mean the same thing. They do not.
Adobe describes a basic electronic signature as something that may appear as an image of a handwritten signature. A certificate-based digital signature uses a digital certificate and can support verification of signer identity and document integrity. Adobe: Types of signatures Adobe further explains that certificate signatures can allow recipients to validate authenticity and detect changes in a document's lifecycle. Adobe: About certificate signatures
A picture of a signature may be legally significant in context, but the picture itself is not cryptographic proof. It is an image. Treating the two as interchangeable is like calling a photograph of a key the key itself.
The second PDF had a much shorter internal history
We received two copies of Evidence Item 2. One arrived as a forwarded attachment. The other was preserved inside an EML message container with the associated email content.
Unlike Evidence Item 1, this PDF contained no dates in the native D: format we examined. It did contain XML-formatted metadata, including fields such as creation, modification, and metadata dates. Adobe's Extensible Metadata Platform is designed to embed this kind of metadata in a file. Adobe Acrobat SDK: Metadata and XMP
The recorded activity in Evidence Item 2 centered on September 7, 2022. That was more than a year after the document was represented to have been created.
Absence also mattered. Evidence Item 1 contained a longer sequence of object-level editing activity. Evidence Item 2 did not. Its earlier editing history was unavailable in the file we received.
That did not prove a particular “metadata scrubber” had been used. Files can lose internal detail through several workflows, including export, optimization, flattening, printing to a new PDF, or deliberate sanitization. Adobe's own tools can remove hidden metadata and can flatten content into permanent page elements. Adobe: Sanitize PDFs Adobe: Merge and flatten PDF layers
Missing history is a reason to investigate. It is not a license to invent the missing chapter.
Extracting the embedded images
We used iText RUPS 8.0.0 and PDFStreamDumper 0.9.270 to inspect and extract image objects from Evidence Item 2. Two objects were especially important:
- A logo added to the document
- A bitmap depicting a handwritten signature
The signature was not merely ink captured as an inseparable part of a full-page scan. It existed as an image object within the PDF.
Comparison with Evidence Item 1 indicated that the signature image in Item 2 was likely copied from the Item 1 signature, modified, and placed into the second document. That finding did not identify the person who performed the edit. It did undermine the claimed wet-sign-and-scan narrative for the file we examined.
Why appearance is not enough
On a printed page, a scanned wet signature and a pasted signature image may look nearly identical. Once printed, both are ink on paper. The distinction lives in the native file structure:
- Is the page one continuous scan or a collection of separate objects?
- Does a signature field contain a certificate-based signature?
- Is the visible signature an image stream?
- Do object locations, dimensions, transformations, or compression characteristics reveal placement?
- Do the metadata dates agree with the alleged signing timeline?
- Does another file contain the apparent source image?
Those questions cannot be answered from a screenshot or printout. The native PDF is not a convenience copy. It is the evidence.
What a certificate-based signature can show
A properly implemented certificate-based digital signature can provide evidence that an identified digital ID signed a particular document state. Depending on the implementation, validation can reveal whether the document changed after signing and whether the certificate was trusted at the relevant time. Adobe: Add digital signatures to PDFs
A bitmap cannot provide that cryptographic chain. It may still be supported by email records, witness testimony, audit logs, or other evidence. But the visual mark alone does not carry those assurances.
The distinction is not academic. In litigation, “there is a signature on the page” and “this file contains a verifiable digital signature” are different statements. So is “this page was scanned after signing” versus “a signature image was inserted into the PDF.”
The source computer remained the missing witness
The PDF told us that an image had been embedded and that its internal dates did not align with the claimed history. It could not, by itself, tell us who placed the image or every application used along the way.
The creating computer might have contained:
- The source image from which the signature was copied
- Alternate PDF versions
- Browser or application artifacts
- Download and recent-file history
- Cloud-sync records
- Email attachments and message context
- File-system timestamps and link files
That is why early preservation matters. A source computer can turn a strong document-level finding into a fuller origin analysis. Without it, the examiner must be honest about the gap.
Questions counsel should ask about a disputed PDF signature
When someone claims a PDF was wet signed, ask:
- Where is the original paper?
- What device scanned or photographed it?
- Is the entire page a scan, or is the signature a separate object?
- Does the PDF contain a certificate-based signature field?
- What do the creation, modification, and object dates show?
- Are there earlier or later versions in email, cloud storage, or on the source computer?
- Was the native file preserved, or was only a printout produced?
The answers should fit together. When they do not, the inconsistency is not paperwork trivia. It is the beginning of the forensic question.
If a signature's origin matters to an insurance claim or litigation, Cyber Agents can examine the native PDF, related messages, and available devices while the underlying artifacts still exist. Learn about Cyber Agents' litigation support. To discuss the disputed document and available evidence, contact Cyber Agents.