PDF security best practices — encryption, signatures, audit trails

The three layers of PDF security

PDF security is a stack of three independent layers, defined in the ISO 32000-1 specification.¹ Each protects against a different threat, and each requires a different mechanism. Confusing them is the root cause of most "secured" PDFs that are not.

1. Encryption — protects against unauthorised reading. The file is encrypted with a symmetric cipher; the document cannot be opened without the key. Set by a "user password" (sometimes called the open password). This is the only layer that actually prevents a determined reader from accessing the content.
2. Permissions — protects against unauthorised actions. Flags in the PDF metadata indicate which actions (print, copy, modify, annotate) are permitted. Enforced voluntarily by PDF readers; ignored by tools that do not respect them. Useful as a hint, not as a guarantee.
3. Signatures — protect against undetected tampering. A cryptographic signature over the document content detects any subsequent modification. Does not prevent reading or copying; only proves whether the document has been changed since signing.

For a confidential document, the right combination is usually encryption + signatures. Permissions add a small marginal benefit at no cost but should never be the primary security control.

Encryption — which algorithm to use

PDF supports four encryption algorithms across its history. Only one of them is the right choice in 2026.

AES-256 (handler V5, AESV3) is the modern default — FIPS-197 approved, aligned with NIST SP 800-175B guidance for symmetric encryption, and the algorithm used by PDF/A-4 and ISO 32000-2.² Use ScoutMyTool's Protect PDF tool with the AES-256 setting to encrypt with a strong, unique passphrase.

Permissions — useful, but not security

PDF permission flags specify which actions a reader is allowed to perform on an encrypted-but-open document. The six standard flags:

The recurring theme above is that permissions are advisory. Adobe Reader, Foxit, and most commercial readers respect them; many other tools do not. If the content is sensitive enough that you would care about it being copied, encrypt with a user password and rely on the encryption — not the permission flag — to keep it safe. Treat permissions as the equivalent of a "Do Not Photocopy" stamp on a paper document: signals intent but does not stop a determined recipient.

Signatures — five flavours and when to use each

"Sign a PDF" can mean five different things depending on the legal weight you need the signature to carry. The differences matter for contracts, regulatory filings, and any document where signature authenticity could later be disputed.

For routine business contracts, a simple e-signature applied with ScoutMyTool's Sign PDF tool is legally valid under the US ESIGN Act and EU eIDAS's "simple" tier.³ For higher-risk or EU-regulated workflows, an Advanced or Qualified electronic signature is required. PAdES (defined by ETSI EN 319 142) is the PDF-specific standard that wraps Advanced/Qualified signatures in a long-term-verifiable PDF structure.⁴

Audit trails — Certificate of Completion

For multi-party workflows, the signed PDF alone is rarely enough evidence of intent and timing. SaaS signing services (DocuSign, Adobe Sign, Dropbox Sign) supplement the signature with a Certificate of Completion — a structured audit-trail document naming each signer, when they were sent the file, when they viewed it, when they signed, the IP address and email used, and a SHA-256 hash of the final document. The Certificate is appended to the signed PDF, either as an additional page or as an embedded file.

For contracts under $10,000 between known parties, the email thread carrying the signed PDF is usually sufficient audit trail. For higher-value contracts, regulated transactions, or cases where the counterparty might later dispute, the SaaS workflow certificate is worth the subscription cost. ScoutMyTool's browser tools do not produce a workflow Certificate of Completion — that is a deliberate scope choice; if you need one, use DocuSign or Adobe Sign for those specific documents and use ScoutMyTool for everything else.

Watermarks — confidentiality theatre, with limits

A "CONFIDENTIAL" watermark on every page tells the recipient that the document is sensitive and creates a paper-trail context for any subsequent leak. It does not technically prevent copying or distribution — the recipient can crop the watermark out with a few minutes of work. Treat watermarks as legal-deterrent rather than technical-security: useful for setting expectations, useful in court as evidence that the recipient was on notice, not useful as a barrier against a motivated adversary. ScoutMyTool's Add Watermark and Confidentiality Stamp tools handle the workflow.

A complete "secure PDF" workflow

1. Scrub metadata. Author, title, keywords, custom properties — clean them or sanitise them before encrypting. Encryption protects the content but does not change the metadata under the hood.
2. Strip embedded files and JavaScript. If the document does not need them, remove them. Embedded files can carry the unredacted source; JavaScript can hide malicious payloads.
3. Apply digital signature (if required). For documents where tampering detection matters, sign with a certificate-based signature (PAdES for EU workflows; AES-256 hash + standard PKI signature elsewhere).
4. Apply watermark (if appropriate). Confidentiality stamp, recipient identifier ("Prepared for X"), or "Do not distribute". Sets expectation; creates a paper trail.
5. Encrypt with AES-256. Use Protect PDF with a strong unique passphrase for the user password. Optionally set an owner password and permissions, with the understanding that permissions are advisory.
6. Deliver the passphrase out-of-band. Never email the encrypted PDF and its passphrase in the same channel. SMS, voice call, a different email account, or a credential-manager share are all acceptable alternatives.

