To password protect a PDF report, set an open password with AES-256 encryption, add a permissions password if you want to limit printing or editing, and send the password through a different channel than the file. For a single file, that takes a minute. For a report that goes out every Monday to hundreds of people, it has to happen automatically, which is what we built PBRS, ATRS and CRD to do for Power BI, SSRS, Tableau and Crystal Reports.
TL;DR
- An open password encrypts the PDF. A permissions (owner) password only restricts actions such as printing, editing and copying, so set both when you need both.
- Choose AES-256 whenever the tool offers it, and use a password of at least 12 to 16 characters.
- Never email the password in the same message as the file. Use a separate channel.
- Manual protection works for one file. Recurring BI reports need protection applied at export time, as part of the schedule.
- Our PBRS, ATRS and CRD products schedule, export and deliver BI reports as PDF, and we have step-by-step guides for each platform.
Table of Contents
- Open password vs. permissions password
- How to password protect a PDF report by hand
- Choosing a strong password and encryption level
- Sharing the password without undoing the protection
- Why recurring reports need automation
- How to password protect BI reports on each platform
- A repeatable routine for protected report delivery
- Promo: automate protected PDF delivery with ChristianSteven
- Our perspective
- FAQ
- Sources
Open password vs. permissions password
PDFs use two kinds of password, and mixing them up is the most common mistake.
- Open password (user password): the recipient must enter it to view the file. Only this one actually encrypts the document, according to Proton's guide.
- Permissions password (owner password): controls what a recipient may do after opening. In Acrobat, permissions cover printing, editing, copying and screen reader access. Printing can be set to none, low resolution (up to 150 dpi) or high resolution. Changes can be set to none, page insertion, deletion and rotation, form filling, commenting, or anything except extracting pages.
Two details from the pikepdf security documentation matter in practice. A blank user password means everyone can open the file. And setting a user password while leaving the owner password blank is useless, so always fill in both fields when you use both.
For reports, a sensible default is simple: an open password so only the intended recipient reads the numbers, and a permissions password so the layout and figures are not edited and re-circulated.
How to password protect a PDF report by hand
Manual protection is the right tool when you have one finished file and one recipient. The steps differ slightly by application.
In Adobe Acrobat
- Open the PDF and select All tools, then Protect a PDF.
- Under Advanced Options, select Encrypt with Password.
- Select Yes, then check "Require a password to open the document."
- Enter the password in the Document Open Password field and select OK.
- Re-type it in the confirmation dialog and select OK.
- Review the security message, select OK, and save the PDF so the changes apply.
To restrict printing, editing and copying, choose the options under Permissions, enter a permissions password in the Change Permission Password field, and save. Where the compatibility setting is offered, choose Acrobat X or later for the best security.
On a Mac, with Preview
In Preview, go to File > Export, choose Permissions, turn on "Require Password To Open Document," and save. Since macOS Monterey, Preview can also set a separate permissions password and choose which elements may be modified or printed.
When exporting from Word or another source
Many applications can encrypt the PDF at the moment of export. In Microsoft Word, the PDF export options include an option to encrypt the document with a password. Developer libraries do the same: with Aspose.Slides for Python you set a password and access permissions on the PDF options object before saving. The common thread is that protection is cheapest when applied at creation, not afterward.
Reusing settings with a security policy
Retyping options for every file invites mistakes. Acrobat lets you define password and permission settings once and store them as a reusable policy for multiple PDFs. That reduces effort, but a person still has to open each file and apply it. That is where manual methods stop scaling.
Choosing a strong password and encryption level
Two decisions determine how much protection you actually get.
Encryption. Pick AES-256 whenever the tool supports it. Adobe notes that 128-bit and 256-bit AES are the common encryption types, and Proton also recommends 256-bit AES as the strongest available option. Older RC4 encryption should be avoided.
The password itself. EditionGuard recommends at least 12 to 16 characters and avoiding names, dates and dictionary words. For recurring reports, there is a practical question on top of that: where does the password come from?
| Password approach | Where it fits | Watch for |
|---|---|---|
| One password per report | Single ad hoc file | Easy to forget, easy to reuse |
| One password per recipient | Customer or vendor statements | Needs a lookup source for each person |
| One shared password per team | Internal distribution | Anyone who leaves still knows it |
| Password drawn from a data field | Bursting reports to many recipients | Needs automation to apply it |
The last row is where manual work breaks down: when each recipient needs a different password, nobody wants to encrypt 400 files by hand.
Sharing the password without undoing the protection
A strong password sent next to the file gives you no protection at all. Proton advises sending the password separately, by encrypted messaging, by phone or in person, and never in the same email as the PDF. EditionGuard gives the same rule.
For reports with a regular audience, agree on the password channel once. Share the credential during onboarding, then let the scheduled reports arrive on their own. If you also need to think about how files move between your organization and outside parties more broadly, this overview of secure data sharing for businesses covers the wider picture beyond a single PDF.
Keep in mind what a password can and cannot do. Once a protected PDF is opened by someone with the password, they hold the contents. A password controls who gets in. It does not track forwarding or provide an audit trail, so treat distribution lists with the same care as the password.
Why recurring reports need automation
A finance team that exports a dashboard to PDF every Monday, opens Acrobat, applies a password and emails twelve recipients spends the same hour every week, and one skipped step means an unprotected file in an inbox. Multiply by departments and the manual route turns into a standing risk and a standing cost.
The fix is to move protection into the export itself. Automated delivery tools have the same logic in different forms. Qualys, for example, documents scheduling a report daily, weekly or monthly and emailing it with a password. Command-line converters can attach encryption flags and run unattended from Windows Task Scheduler. Those approaches work for their own product or for one file type. BI environments rarely have one tool. They have Power BI, SSRS, Tableau and Crystal Reports side by side, each with different native scheduling.
That gap is what we designed our software for. PBRS, ATRS and CRD schedule, personalize, export, package and securely deliver Power BI, SSRS, Tableau and Crystal Reports content to licensed or external recipients. Schedules can be data-driven or triggered by events, exports include PDF and Excel, and destinations include email, cloud storage, databases and collaboration tools.
How to password protect BI reports on each platform
The exact steps depend on where the report lives. We have written a guide for each platform.
Power BI
Power BI's built-in subscriptions are designed for sending report snapshots to people inside your tenant. When PDFs go to many recipients, with their own filters and their own passwords, you need a scheduler that handles the export and the protection. Our guide on how to send password protected Power BI PDF reports walks through the setup with PBRS, and this one on emailing Power BI reports as PDF covers the delivery side.
SSRS
SSRS reports can be rendered to PDF on a schedule, and the question is how to get a password on the file. We explain it in generating an SSRS report as a password protected PDF. PBRS covers both Power BI and SSRS.
Tableau
For Tableau, ATRS handles scheduled exports and delivery. See how to password-protect Tableau PDF reports, and for the export basics, how to use ATRS to export Tableau reports to PDF.
Crystal Reports
CRD is built for Crystal Reports. The guide to password-protecting Crystal Reports PDFs covers protection, and automating Crystal Reports PDF delivery shows the scheduling around it. If one report must become a separate PDF per group, see emailing Crystal report groups as separate PDFs.
A repeatable routine for protected report delivery
Whatever the platform, the routine that holds up is the same.
- Decide what each recipient may do. Open only, or open plus print? Set the permissions password accordingly and always fill in the owner field.
- Pick AES-256 and a password of 12 or more characters. Where passwords differ per recipient, store them in a data source, not a spreadsheet on someone's desktop.
- Apply protection at export. A file that is never saved unprotected cannot be mailed unprotected. Our schedulers export, package and deliver in one run, so the PDF is not handled by a person in between.
- Use a separate channel for the password, agreed once with each recipient group.
- Plan for failures. A scheduled report that silently fails is as bad as one that arrives unprotected. Our software includes automated error handling, so a failed run does not go unnoticed.
- Review recipients periodically. When someone leaves a team, change the password or remove them from the distribution.
Promo: automate protected PDF delivery with ChristianSteven
If your reports live in Power BI, SSRS, Tableau or Crystal Reports and the same PDFs go out every week, the manual route is where time and mistakes accumulate. PBRS for Power BI and SSRS, ATRS for Tableau Reports and CRD for Crystal Reports generate, format and deliver the right report to the right person, in the right format, on schedule. We are SOC 2 Type II certified, and licenses come as subscription or perpetual. See the products at ChristianSteven Software.
If you work mainly in Power BI, start with the Power BI report scheduler. Tableau teams can go straight to the Tableau report scheduler, and Crystal Reports users to the Crystal Reports scheduler.
Our perspective
A password on a PDF is a good control, and it is only as reliable as the process around it. In most organizations we talk with, the weak point is not the encryption. It is the Friday afternoon when someone exports a report by hand, forgets the password step, and sends it anyway.
That is why we think protection belongs inside report delivery, not after it. When the schedule generates the PDF, applies the settings and sends it to a defined recipient list, the secure path is also the easy path. Nobody has to remember anything.
Native scheduling in a BI platform was built for a simple job: refresh and send. Enterprise reporting asks for more: personalized filters per recipient, bursting to thousands of people, event triggers, several formats, several destinations. We built PBRS, ATRS and CRD for that larger job, so teams stop stitching together scripts and manual steps to cover it.
Our advice: choose AES-256, set both passwords, send the password separately, and automate the whole chain so that protection is a property of the report, not a task on someone's checklist.
Christian Ofori-Boateng
FAQ
Why can't I password protect my PDF?
The usual causes are a file that is already locked by someone else's permissions password, or a blank owner password when you set a user password, which pikepdf notes is useless. Check that you are saving the file after applying the encryption, because in Acrobat the settings only take effect once you save. If the report comes from a BI platform, apply the password during export instead.
What is the difference between an open password and a permissions password?
An open password is required to view the PDF and is what encrypts it. A permissions password restricts printing, editing and copying after the file is open. Set both for reports that should be read only by the intended recipient and not altered.
Which encryption should I choose?
Choose AES-256 when your tool offers it. In Acrobat, picking Acrobat X or later compatibility gives the strongest security setting. Avoid older RC4-based options.
How do I send a protected PDF report safely?
Send the file by email and the password by a different route, such as encrypted messaging, a phone call or in person. Do not put both in one message. For recurring reports, agree the channel once so the scheduled delivery only carries the file.
Can I password protect scheduled Power BI, Tableau or Crystal Reports PDFs?
Yes. PBRS, ATRS and CRD export and deliver these reports on a schedule, and each platform has its own guide linked above, including Power BI and Tableau.
Sources
- Add passwords and restrict access to PDFs in Acrobat
- Restrict PDF printing, editing, and copying in Acrobat
- Protect PDFs with password security policies
- Password protect PDF and encrypt a PDF for free
- How to use the new PDF features in macOS Monterey's Preview
- How to password-protect PDF files
- How to Password Protect PDF Files in 2026
- PDF security (pikepdf)
- Convert PPT and PPTX to PDF in Python
- Convert XLSX to PDF via Command Line
- Creating Encrypt PDF Reports
- Secure Data Sharing: How to Share Business Data Safely