Publisher CLI Update: Clearer Trust Signals in Acrobat + Configurable Post-Seal Permissions
Stronger verification UX for reviewers, tighter workflow control for teams—still ISO 32000 / PAdES compliant and automation-friendly.
TL;DR
- New verification banner in Adobe Acrobat/Reader: sealed PDFs now display a blue “Certified by Trusted Signatures” ribbon with our issuing CA (Sectigo, EUTL path) visible to reviewers.
- DocMDP controls (explicit): configure what’s allowed after sealing without breaking the seal—e.g., enable signature fields to be added or annotations to be made while preserving content integrity.
- Same automation story: fully scriptable via CLI and CI, same simple upgrade path.
Why this matters (and to whom)
For reviewers, auditors, and clients: the blue “Certified” ribbon + visible CA significantly shortens the “is this legit?” step. You don’t have to dig into the signature properties to understand the trust path.
For teams shipping PDFs in real workflows: post-sealing isn’t binary anymore. You can intentionally allow specific actions (like adding signature fields or annotating) without invalidating the seal—because those allowances are explicitlydefined in the signature’s DocMDP permissions.
For engineering and ops: nothing exotic here—just standards, done right:
- ISO 32000 / PAdES signature profiles
- AATL/EUTL trust path
- Embedded evidence (certificate chain, timestamping metadata, revocation data) for a clean, portable audit trail
What changed inside Acrobat/Reader (before/after)
Before: a generic green check often left reviewers guessing how the PDF was sealed and by whom.
After: Acrobat/Reader shows a blue “Certified by Trusted Signatures” banner and exposes the issuing CA (Sectigo) in the UI, so trust is communicated up-front.
Want a before/after screenshot pair (+ properties view)? Ping us and we’ll share the image set we use in demos.
Configurable post-seal permissions (DocMDP)
Real documents don’t live in a lab. People annotate. Legal asks for a signature line. A counterpart needs to initial a page. Historically, that meant breaking a seal—unless you allowed nothing post-signing (not practical) or everything (not safe).
With this release, DocMDP permissions are first-class in our CLI:
- Allow annotations (comments/markups) without breaking the seal
- Allow adding signature fields after sealing
- Keep the content integrity guarantee intact while enabling these controlled, predictable edits
This maps to the PDF standard’s DocMDP (Document Modification Detection and Prevention) model. In short: the seal encodes which changes are allowed. Anything outside those allowances breaks the certification.
How to use it
| |
There are three policies permitted for the --limit-changes argument, based upon the PDF specification:
| Value | Meaning |
|---|---|
no-changes | Any change will invalidate the seal |
allow-forms | Fields and signatures may be filled in; additional pages may be added |
allow-comments | Fields and signatures may be filled in; comments and additional pages may be added |
See the CLI documentation for more details and guidance on which policy you should apply for your use case.
Verification and validation
In Acrobat/Reader: you’ll see the blue “Certified by Trusted Signatures” banner. Click into the signature properties to view details, including the issuing CA (Sectigo).
In your browser: use our online validator to confirm the certificate chain and timestamp quickly:
FAQ
Does this change our trust path?
No. This release surfaces the same EUTL trust path (Sectigo) more clearly in Acrobat/Reader and exposes DocMDP permissions in the CLI.
Is this “tamper-proof”?
We avoid that term. It’s tamper-evident and standards-compliant: any change outside your allowed DocMDP permissions will break the certification.
What if we want different allowances by document type?
Use per-document or per-workflow configs. For example, contracts may allow signature-fields while reports allow annotations only.
Do we need to change our automation?
No. Existing pipelines continue to work as before. If you want to leverage DocMDP, add --limit-changespolicies as shown above.
Will this affect file size?
Limiting changes will add a few dozen bytes to the file size.
How to upgrade
Update the CLI to the latest version (see the downloads page).
Add DocMDP options (
--limit-changes <policy>) where you need controlled post-seal actions.Validate using Acrobat/Reader and (optionally) our online validator:
If you’d like the screenshot pack (before/after Certified banner + properties view), or a CI-ready config template, reach out and we’ll share.
The bigger picture
This update is part of our push to make document trust obvious to humans and predictable for systems:
- Humans see a clear, Certified banner and recognized CA.
- Systems rely on explicit DocMDP rules and portable evidence (certificate chain, timestamps, revocation data) embedded in the file itself.
No special viewer. No lock-in. Just standards.
New display in Adobe Acrobat
When Adobe Acrobat displays a document you’ve sealed with sealed with the --limit-changes argument, it displays the Signature Bar differently:
Now documents immediately show the name of the signing organization (Trusted Signatures, LLC if you use our certificate; your organization name if you use your own). This makes it easier for recipients to verify where the document came from. If the document has been tampered with in any way not authorized by the seal, they will see this:
If they open the Signature Panel in Acrobat, it will display more information:
When to use these options
We recommend using --limit-changes whenever you’re the producer of a PDF. The way that Acrobat highlights the certification of the file (see above) combined with the extra protections you can apply to the document makes --limit-changes a powerful tool to reduce document tampering and fraud.
Which policy to use
If the document you’re signing should never be modified, like an invoice or the signed version of a contract, simply seal the document with the no-changes policy. Any subsequent change to the document will invalidate the seal.
If your document is a form the consumer needs to fill out and sign, then you include form data and/or signature blocks in the PDF, and you should pass the allow-forms policy when you seal it. Then the user can fill in the form fields you specified and/or sign it, add addenda in the form of additional pages, but make no other changes. If the seal is still present and valid when the document is returned, you know that no unauthorized changes were made.
If your document is a draft contract or other document and you want people to comment on it, then use the allow-comments policy when you seal it. Then they may not add in any structural changes to the document, but may contribute comments back to you.
When you’re consuming a PDF produced by someone else and want to seal it (or if it already has been signed or sealed), you must not use --limit-changes or the resulting PDF will be invalid.
Questions?
Contact us at support@trusted-signatures.com or try the validator at https://trusted-signatures.com/pdf-validator/.