Related ScoutMyTool tools and articles

• Protect PDF — encrypt with AES-256 and set permissions.
• Unlock PDF — remove encryption when you have the key.
• Sign PDF — apply a simple e-signature to a document.
• Add Watermark — confidentiality watermarks on every page.
• Confidentiality Stamp Overlay — stronger confidentiality marking for legal docs.
• PDF Metadata — inspect and scrub document metadata.
• Permanent Redact PDF — remove sensitive content before encrypting.
• PDF redaction guide — sister article on the redaction step.
• DocuSign free alternatives — for signing workflows that need a Certificate of Completion.

Frequently asked questions

What is the difference between a PDF user password and an owner password?

A user password (sometimes called the "open" password) prevents the PDF from being opened without entering the password — the document is encrypted, the file is unreadable without the key. An owner password (sometimes "permissions" password) does not block opening; it locks the permission flags that govern printing, copying, editing, and annotating. The document opens normally but, in a permission-respecting reader, the disallowed actions are greyed out. The two passwords are independent and can be combined: setting both produces a file that needs the user password to open and the owner password to override permissions.

Are PDF permissions actually enforced?

Only by readers that choose to respect them. The permission flags are part of the PDF object metadata, but enforcement is voluntary — any reader can ignore them. Adobe Reader, Foxit, and most commercial tools respect the flags. Open-source tools that ignore the flags exist and are easy to find. The practical takeaway: permissions are advisory, not security. If the document content is genuinely sensitive, encrypt with a user password (open password) so the file cannot be read at all without the key, rather than relying on permissions to restrict what the reader can do.

Should I use RC4 or AES for PDF encryption in 2026?

AES-256, always. RC4 was the original PDF encryption algorithm and is now broken: RC4 40-bit can be recovered in seconds with off-the-shelf tools, RC4 128-bit has known statistical biases that have led to its deprecation by NIST. AES-128 is acceptable but AES-256 is the modern default — FIPS-197 approved and aligned with NIST SP 800-175B guidance for symmetric encryption in 2026. The PDF/A-4 standard uses AES-256; PDF 2.0 (ISO 32000-2) adds the V5 / AESV3 handler that implements it. Any tool worth using in 2026 defaults to AES-256.

What is the difference between an e-signature and a digital signature?

An "e-signature" is the legal-document term for any electronic mark made with the intent to sign — a typed name, a drawn squiggle, a checkbox tick. A "digital signature" is the cryptographic term for a signature backed by a public-key infrastructure — the signer holds a private key, the document is hashed and the hash encrypted with the private key, and any reader with the matching public key can verify the signature mathematically. All digital signatures are e-signatures; not all e-signatures are digital signatures. Under the US ESIGN Act and EU eIDAS "simple" tier, a non-cryptographic e-signature is legally valid for most business contracts. For higher-evidentiary-value scenarios — EU public-sector, regulated industries — a digital signature (specifically an Advanced or Qualified electronic signature) is required.

What is a PAdES signature and when do I need one?

PAdES (PDF Advanced Electronic Signatures) is a profile of the Advanced Electronic Signature standard specifically for PDFs, defined by ETSI EN 319 142. A PAdES signature embeds the cryptographic signature inside the PDF in a way that supports long-term validation — the signature, the signer's certificate, and the chain-of-trust evidence are all stored in the PDF itself, so future verifiers can confirm the signature was valid at the time of signing even if the certificate authority later disappears. Required for some EU public-sector workflows and recommended for any signed PDF that needs to remain verifiable over a long period (legal contracts, official records).

What is a "Certificate of Completion" and is it different from a digital signature?

A Certificate of Completion is an audit-trail document produced by SaaS signing services (DocuSign, Adobe Sign, Dropbox Sign) that records the workflow: who was sent the document, when each party viewed it, when each signed, the IP and email of each signer, and a hash of the final document. It is appended to the signed PDF as a separate page or as an attachment. It is not itself a digital signature — the actual signature on the document may be a simple e-signature (drawn or typed) or an Advanced electronic signature. The Certificate provides the audit-trail evidence; the signature on the page provides the visible mark. For dispute resolution, the combination of both is what carries weight.

What are the realistic threats to a PDF?

Six common categories. (1) Unauthorised reading — solved by encrypting with a user password (AES-256). (2) Tampering — solved by digital signatures that detect subsequent changes. (3) Content extraction — copy-paste and OCR can defeat permissions-only protection; rely on encryption instead. (4) Metadata leakage — solved by scrubbing metadata before distribution. (5) Embedded-file malware — PDFs can embed arbitrary files including malicious payloads; strip embedded files from received PDFs unless you specifically need them. (6) JavaScript-driven attacks — PDF JavaScript can be exploited; disable JavaScript in your reader if you have no workflow need for it. PDF/A and PDF/A-4 ban JavaScript and embedded files specifically because of these threats.