PDF Security: Passwords, Permissions, and Encryption

← Back to Blog

Overview of the PDF Security Model

PDF security is built around a handler-based architecture defined in the PDF specification. When a PDF is secured, a security handler is embedded in the document's encryption dictionary. The handler stores the encryption method, key length, and the encrypted document encryption key (DEK). Viewers must interact with the handler to obtain the key before they can decrypt and render the document.

The standard security handler — used for both password and certificate security — has been part of PDF since version 1.1. It supports two independent password slots and a set of permission flags that control what a reader or viewer may do with the content. Critically, the document content itself (text, images, fonts) is encrypted, but the cross-reference table, trailer, and certain stream lengths remain unencrypted so that conforming readers can open the file structure even before decrypting content.

Two Types of Passwords

The PDF standard defines two distinct password roles, each serving a different purpose:

Document Open Password (User Password)

Also called the user password, this controls whether a viewer can open and read the document at all. If set, the viewer prompts for this password before displaying any content. Users who supply the correct password can view the document subject to whatever permissions the owner has set. If no open password is set, the document opens freely — but permissions may still restrict what can be done.

Permissions Password (Owner Password)

Also called the owner password or master password, this grants unrestricted access. An owner who supplies this password can change the permission settings, remove security entirely, or extract the document. In practice, the owner password is used by the author or publisher to manage the document's restrictions, while the user password is what end recipients see.

Technically, within the encryption dictionary, both passwords are used to encrypt different copies of the document encryption key. The owner password decrypts the key without restrictions; the user password decrypts a copy that has the permissions bitmask applied.

Permission Flags

The PDF encryption dictionary contains a 32-bit permissions integer. Bits 3 through 12 (with some reserved) map to specific capabilities. The full set of permission flags defined by the standard is:

• Printing (bit 3): Allows printing the document. When combined with the high-quality printing flag, this controls whether printing is allowed at all.
• Modifying content (bit 4): Allows modifying the document content other than items controlled by the annotations/forms bits.
• Copying text and graphics (bit 5): Allows copying or extracting text and graphics, including using the Select and Copy commands.
• Adding or modifying annotations (bit 6): Allows adding, modifying, or deleting annotations and interactive form fields. If modifying content is also disallowed, only filling form fields is permitted.
• Form filling (bit 9): Allows filling in interactive form fields even when the modifying content flag is clear. This is a finer-grained permission introduced in PDF 1.5.
• Accessibility (bit 10): Allows extracting text and graphics for accessibility purposes such as screen readers. Deprecated in PDF 2.0; accessibility tools should always be allowed regardless of this flag.
• Document assembly (bit 11): Allows inserting, rotating, or deleting pages, and creating bookmarks or thumbnail images, even when the general modifying content flag is clear.
• High-quality printing (bit 12): Allows printing at the highest quality. If the general printing flag (bit 3) is set but this bit is clear, printing is degraded to low-resolution (150 dpi rasterisation in Acrobat's implementation).

These flags only restrict PDF viewers that honour them. Applications built without security compliance will ignore them entirely, which is one of the fundamental limitations of permission-based PDF security.

Encryption Algorithms

The PDF specification has progressed through several encryption algorithms over the years, each associated with specific PDF versions:

RC4 40-bit (PDF 1.1)

The original PDF encryption algorithm. RC4 with a 40-bit key was the only option in early Acrobat. By modern standards, 40-bit RC4 is entirely insecure and can be broken trivially. Documents encrypted at this level offer almost no real-world protection.

RC4 128-bit (PDF 1.4)

Introduced with Acrobat 5 and PDF 1.4, 128-bit RC4 significantly increased the key size. However, RC4 itself is now considered a broken cipher — it has well-documented statistical weaknesses. While 128-bit RC4 PDFs are not trivially broken, they are not recommended for sensitive data.

AES 128-bit (PDF 1.6)

Acrobat 7 introduced AES encryption with 128-bit keys (PDF 1.6). AES (Advanced Encryption Standard) replaced RC4 as the default and offers significantly better security. AES-128 remains secure for most purposes as of 2026, though AES-256 is preferred for long-term sensitive data.

AES 256-bit (PDF 1.7 Extension Level 3 / PDF 2.0)

AES with a 256-bit key was first introduced as an extension to PDF 1.7 (Extension Level 3, associated with Acrobat 9) and was formally incorporated into PDF 2.0 (ISO 32000-2). This is the strongest standard encryption available for PDFs and is the recommended choice for any document containing sensitive information. PDF 2.0 also revised the password hashing algorithm from the older MD5/RC4-based approach to one using SHA-256, further hardening against brute-force attacks.

Certificate Security (Public-Key Encryption)

As an alternative to password-based security, PDF supports certificate-based encryption using public-key cryptography (X.509 certificates). Instead of a shared password, the document encryption key is encrypted separately for each recipient using their public key. Only the holder of the corresponding private key can decrypt the document encryption key and thus read the document.

Certificate security offers several advantages over passwords: there is no shared secret to manage, different recipients can be granted different permission levels, and certificates can be revoked. It integrates naturally with existing PKI (Public Key Infrastructure) environments, including Windows Certificate Store and smart cards.

The downside is complexity: recipients must have a valid certificate, and the author must obtain each recipient's public certificate before encrypting. In practice, certificate security sees more use in enterprise and government document workflows than in consumer or small-business settings.

Security Policy Templates in Acrobat

Adobe Acrobat supports the creation and reuse of security policy templates, which store a predefined set of security settings — encryption algorithm, permission flags, and password or certificate recipients. A policy can be applied to any document with a single action, ensuring consistency across a document set. Policies can be stored locally or, in enterprise deployments, on an Adobe LiveCycle Rights Management Server (now Adobe Experience Manager Document Security), which adds the ability to revoke access to a distributed document even after it has been sent.

Known Limitations of PDF Security

PDF permissions are an access control layer within PDF readers, not a digital rights management system. Several important limitations apply:

• Screenshots: Any user who can view a document on screen can take a screenshot. PDF permissions have no mechanism to prevent this.
• Print-to-PDF: A user who can print a document (even at low resolution) can print to a PDF printer driver, creating an unencrypted copy of the content. Even if printing is disabled, accessibility tools can sometimes extract text.
• Non-compliant readers: Third-party PDF readers, command-line tools, and libraries may not honour permission flags.
• Password recovery: Password security is only as strong as the password and the encryption algorithm. Weak passwords are vulnerable to dictionary and brute-force attacks.

These limitations do not mean PDF security is useless — it is appropriate for deterring casual misuse and meeting compliance requirements — but it should not be relied upon as the sole control for highly sensitive data.

Removing Security in Acrobat

If you have the owner (permissions) password for a secured PDF, removing the security is straightforward in Adobe Acrobat. Open the document, supply the owner password when prompted (or when accessing security settings), navigate to File > Properties > Security tab, change the Security Method to "No Security", and save the document. The saved file will be fully unencrypted. Without the owner password, Acrobat will not allow security removal regardless of whether the user password is known.