Issue

Pega Platform™ accepts and stores any uploaded file, including password-protected or permission-restricted PDFs, without inspecting the file's protection state at upload time. When such files are forwarded to a downstream document processing service through a custom integration, two failure modes occur: the service fails to parse open-password PDFs entirely, and permission-restricted PDFs transfer successfully but cannot be validated by the receiving team. No out-of-the-box platform capability exists to detect either condition. 

Symptoms and Impact

Two distinct behaviors are observed when protected PDFs are uploaded as case attachments and forwarded through a custom integration: 

1. Open-password PDFs (requiring a password to open) — the downstream service fails during processing and returns an error indicating that no pages can be detected in the file. 
2. Permission-restricted PDFs (no open password, but with restrictions on actions such as copying, editing, or signing) — the file transfers to the downstream service without error, but the receiving team cannot validate the content because the document remains protected on the viewer side. 

In both scenarios, the failure occurs outside Pega Platform, within the custom integration layer and the downstream service. This is expected behavior, not a product defect. 

Steps to Reproduce

1. Open a case and navigate to the Case Attachments case-wide action. 
2. Upload a PDF that is password-protected for opening (an open-password PDF). 
3. Submit the case action to trigger the integration that forwards the attachment to the downstream service. 
   • Result: the downstream service returns an error, and the attachment is not processed. 

To reproduce the second scenario, repeat steps 1–3 using a PDF that carries only permission restrictions (no open password). The file transfers without error, but the content is not accessible to the receiving team. 

Root Cause

Pega Platform treats uploaded files as opaque binary streams. The platform does not parse PDF structure or inspect PDF encryption headers during the attachment upload flow. As a result: 

• A PDF encrypted with an open password is stored and forwarded as-is. When the downstream service attempts to parse the file, it encounters an encrypted byte stream with no readable page content and fails. 
• A permission-restricted PDF (using a PDF owner password to restrict operations but not requiring a password to open) is readable as a byte stream, so it transfers without error. The restrictions are enforced by the PDF viewer, not by the transport layer, which is why the receiving team has difficulty with it. 

Detection of these two conditions requires custom development. This applies to PDF password protection and document encryption in Pega broadly — neither is handled out of the box. 

Solution

Since this is a custom integration design requirement rather than a platform defect, the recommended approach is to add a pre-processing validation step to the integration flow, before the downstream service call, to detect the attachment's protection state and branch accordingly. 

The recommended design pattern is: detect and route, not decrypt or unlock. Attempting to remove PDF protection within the platform is not recommended due to security, document-integrity, and compliance risks. 

Conceptual flow design: 

1. After the attachment is identified for forwarding, retrieve the attachment stream using pyRequestAttachmentPage. 
2. Add a custom Java step (in an Activity or a Utility shape) that reads the PDF header bytes to determine whether an open password is required or whether owner-level restrictions are present. The Apache PDFBox library, available in Pega Platform '24.2.x, can be used for this inspection without requiring a full parse of the document. 
3. Based on the result, branch the flow:
   • Open-password PDFs — reject the file at this step, display an informative message to the user, and do not pass the file to the downstream service.
   • Permission-restricted PDFs — allow the file to proceed to the downstream service and include a flag or notification for the receiving team indicating that the document carries permission restrictions. 

This approach prevents downstream failures, gives users actionable feedback at the point of upload, and avoids the compliance risk of attempting to manipulate protected documents within the platform.

Additional considerations 

• Do not attempt to decrypt or strip PDF protection within Pega Platform. This approach creates security and compliance exposure and is outside the intended use of the platform's document handling capabilities. 
• The detection logic described above is custom application code. Design, development, and testing fall outside the scope of Pega Support. Pega Community Forums is the appropriate venue for implementation guidance and peer review. 
• Storage of protected PDFs as case attachments is technically possible and not prevented by the platform. Whether it is appropriate depends on the organization's security, privacy, and compliance policies — particularly where protected documents may contain personally identifiable information or regulated content. 
• If the downstream service has its own requirements about file format or protection state, those requirements should be validated upstream (before the Pega integration call) rather than relying on the service to return meaningful errors after the fact. 

References

Considerations for ingesting documents, extracting data, and populating cases 

 Controlling access to case attachments 

Configuring external temporary storage options for attachments in offline mode 

PGP Encryption of documents in Pega – Solution – Pega Forum