A simple, affirmative answer to the question „Is the data encrypted?” should not be enough for CISOs and IT directors. When answering this question, it is more important to determine: Who manages the keys, who has access to them, and can the organization demonstrate this during an audit?.
In this article, we describe three models: PMK, CMK, and Microsoft Purview Customer Key. Without scaremongering or pushing the „strongest” encryption option everywhere. The point is to match the level of security to the risks, regulations, and the organization’s operating procedures.
It’s also worth remembering that key management in Microsoft 365 and Azure is just one component of a broader data protection policy. In practice, organizations also secure endpoints, databases, applications, email, archived data, and data in transit. They also use anonymization and pseudonymization processes, which may alter encryption requirements. Here, we focus on the Microsoft 365 and Azure layer, particularly on the PMK, CMK, and Customer Key models.
Data Encryption in Microsoft 365 and Azure: What Works by Default
Microsoft Purview Information Protection uses AES256-CBC as the default encryption mechanism for protected documents and messages in Microsoft 365 applications. Microsoft had announced the switch to AES256-CBC as the default encryption mode for apps using Microsoft Purview Information Protection, and Microsoft’s technical documentation indicates that by October 2023, AES256-CBC had become the default for encrypting documents and messages in Microsoft 365 Apps.
In Azure, services can use various key management models: ranging from platform-managed keys to customer-managed keys in Azure Key Vault or Azure Managed HSM, to scenarios that provide greater control on the part of the organization. Microsoft describes CMK as a model in which the customer owns and manages the encryption key in Azure Key Vault or Azure Managed HSM.
In other words: By default, encryption of your data is enabled. The real question is whether a model in which Microsoft manages the keys is sufficient for your organization, or whether you need to take greater control over the keys.
PMK, CMK, and Customer Key—how do they differ?
When it comes to cloud encryption, it's easy to get bogged down in acronyms. The simplest way to think of them is as three levels of control.
PMK – Platform Managed Keys
For the IT team, this is the simplest option because it doesn't require a separate Azure Key Vault architecture, rotation procedures, or additional operational support. Users work as usual, and encryption runs in the background.
For many companies, PMK is more than enough. This is especially true when an organization has no specific regulatory requirements regarding key management.
The limitation is clear: the data is encrypted, but you do not manage the master keys. If an audit, a regulator, or an internal security policy requires control on the client side, you should consider CMK or a Customer Key.
CMK - Customer-Managed Keys in Azure
Microsoft describes CMK as a model in which the customer owns and manages key encryption key in your Azure Key Vault or Managed HSM, and Azure services use this key to protect the keys that encrypt data using envelope encryption. For hardware-protected keys, Microsoft recommends Azure Key Vault Premium or Azure Managed HSM.
CMK gives you more control over:
- access to the key,
- an audit of operations,
- by rotation,
- separation of duties,
- compliance requirements,
- procedures for discontinuing services or data.
In summary: CMK is stepping up oversight, but it is also increasing accountability.
Microsoft Purview Customer Key
Microsoft describes Customer Key as a solution that complements BitLocker and server-side encryption in Microsoft data centers and helps meet compliance requirements by providing control over root encryption keys at the application level.
This solution makes sense primarily in situations where an organization needs to demonstrate additional control over data at rest—for example, in regulated sectors, when dealing with particularly sensitive data, or as part of a data sovereignty policy.
Important: The Customer Key does not mean that „all data security” is solved by a single mechanism. It is an additional layer of cryptographic control. You still need a robust model for access control, data classification, DLP, data retention, and auditing.
When Is Microsoft's Default Encryption Enough?
In many organizations, getting the basics in order first will yield better results:
- MFA and Conditional Access,
- administrative roles,
- data classification,
- sensitivity labels,
- DLP,
- retention,
- sharing controls,
- monitoring and auditing.
CMK and Customer Key can supplement a data protection policy, but they cannot replace information classification, DLP, access controls, retention policies, endpoint protection, or a well-designed anonymization or pseudonymization process.
When should you consider CMK or Customer Key?
CMK and Customer Key make sense when the need for greater control stems from a specific requirement. The notion that „having your own key feels more secure” is not a good reason to implement CMK.
1. Regulatory Requirements
In this case, the question is not, „Does Microsoft encrypt data?” but rather, „Can the organization demonstrate how it controls keys and access to data?”.
2. Data Sovereignty
This is not always a statutory requirement. Sometimes it is part of an internal risk model.
3. Exit Strategy and Crypto-Shredding
This is a robust mechanism, but it requires legal, operational, and security procedures. It should not be implemented „on the side.” Microsoft describes Customer Key management—including the creation and assignment of Data Encryption Policies and key management—as a process that requires preparation, permissions, and the appropriate administrative modules.
4. Separation of Duties
A well-designed model helps prevent a situation in which a single person or team has too much control over the entire environment.
What the Customer Key Doesn't Solve
This is important because the importance of security through the use of one's own keys is often overestimated.
- Customer Key will not fix incorrect permissions in SharePoint.
- It will not prevent a user who has legal access to the document from sharing it.
- It cannot replace DLP, sensitivity labels, retention, auditing, or access controls.
- It won't solve the problem of having too many administrators.
- It won't bring order to the chaos in Teams, groups, and sites.
- It cannot replace endpoint protection, disk encryption, or security policies for user devices.
- It will not solve the problem of personal data used in reports, test environments, or integrations—where pseudonymization or anonymization often needs to be considered as well.
This is an additional layer of cryptographic control. It is very useful in certain organizations, but it is not a universal solution for data security.
Encryption, Anonymization, and Pseudonymization—Where Is the Line?
Encryption It protects data by encrypting it. The data remains accessible to individuals and systems that have the appropriate permissions and keys. This is the fundamental mechanism for protecting confidentiality.
Pseudonymization limits the ability to link data to a specific individual without additional information. This additional information should be stored separately and adequately secured.
Anonymous It goes further: once data has been properly anonymized, it should not be possible to link it to a specific person. In practice, this is more difficult than simply removing a first name, last name, or identification number.
That is why, when designing data protection solutions, it is not advisable to choose a mechanism based solely on the name of the technology. First, you need to determine what you are actually protecting: access to data, a person’s identity, data transmission, a database, an application, an endpoint, an archive copy, or a test environment.
What does the implementation of Customer Key look like?
Microsoft notes that Customer Key requires two keys for each Data Encryption Policy. In the Customer Key configuration documentation, Microsoft requires two Azure subscriptions and recommends creating new subscriptions specifically for Customer Key.
In practice, the project includes:
- selection of data and charges covered by the Customer Key,
- Azure Key Vault or Azure Managed HSM project,
- a model of roles and responsibilities,
- Data Encryption Policy configuration,
- tests,
- rotation and emergency procedures,
- monitoring,
- documentation for the audit.
The Greatest Risks of CMK and Customer Key
1. Improper handling of keys
Using your own keys gives you more control, but also more responsibility. An error in access, rotation, deletion, or emergency procedures can block access to your data.
Microsoft also describes the availability key mechanism, which supports recovery in certain scenarios but does not replace the organization's responsibility for properly managing the Customer Key.
2. Too broad a scope of implementation
A better approach: Start with the data and workloads that actually pose a higher level of risk or have specific compliance requirements.
3. Lack of operational procedures
A private key is not just a technical feature. It is an operational process.
4. Licenses and Dependencies
Customer Key is not a feature that can be enabled on every plan and for every user without verification. Before implementation, you must check the licensing requirements, supported workloads, and the scope of users covered by the policy. Microsoft notes that once Customer Key is configured, Data Encryption Policies are created and assigned to control the encryption of data at rest in Microsoft 365.
How can I get started without dragging out the project?
The best way to start is with a brief assessment of your requirements and data. Before you choose between PMK, CMK, or Customer Key, answer a few questions:
- Which data have the highest classification level?
- Where are they stored: Exchange, SharePoint, OneDrive, Teams, Azure SQL, Storage, or other services?
- Do the requirements apply to the entire tenant or to selected areas?
- Does the project also need to include databases, applications, email, end-user workstations, or archived data?
- Is integration with PKI or HSM required?
- Does the project also involve the anonymization or pseudonymization of data?
- Who will own Azure Key Vault or Azure Managed HSM?
- How does key rotation work?
- What is the emergency procedure?
- What supporting documents do you need to show the auditor?
- What licenses are available?
- Which risks are real, and which are merely theoretical?
Only after conducting this analysis should you decide whether Microsoft’s default encryption is sufficient, or whether you need a model with client-managed keys—or perhaps a broader data encryption policy that also covers endpoints, databases, applications, and email.
Not sure if Microsoft 365's default encryption is sufficient for your organization?
We'll examine where you store sensitive data, what regulatory requirements you need to meet, and whether Customer Keys or CMKs actually make sense in your environment.
How does ISCG help with encryption and key management projects?
We help you choose the right data protection model—from default platform encryption, through CMK and Customer Key, to the encryption of databases, applications, email, and endpoints, as well as integration with PKI and HSM.
In practice, we support organizations in areas such as:
- Microsoft 365 and Azure environment analysis,
- identifying data and workloads that require stricter control,
- selection of a key management model,
- Azure Key Vault or Azure Managed HSM project,
- integration with PKI and HSM,
- encryption of databases, applications, email, and endpoints,
- support in the area of data anonymization and pseudonymization,
- draft of roles and responsibilities,
- configuration of policies and tests,
- preparing rotation and emergency procedures,
- audit documentation,
- post-implementation operational support.
FAQ - Data Encryption in Microsoft 365 and Azure
Yes. Microsoft 365 uses multi-layered data encryption, including at the service and data center levels. Microsoft Purview Information Protection uses AES256-CBC as the default encryption mechanism for protected documents and messages in Microsoft 365 applications.
PMK means that the keys are managed by the Microsoft platform. CMK means that the organization manages the key used to protect the data encryption keys, most commonly in Azure Key Vault or Azure Managed HSM.
It’s not accurate to describe this as a complete „break from Microsoft.” Customer Key gives organizations greater control over root encryption keys at the application level and adds a layer of protection on top of standard encryption.
This must be understood in the context of a specific workload, policies, licenses, and operating model. Microsoft describes the Customer Key as an additional safeguard to help meet compliance and regulatory requirements, not as a replacement for the entire data security model.
In a typical model, the Customer Key is part of the key protection hierarchy, rather than a mechanism in which each file is manually encrypted with the customer's key for every user operation.
Users generally shouldn't notice this as a „slowdown,” but it's still worth testing the project in your own environment—especially with large tenants, multiple locations, and critical workloads.
Losing a key or mishandling it can have serious consequences for data availability. Therefore, Customer Key requires an appropriate architecture, including two keys for each Data Encryption Policy and separate Azure subscriptions.
Not always. It’s often better to apply additional monitoring to specific data, workloads, or user groups.
The scope should be based on data classification, regulations, and risk, rather than on the assumption that „everything must have its own keys.”.
No. CMK and Customer Key relate to cryptographic control and key management.
DLP, sensitivity labels, retention, auditing, and access controls address other risks: who has access to the data, how it is classified, how it is shared, and how long it is retained.
No. Encryption protects data by encoding it, but the data can still be read by authorized individuals or systems that have the correct key. Anonymization is intended to prevent data from being linked to a specific individual. Pseudonymization limits the possibility of identification, but with the use of additional information, it may still be reversible.
No. BitLocker protects data at the disk and infrastructure levels. Customer Key adds a layer of control over master keys at the application level in Microsoft 365 and complements standard service-level encryption. Microsoft describes Customer Key as an additional layer of protection on top of BitLocker and server-side encryption.
Would you like to find out which data encryption model makes sense for your organization?
We will assess whether Microsoft’s default security measures are sufficient, or whether it is worth implementing CMK, Customer Key, HSM, PKI, or additional anonymization and pseudonymization mechanisms—without adding complexity where it does not provide real value.
Learn about our other services
Business applications
Services for applications and turnkey solutions in the area of process digitization and modern work environment.
Full support and optimization of IT infrastructure, ensuring stable development of your business.
IT infrastructure
Security of deployment and maintenance of Microsoft 365 and Azure services that enable flexible management and cost optimization.
