How to remove Sensitivity restriction when none has been set, and print password protected docx

Question

How to remove Sensitivity restriction when none has been set, and print password protected docx

Peter W 0

If I try to print a password protected docx from iphone or ipad in Word I get a sensitivity block. Opening the document on the Mac in Word shows no label or block.

I trried creating a new document using the pasted contents of the original, and set a simple password to open it. Same problem. Will not print due to sensitivity label, which has not been set.

This is new, is it iOS26.6 or what?

0 comments

2 answers

Your answer

Answer 1

Peter W 0

Thank you.

Already tested 1 and 2. Applying a password (can only be done in Mac) to any docx will turn on the apparent sensitivity label in iOS and iPadOS, ie will not print on phone or ipad.

3, no sensitivity setting exists in Home to turn off.

4, latest version 2.112.4 installed

5, can't test but reported to apple feedback and Word feedback

Peter W 0 Reputation points

2026-08-22T15:41:03.14+00:00

A couple of others in MacRumors forum have tested it and it seems to be a new Word for ios bug

Answer 2

Allan Solomon Mejia 8,000

Hello @Peter W

If the document shows no sensitivity label in Word for Mac, but Word on iPhone/iPad blocks printing specifically because of sensitivity, I wouldn't assume that a label was actually applied. Office for iOS has built-in sensitivity-label handling, and Microsoft notes that behavior can vary between Office platforms.

The important clue is that this also happens with a new document after you enable “Password to Open.” That suggests the issue may be related to how Word for iOS is interpreting the document's encryption/protection rather than a visible sensitivity label.

I would test the following:

Create a completely new .docx with no password and try printing it from the iPhone/iPad.
Add the password protection to the same document and test again.
Check Home > Sensitivity in Word for iOS itself rather than relying only on what Word for Mac displays.
Update Word from the App Store and test after signing out/in to the Office account.
If an unprotected document prints but the identical password-protected document doesn't, that strongly points to an iOS Word protection/printing interaction rather than the printer itself.

Microsoft documents that printing can be restricted when Office considers a document protected by sensitivity/encryption policies, but I don't see documentation confirming that iOS 26.6 intentionally treats ordinary password-protected Word documents as sensitivity-labeled documents.

So if the above A/B test reproduces it consistently, I'd consider this potentially a Word for iOS issue/regression and report it through Word > profile/account > Help & Feedback, including the Word app version and iOS/iPadOS version.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Allan Solomon Mejia 8,000 Reputation points

2026-08-15T19:50:13.1566667+00:00

Hello @Peter W

Please let me know if you need any further assistance. Otherwise, if the information provided has resolved your issue, please consider clicking “Accept Answer” to help others who may encounter the same problem.

Thank you!
Allan Solomon Mejia 8,000 Reputation points

2026-08-22T16:37:49.6333333+00:00
Hi @Peter W

Thanks for confirming, and the additional testing from other users is useful.

Based on what you've described, I agree that this increasingly looks like a Word for iOS/iPadOS regression rather than an actual sensitivity-label configuration issue.

The strongest indicator is your reproducible sequence:

Normal .docx → prints successfully

→ Add "password to open" in Word for Mac

→ Open the same document in Word for iOS/iPadOS

→ Word reports a sensitivity-related restriction

→ Printing is blocked

Microsoft documents password protection and sensitivity/IRM protection as separate protection mechanisms. Password encryption is configured through Word's document-protection functionality, whereas sensitivity labels can apply Microsoft Purview/IRM protection and printing restrictions.

More importantly, Microsoft's mobile compatibility documentation indicates that Word mobile supports password-protected documents, and Word for iPhone normally supports printing.

So simply applying a password-to-open shouldn't cause Word for iOS to treat an otherwise unlabeled document as though an IRM/sensitivity policy prohibits printing.

Since you've also confirmed:

no sensitivity label exists on the document;

recreating the document produces the same behavior once a password is added;

you're using Microsoft 365 Home, so there isn't an organizational sensitivity policy to disable;

multiple users can reproduce it;

the behavior appears to have started recently;

I wouldn't recommend modifying sensitivity settings or removing document security as the "solution." The evidence points more toward Word for iOS/iPadOS incorrectly handling or classifying password-encrypted .docx files during the print operation.

Microsoft's current list of sensitivity-label issues doesn't appear to document this specific password-protected Word → false sensitivity restriction → printing blocked on iOS/iPadOS scenario.

For now, the practical workaround would be to print the password-protected document from Word for Mac/Windows, or temporarily work from an unprotected copy where appropriate. I would avoid weakening protection on the original document solely to accommodate the mobile printing issue.

Since you've already submitted feedback to both Apple and Microsoft, I'd continue with the Microsoft report and include the exact Word version, iOS/iPadOS version, device model, and a minimal test .docx that reproduces the issue. That should make it much easier for the Word team to reproduce.

Sharing these references with you:

Microsoft - Protect a Word document with a password

Microsoft - Known issues with sensitivity labels in Office

At this point, I think you've done enough testing to rule this out as a normal sensitivity-label configuration issue. It looks reproducible enough to warrant investigation as a Word for iOS/iPadOS bug.

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.