General Availability: Purview Customer Key Using Managed HSM
We are excited to announce the general availability of Purview Customer Key using Managed HSM. This new feature enhances your data security by allowing you to manage and control your own encryption keys using Azure Managed HSM. This release is the result of the efforts Microsoft 365 Data-At-Rest Encryption Engineering team. With Customer Key using Managed HSM, you can: Achieve higher security: Managed HSM provides dedicated, FIPS 140-2 Level 3 validated hardware for key protection, offering enhanced security over standard Azure Key Vaults. Ensure compliance: Meet stringent regulatory and compliance requirements with the advanced security features of Managed HSM. Maintain control: Enjoy full control over your encryption keys, including key lifecycle management, within a highly secure, tamper-resistant environment. Enhance performance: Benefit from the high availability and scalability of Managed HSM for critical workloads. Purview Customer Key now supports three different options for key storage including Standard Azure Key Vault, Premium Azure Key Vault and Managed HSM. For more details about the differences between these options, see How to choose the right key management solution. Start leveraging the enhanced security and compliance benefits of Customer Key using Managed HSM today. For more information, visit Set Up Customer Key or learn more about Azure Key Vault and Managed HSM. With Gratitude, M365 Data-at-Rest Encryption
Client Side Encryption Offering for Office 365 (feature parity with Google Workspace Enterprise)
Hey All - Are there any known plans to have a similar feature set as the recently announced Google Workspace Client Side Encryption for E3 plans or below? I know client encryption is possible at the E5 level with Customer Key and with additional required Azure add-on but the price difference is significant. Previously it was available at a much lower price point with the compliance add-on. Thanks
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! :-)Encrypting and Decrypting sensitive Information in ASP.NET Core
In today’s digital landscape, securing sensitive information is more critical than ever. If you're using ASP.NET Core, you might store configuration settings in appsettings.json. However, hardcoding sensitive data like connection strings or API keys in plain text can expose your application to serious risks.
