Extending Protection for Confidential SharePoint Online Files
Sensitivity labels offer great protection against unauthorized access, but sometimes files that aren’t encrypted escape from a document library. SharePoint Online can now use sensitivity labels configured with user-defined permissions (UDP) to extend protection to downloaded files. The magic works by configuring permissions on download based on the membership of the user who downloads a file. https://office365itpros.com/2026/02/26/sensitivity-label-extend-protection/
Encrypted vhdx moved to new host, boots without pin or recovery key
Hyper-V environment. Enabled VTPM on guest Server, 2022 OS and encrypted OS drive C:\ with BitLocker. Host server 2022 has physical TPM. Shut down guest OS and copied vhdx file to another Hyper-V host server that is completely off network (also server 2022 with a physical TPM). Created a new VM based on the "encrypted" vhdx. I was able to start the VM without needing a PIN or a recovery key. Doesn't this defeat the whole point of encrypting vhd's? Searching says that this should not be possible, but I replicated it twice on two different off network Hyper-V host servers. Another odd thing is that when the guest boots on the new host and you log in, the drive is NOT encrypted. So, where's the security in that? Does anyone have any ideas on this or if I'm missing something completely? Or have I just made Microsoft angry for pointing out this glaring flaw??
Outlook Classic for M365 - File > Encrypt > 'Encrypt-Only' option applies 'Do Not Forward' label?
I recently joined a new company and am helping support their M365 tenant and admin duties. I'm running into a very weird issue where no recipients can actually read/view the message when we encrypt emails using only 1 specific method (our organization largely uses the Outlook Classic for Microsoft 365 desktop app). If a user follows this method, for some reason the 'Do Not Forward' label is applied to the encryption, despite specifically selecting 'Encrypt-Only' - it defaults to 'Do Not Forward' every single time: New Email > File > Encrypt > Encrypt-Only Sending emails with this method gives any/all recipients a "You don't have sufficient permissions to open the mail." regardless of where they try to open the email (OWA, Outlook Classic, New Outlook) Yet, if the user tries this other method below - the proper Encrypt-Only label is applied, and any Outlook client immediately and opens/views the email as you'd expect: New Email > Options ribbon > Encrypt properly applies the Encrypt-Only label I verified IRM (Identity Rights Management) is enabled for our tenant: And encryption tests pass with flying colors: Ultimately, I'm at a loss for what's going on here and specifically where to check to fix this issue for this 1 specific encryption method. Poking around in the Purview portal, I'm having a hard time figuring out where these encryption policies/settings lie and how to get this method to stop defaulting to 'Do Not Forward' even though 'Encrypt-Only' is checked.
Outlook Encrypted Email Issues
I have deployed M365DLP controls to block password protected atachments that cannot be scanned and am telling users to use Outlook Encryption instead to protect outgoing email attachments. However, a number of external companies have reported not being able to open the encrypted messages and the screenshots provided show that they are trying to authenticate as a guest user in my Entra ID instance (rather than using their own IdP, SSO or an OTP). What would cause that and how do I resolve?
Compliance licenses at tenant level
Hi, We are a small organization of about 200 employees, and we have following requirements. DLP policies configuration at Exchange, OneDrive, SharePoint BYOD security Users should not be able to send files outside the org And so on as we evaluate We already have M365 Business Premium. However, after researching we figured out that M365 Business premium will alone not solve our requirements. May be compliance license will. We want to apply security policies at tenant level in our organization but definitely do not want every user to get licenses as this will be expensive for us and there is no requirement at all for our users. The question is, Is there a way to solve the above scenario?External people can't open files with Sensitivity Label encryption.
Question: What are the best practices for ensuring external users can open files encrypted with Sensitivity Labels? Hi all. I've been investigating proper setup of sensitivity labels in Purview, and the impact on user experience. The prerequisites are simple enough, creating and configuring the labels reasonably straightforward, and publishing them is a breeze. But using them appears to be a different matter! Everything is fine for labels that don't apply encryption (control access) or when used internally. However, the problems come when labels do apply encryption and information is sent externally. The result is that we apply a label to a document, attach that document to an email, and send it externally - and the recipient says they can't open it and they get an error that their email address is not in our directory. This is because due to the encryption, the external user needs to authenticate back to our tenant, and if they're not in our tenant they obviously can't do this so the files won't open. So, back to the question above. What's the easiest / most secure / best way to add any user we might share encrypted content with to our tenant. As I see it we have the following options: Users have to request Admins add the user as a Guest in our tenant before they send the content. Let's face it, they'll not do this and/or get frustrated. Users share encrypted content directly from SharePoint / OneDrive, rather than attaching it to emails (as that would automatically add the external person as a Guest in the tenant). This will be fine in some circumstances, but won't always be appropriate (when you want to send them a point-in-time version of a doc). With good SharePoint setup, site Owners would also have to approve the share before it gets sent which could delay things. Admins add all possible domains that encrypted content might be shared with to Entra B2B Direct Connect (so the external recipient doesn't have to be our tenant). This may not be practical as you often don't know who you'll need to share with and we work with hundreds of organisations. The bigger gotcha is that the external organisation would also have to configure Entra B2B Direct Connect. Admins default Entra B2B Direct Connect to 'Allow All'. This opens up a significant attack surface and also still requires any external organisation to configure Entra B2B Direct Connect as well. I really want to make this work, but it need to be as simple as possible for the end users sharing sensitive or confidential content. And all of the above options seem to have significant down-sides. I'm really hoping someone who uses Sensitivity Labels on a day-to-day basis can provide some help or advice to share their experiences. Thanks, Oz.
Issues with Sensitivity Labels and "Specific email addresses or domains" - Not working
Hello! We have enabled Sensitivity Labels in our tenant. The access control settings for the label states that a specific domain gets the permission "Co-Author". When we enable the Sensitivity label on a document and sent it towards the approved domain, it results in an error message when authenticating to open the document: "Selected user account does not exist in tenant 'Veni AS' and cannot access the application in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account." After doing some research I did some changes to the external domain within the Cross-tenant settings. The external domain now has the following settings: Inbound access: Allow access on external users and groups, within B2B Collaboration Allow access on external users and groups, within B2B direct connect Trust multifactor authentication from Microsoft Entra tenants, within Trust settings. Outbound access: Allow access on users and groups, within B2B Collaboration Allow access on users and groups, within B2B direct connect External Identities: Block access for external users and groups. (Inherited from default) After doing this change, I no longer get the same error message as above when authenticating to open the labeled document. Now I get the following error message: "You are not signed in to office with an account that has permission to open this document. You may sign in a new account into Office that has permission or request permission from the content owner" I have this working from another tenant to the same external domain and I have cross-checked the settings. Any idea on how to proceed, or if it is any obvious change I need to make in order to get this to work? All feedback appreciated! :-)Microsoft Purview Encryption on Third Party Apps
Hello Community, I’m working with a desktop-based correspondence management system (CMS) application and would like to apply encryption to the documents that are being created, handled, or stored by this application. Specifically, I’m looking to use Microsoft Purview Information Protection to classify and encrypt these documents. Could someone please guide me on: The steps or best practices to integrate Microsoft Purview labels (with encryption) into a third-party or in-house desktop application? Whether Microsoft Purview SDK or API can be used in such scenarios, and if so, what the implementation flow looks like? Any prerequisites or limitations I should be aware of (e.g., licensing, file formats, offline handling)? How to ensure persistent encryption when files are exported from the application (e.g., to network drives or shared folders)?
