PDF

Fix "Document Has Been Altered or Corrupted Since It Was Signed"

Error message: The document has been altered or corrupted since the Signature was applied

Fix “Document Has Been Altered or Corrupted Since It Was Signed”

Adobe Acrobat is reporting that a digital signature on your PDF is invalid, with the message that the document has been altered or corrupted since the signature was applied. This is one of the more nerve-racking PDF errors — for legal documents, contracts, and audit trails, an invalid signature can be a serious problem. But the warning is worth investigating carefully before assuming the worst. Many cases are not malicious modification at all. They’re hash-algorithm mismatches, certificate trust problems, or save-process artefacts that look like alteration to Acrobat’s strict checker.

First, find out what actually happened

Before any “fix” makes sense, you need to know whether the document genuinely was altered. Acrobat tells you this if you ask:

  1. Open the PDF in Acrobat.
  2. Click the signature panel icon in the left sidebar (it looks like a fountain pen).
  3. Expand the signature entry. The detail view shows:
    • Whether the signature itself is cryptographically valid (was the file’s hash at signing time correctly signed by the certificate’s private key?)
    • Whether the certificate is trusted on this machine (does the certificate chain to a trusted root?)
    • Whether the document content covered by the signature has changed (does the current file match the hash that was signed?)
    • Whether incremental changes have been added after signing (which is allowed but is reported)

Read the detail panel. The exact phrasing of the failure tells you which fix path to take.

If the signature is genuinely invalid because the file was modified

If the signature was valid when the document was signed and is no longer valid now, someone — or some process — changed the file. Options:

  • Get the original signed copy back. If you have an unmodified version (in email, version control, a backup), use that. The signature on the original is still valid.
  • Have the document re-signed. If you control the signing process, the signer can re-sign the current state of the document. The original signature is gone, but a new valid signature replaces it.
  • For legal or audit purposes, treat the signature as void. If the file genuinely was altered after signing and no clean copy exists, the signature no longer attests to anything. Don’t rely on it; document the situation.

If the signature shows invalid right after signing

This is the most surprising case: the document was just signed and the signature appears invalid before anything has been saved or modified. There are several real causes for this, none of which involve actual alteration.

SHA-256 hash with a CAdES-incompatible signature format. Modern signing setups using SHA-256 and certain certificate types produce signatures Acrobat sometimes rejects on the same machine that produced them. The fix is on the signer’s side: change the default signing format.

  1. In Acrobat, choose Edit > Preferences (or Acrobat > Preferences on Mac).
  2. Select Signatures from the Categories.
  3. Under Creation & Appearance, click More.
  4. Set Default Signing Format to CAdES-Equivalent.
  5. Click OK. Re-sign the document.

This resolves a substantial fraction of the “invalid right after signing” cases, particularly with smart-card-based signing where the card middleware (CSP) and Acrobat negotiate the signature format.

Missing certificate revocation status (CRL/OCSP). If the signer’s preferences exclude revocation status from the signature, Acrobat may flag the signature as invalid for long-term verification. Check the signer’s preference:

  1. In Preferences > Signatures > Creation & Appearance > More, check Include signature's revocation status.
  2. Re-sign the document.

Saving to a network location during signing. Saving directly to a network share, OneDrive, or other non-local storage during the signing process can interfere with how the signature is written into the file. Save signed files locally first, then move them to network storage afterwards.

If the signature is invalid because the certificate isn’t trusted

A different failure mode: the signature is cryptographically fine, but Acrobat doesn’t recognise the certificate authority as trusted on this machine. The signature panel will say so explicitly — typically “signed but not validated” or “the signer’s identity is unknown”.

To trust a specific certificate (only do this if you genuinely know and trust the signer):

  1. Open the signature panel and right-click the signature.
  2. Choose Show Signature Properties.
  3. Click Show Signer's Certificate.
  4. Click the Trust tab, then Add to Trusted Certificates.
  5. In the dialog, check Use this certificate as a trusted root and the boxes for the trust scopes you want.

For region-specific trust frameworks (for example, Brazil’s ICP-Brasil), Adobe distributes specific plugins (PAdES ICP-Brasil) that install the appropriate root certificates. Install the plugin from the trust framework’s official distribution rather than configuring trust manually.

What you should not do

Lower Acrobat’s required hash algorithm to SHA-1 via the Windows registry. This workaround appears in some forum threads as a way to make signatures “validate” again — it works by reducing security. SHA-1 is cryptographically broken; using it for signature validation defeats the point of having a signature. Don’t do this, even if you find the registry key documented elsewhere.

Disable signature validation entirely. The signature is there to attest to the document’s integrity. Disabling validation removes the attestation. If a workflow doesn’t actually need signature verification, remove the signature from the workflow rather than disabling validation.

Why this happens

A PDF digital signature works by hashing a defined byte range of the file (recorded in the signature object’s /ByteRange array) at signing time, then encrypting that hash with the signer’s private key. Acrobat verifies a signature by:

  1. Hashing the same byte range of the current file.
  2. Decrypting the stored signature hash with the certificate’s public key.
  3. Comparing the two.

If they match, the document is byte-identical within the covered range to what was signed. If they don’t, something changed. The “altered or corrupted” warning means the comparison failed.

Several non-malicious things can cause the hashes not to match:

  • Re-saving the file with a different PDF tool. Acrobat preserves the byte range; some other PDF tools rewrite the file in ways that change bytes inside the covered range, even if the content is unchanged.
  • Email gateways that re-encode attachments. Some corporate email systems decode and re-encode PDF attachments, which can alter bytes inside the signed range.
  • Version-control or backup systems that touch metadata. Rare but possible with systems that try to “normalize” file metadata.
  • The signing tool itself wrote a malformed signature. Particularly with non-standard CSPs or older PDF libraries that don’t correctly implement the spec.

In all of these cases, the document content is functionally unchanged, but Acrobat’s strict byte-level comparison correctly reports that bytes within the signed range have moved. The signature is genuinely no longer valid in a cryptographic sense, even though no one tried to forge anything. The fix is to obtain or re-create a clean signed copy, not to weaken the validation.

Preventing this in future

If you’re producing signed PDFs, sign at the end of the workflow — after any conversion, optimisation, or normalisation steps. Signing then editing then re-saving is a guaranteed way to invalidate signatures.

Save signed files locally first, then move them where they need to go. Direct save to network storage, cloud storage, or sync folders during the signing operation is a recurring source of “invalid right after signing” reports.

For high-stakes signed documents (contracts, legal filings), keep an unaltered copy of the signed file in a location that doesn’t get touched by other workflows. If the working copy’s signature breaks, the original is still authoritative.

If your organisation regularly signs documents, standardise on a signing format and hash algorithm that matches what your verification audience uses. Mismatches between signer and verifier configurations are the single most common source of the “invalid right after signing” pattern.

This warning is sometimes confused with the Acrobat security warnings about JavaScript or external content — they look similar in the user interface but mean fundamentally different things. The signature warning is about cryptographic integrity; the security warnings are about runtime behaviour the file might attempt. For general PDF damage that isn’t signature-related, see the PDF repair complete guide.

Last verified: April 2026