Securing emails to "regular" users with Information Protection.

 This is a scenario that tend to stop our information protection discussions pretty fast. Cause even though Sensitivity labels are great at securing/labeling info, even when sharing with external parties, this changes immediately when we want to communicate directly with customers in a B2C scenario. Microsoft has showcased the growing support for this if the customer has gmail or outlook and stuff like that, but we cannot assume that this goes for everyone, and even more important: We cannot assume that our customers have tech knowledge.

So, what do we do then? How about those non-business users? If you have any experience with this and want to share them with us, please let me know in the comment section below.


Sensitivity labels

These are great. After Microsoft bought Secure Islands (back in 2016 I believe it was) Rights Management Service (RMS) turned into something with a lot more potential with Azure Information Protection (AIP). This has evolved further into what we know have in our compliance portal. Sensitivity labels. These are a selection of properties (protection/classification/labeling) that can be applied to files, folders, emails, SharePoint libraries, Teams, in Data Loss Prevention, Azure Purview and more. It is truly useful, and best of all when using them to secure our own information, and making sure they are inaccessible to others.

Do Not Forward and Encrypt

If you have Office 365/Microsoft 365 with E3 lever or higher, you may have noticed the protection settings you can set on new emails. We have already talked about these, and how they do have a couple of issues you may want to at least check for. 


Still, they do give us the opportunity to protect our emails in a very easy way without any kind of pre-configuration.

External email to "normal" users

I tried to cover some of this in an earlier post, but things are moving fast, and new functionality is added all the time so how is this today? Well, you can still cross your fingers and hope they have a supported account, but what you normally will not do is create a guest account in Azure AD for all of them unless you already have some sort of B2C setup with the users in there. I am in the process of finding a good solution for a company as we speak, but unfortunately most of our trials so far has left Information Protection as a non-viable solution for these particular scenarios. 

So why this isn't fixed? That is pretty easy to answer. It has to do with how Information Protection uses Azure AD to protect, add/remove access to content etc. If the recipient does not have the prerequisites, ability (or understanding) to use AAD, they will not be able to authenticate, and in the end there are limits to how much we can require a customer to do to be able to read the info we send to them.



Popular posts from this blog

Do not Forward and the protection of attachments

Using Do not Forward or Encrypt Only as the results of a Sensitivity Label