Microsoft Purview Sensitivity Labels removed when printing

[Tai-D]

Does anyone know how to stop users removing sensitivity labels (Microsoft Purview) by using Print to PDF?

Users can remove encryption and it doesn't track as an activity in Purview to know their doing it. would be good to block printing to PDF altogether if there's a way to do it

[Stefan - PDF-XChange]

Hello Tai-D,
Welcome to our forums!

I am afraid that the "printing" process creates a new file, and the original labels are lost in such a printing.
So the only way I can think of is if you can make those file non printable so that users can not create the unprotected copies.

Kind regards,
Stefan

[Tai-D]

Hi Stefan, thanks for the advice.
How do you suggest the documents be made unprintable? I tried creating a DLP policy to block print to pdf but it looks like it only works in Microsoft not PDF Xchange.

[Stefan - PDF-XChange]

Hello Tai-D,

I am not sure how Purview Sensitivity Labels work, but when creating a PDF file you can place restrictions on the PDF itself and e.g. prevent printing of the file:
https://www.pdf-xchange.com/knowledgeba ... -be-edited

Kind regards,
Stefan

[Tai-D]

ah, ok. Yeah I don't think it's feasible in a large organization to get every user to manually remove the ability to print. Plus PDFXchange already removed the label from the file when it was pdf'd, so removing ability to print on the pdf won't be effective.

We use Purview sensitivity labels as I'm sure a lot of companies do, but PDFXchange removes the label when printing to PDF. And even if user reapplies the label in Purview, they have to also remove the ability to print the file in order to stop users from removing the label/security protections??

Is this something PDFXchange is looking into?

Appreciate any info or guidance as would be good to stay with PDFXchange if we can.

[Stefan - PDF-XChange]

Hello Tai-D,

This is not really an "issue" or "oversight" but rather how the PDF file format works, and when you "Print" a document - you are creating a new copy. So there's no way for the printer to know that the source document has any security, or for the printing application to know if the printer it is outputting to is a hardware device that will generate pieces of paper with the content, or a virtual printer that will create a new PDF.

So if you want to prevent copying of that info - you will have to prevent the original file from being printable.
If it can be printed (even to paper only) - the paper can then be scanned back into a new PDF file, OCRed - and that will still be an unprotected PDF copy. So the only way to prevent information copying is to control it at the source and prevent the file from being printable at all. Sorry that I can not offer any other solution.

Kind regards,
Stefan

[Tai-D]

I get what you're saying, yes someone can create a printed hard copy.

But it is possible to prevent printing to PDF through a DLP policy, I've tested this with other PDF tools Microsoft and Adobe. Microsoft recognize that this is an issue so they've closed the gap by forcing users to Export to PDF and therefore retain the protections. It just doesn't work with PDF Xchange.

I've asked Microsoft but they've said its a known issue with PDF Xchange and up to third party to address. Is this something PDF Xchange will look into or if using Purview sensitivity labels we need to use a compatible PDF product?

[Stefan - PDF-XChange]

Hello Tai-D,

I've just asked our devs to also take a look at this forum topic and advise! As soon as I have their feedback I will let you know.

Kind regards,
Stefan

[Daniel - PDF-XChange]

Hello,

We have just heard back from the Dev team on this, here is what they had to say:

Looks like they mix Purview Labels and Purview DLP. They have Labels applied to office documents, and when they print to a PDF-XChange PDF file, it will not have these labels applied, because the printer knows nothing about the labels and the printing application does not provide such information.
Please verify if they do what I think.
And what they expect to achieve - print from office to PDF using PDF-XChange and get a PDF with a Purview label from the original office document, or just prevent PDF creation at all, based on Purview DLP settings?

Kind regards,

[Tai-D]

Hi Daniel, thanks for the response.

Yes I am referring to DLP policy when talking about trying to block the ability to Print to PDF. This is the only option i can think of to try and retain the sensitivity label applied on the original Office document.

It would be preferable to not have to block 'print to PDF' but 'export to pdf' seems to be the only way to retain the label and it's protections.

Unfortunately the DLP policy to block 'print to PDF' does not work with PDF Xchange editor.

thanks
Tai

[Daniel - PDF-XChange]

Hello, Tai-D

If the files are coming from another application entirely (such as MS Word), than printing is expected to remove such items. As you mentioned, export to PDF seems to retain them, and that will likely be the only option available to do so.

If the file with these items is already a PDF file, than you should be able to use "save as" to make a copy which retains them. Do I understand correctly that If your DLP is configured to prevent all printing (instead of only preventing print to PDF), our Editor respects that? If so, all is working as intended here.

Generally speaking printing a PDF to PDF is not advisable. The conversion process to a "physical friendly format" and back is quite destructive to digital elements like security, links, etc. Beyond that, there is no concept/method in our software for detecting when a print process is a "print to PDF" action specifically. All print actions are simply "send to target printer"; we expect a physical printer is used, because your file is already a PDF, and there is no need to reprint it to PDF when you could "save as" to get a copy.

If preventing all printing is not an option, The best I can suggest is to educate your users that they should not be "printing" anything which they need to retain your Purview labels in, no matter what application it is from.
If they need to duplicate an existing PDF using our Editor, File > Save as (Ctrl_Shift+S) should work nicely instead.

Kind regards,

[Tai-D]

Hi Dan

Re your question "Do I understand correctly that If your DLP is configured to prevent all printing (instead of only preventing print to PDF), our Editor respects that?"

No, the DLP policy is configured to block only 'print to file'. PDF Xchange Editor doesn't respect the DLP policy and still prints the PDF.

But to be clear, the DLP policy is just a workaround to prevent a security breach of someone removing encryption by using PDF Xchange editor (and also the user frustration that their labels are removed). Ideally printing to PDF would simply retain the sensitivity label and in turn continue to enforce any protections the sensitivity label applies.

"Save as PDF" retains the label, as does Print to PDF on other PDF tools, just not PDF Xchange editor.

[Daniel - PDF-XChange]

Hello, Tai-D

Okay, yes that is all expected.
The MS Print to PDF printer is in a special state (being a native part of the OS), it has some unique integrations with these kinds of features. Sadly, most third party printers, like ours, are not able to "sign-in as you" in order to apply these policies to newly created files automatically, beyond that, the Editor has no way to feed that data to a printer. My assumption is that MS Office uses an external method to communicate a copy of, and re-create that data in the new file, since it should not be part of standard printing data.

At the moment, the current handling is the best that we can present. We are looking to make improvements in the future, but I cannot promise a swift timeline on any changes in this area.

Kind regards,