Reference:  https://docs.microsoft.com/en-us/microsoft-365/compliance/double-key-encryption?view=o365-worldwide

So many questions!

Many companies struggle when it comes to storing sensitive data in cloud services, partly because of security concerns.  Over the years, Microsoft has taken steps to introduce various service level protections in their cloud service like Bitlocker and TLS.  Then Microsoft introduced a concept called BYOK (Bring your own key) which allowed companies to generate a certificate in an Azure Key Vault that can be used to encrypt data hosted in M365. 

While this was a good first step, the challenge with this BYOK construct is the key needed to be loaded into an HSM (High Security Module) that Microsoft hosts in Azure known as the Azure Key Vault.  When that key is uploaded, the certificate is altered in a way that makes it proprietary to the Azure Key Service, so the company loses control on the revocation ability and has to rely on Microsoft’s Azure Key Vault Service to revoke certificates. 

And, when companies sign up for the BYOK service, Microsoft generates a private service key that is loaded in the tenant to protect from service outages.  This also protects the service in the event the keys inside the key vault are accidentally revoked or deleted, or become unavailable for any reason.  It is important to note that Microsoft’s intention for BYOK is to allow companies to revoke the keys when exiting the service entirely.  It’s not meant to provide true data encryption at the product level.

Basically, when it comes to the “Trust but Verify” model, BYOK still relies on Microsoft Internal security controls, company reputation, and negotiated contract terms to protect data.  While there are some technology controls available to monitor key usage, they are somewhat limited and cannot be used to enforce controls programmatically.

Now Microsoft has introduced Double Key Encryption (DKE) which is currently in Public Preview.  The documentation provided is a bit scarce on how it actually functions, but we can deduce that this encryption construct is triggered by a custom data label.  This means that when that custom label is applied to a document or an email, that action will call a new service URL that applies a layer of encryption using a separate encryption key.  It’s not clear whether or not Microsoft intends to support this new service to be hosted outside of Azure at this point; theoretically, this new DKE service can be hosted anywhere and the data can be completely obfuscated from M365.  Data classification labels can be published in Microsoft Office, SharePoint, and Exchange Online.

It’s important to keep in mind that completely obfuscating data from cloud services does not come without potentially negative side-effects.  There will likely be limited analytics on that data and the search will be limited to high-level document attributes, so companies will really need to think through the use-cases on where to apply DKE.

All-in-all, this evolving data security strategy from Microsoft is promising, and I’m personally looking forward to seeing how this DKE strategy can be used to meet complex data security requirements.