Encryption risks and protections
Microsoft 365 follows a control and compliance framework that focuses on risks to the service and to customer data. The service implements a large set of technology and process-based methods, referred to as controls, to mitigate these risks. Identification, evaluation, and mitigation of risks through controls is a continuous process.
The implementation of controls within layers of our cloud services such as facilities, network, servers, applications, users (such as Microsoft administrators), and data form a defense-in-depth strategy. The key to this strategy is that many different controls are implemented at different layers to protect against the same or similar risk scenarios. This multi-layered approach provides fail-safe protection in case a control fails.
Some risk scenarios and the currently available encryption technologies that mitigate them are listed in this table. In many cases, these scenarios are also mitigated by other controls implemented in Microsoft 365.
| Encryption technology | Services | Key management | Risk scenario | Value |
|---|---|---|---|---|
| BitLocker | Exchange and SharePoint | Microsoft | Disks or servers are stolen or improperly recycled. | BitLocker provides a fail-safe approach to protect against loss of data due to stolen or improperly recycled hardware (server/disk). |
| Service encryption | SharePoint and OneDrive; Exchange | Microsoft | Internal or external hacker tries to access individual files/data as a blob. | The encrypted data can't be decrypted without access to keys. Helps to mitigate risk of a hacker accessing data. |
| Customer Key | SharePoint, OneDrive, and Exchange | Customer | N/A (This feature is designed as a compliance feature; not as a mitigation for any risk.) | Helps customers meet internal regulation and compliance obligations, and the ability to leave the service and revoke Microsoft's access to data |
| Transport Layer Security (TLS) between Microsoft 365 and clients | Exchange, SharePoint, OneDrive, Teams, and Viva Engage | Microsoft, Customer | Man-in-the-middle or other attack to tap the data flow between Microsoft 365 and client computers over Internet. | This implementation provides value to both Microsoft and customers and assures data integrity as it flows between Microsoft 365 and the client. |
| TLS between Microsoft datacenters | Exchange, SharePoint, and OneDrive | Microsoft | Man-in-the-middle or other attack to tap the customer data flow between Microsoft 365 servers located in different Microsoft datacenters. | This implementation is another method to protect data against attacks between Microsoft datacenters. |
| Azure Rights Management (Azure RMS) (included in Microsoft 365 or Azure Information Protection) | Exchange, SharePoint, and OneDrive | Customer | Data falls into the hands of a person who shouldn't have access to the data. | Azure Information Protection uses Azure RMS, which provides value to customers by using encryption, identity, and authorization policies to help secure files and email across multiple devices. Azure RMS provides configuration options where all emails originating from Microsoft 365 that match certain criteria (for example, all emails to a certain address) can be automatically encrypted before they get sent to another recipient. |
| S/MIME | Exchange | Customer | A person who isn't the intended recipient obtained an email. | S/MIME helps ensure that only the intended recipient can decrypt an encrypted email. |
| Microsoft Purview Message Encryption | Exchange, SharePoint | Customer | A person who isn't the intended recipient obtained an email and its protected attachments. | Message encryption lets you configure your tenant so that emails originating from Microsoft 365 that match certain criteria (for example, all emails to a certain address) are automatically encrypted before they're sent. |
| Simple Mail Transfer Protocol (SMTP) TLS with partner organization | Exchange | Customer | Email is intercepted via a man-in-the-middle or other attack while in transit from a Microsoft 365 tenant to a partner organization. | Allows you to send and receive all emails between your Microsoft 365 tenant and your partner's email organization inside an encrypted SMTP channel. |
Tip
If you're not an E5 customer, use the 90-day Microsoft Purview solutions trial to explore how additional Purview capabilities can help your organization manage data security and compliance needs. Start now at the Microsoft Purview trials hub. Learn details about signing up and trial terms.
Encryption technologies available in multitenant environments
| Encryption technology | Implemented by | Key exchange algorithm and strength | Key management* | Federal Information Processing Standards (FIPS) 140-2 validated |
|---|---|---|---|---|
| BitLocker | Exchange | Advanced Encryption Standard (AES) 256-bit | AES external key is stored in a secret safe and in the registry of the Exchange server. The secret safe is a secured repository that requires high-level elevation and approvals to access. Access can be requested and approved only by using an internal tool called Lockbox. The AES external key is also stored in the Trusted Platform Module in the server. A 48-digit numerical password is stored in Active Directory and protected by Lockbox. | Yes |
| SharePoint | AES 256-bit | AES external key is stored in a secret safe. The secret safe is a secured repository that requires high-level elevation and approvals to access. Access can be requested and approved only by using an internal tool called Lockbox. The AES external key is also stored in the Trusted Platform Module in the server. A 48-digit numerical password is stored in Active Directory and protected by Lockbox. | Yes | |
| Skype for Business | AES 256-bit | AES external key is stored in a secret safe. The secret safe is a secured repository that requires high-level elevation and approvals to access. Access can be requested and approved only by using an internal tool called Lockbox. The AES external key is also stored in the Trusted Platform Module in the server. A 48-digit numerical password is stored in Active Directory and protected by Lockbox. | Yes | |
| Service encryption | SharePoint | AES 256-bit | The keys used to encrypt the blobs are stored in the SharePoint Content Database. The SharePoint Content Database is protected by database access controls and encryption at rest. Encryption is performed using transparent data encryption (TDE) in Azure SQL Database. These secrets are at the service level for SharePoint, not at the tenant level. These secrets (sometimes referred to as the master keys) are stored in a separate secure repository called the Key Store. TDE provides security at rest for both the active database and the database backups and transaction logs. When customers provide the optional key, the key is stored in Azure Key Vault, and the service uses the key to encrypt a tenant key, which is used to encrypt a site key, which is then used to encrypt the file level keys. Essentially, a new key hierarchy is introduced when the customer provides a key. | Yes |
| Skype for Business | AES 256-bit | Each piece of data is encrypted using a different randomly generated 256-bit key. The encryption key is stored in a corresponding metadata XML file, which is encrypted by a per-conference master key. The master key is also randomly generated once per conference. | Yes | |
| Exchange | AES 256-bit | Each mailbox is encrypted using a data encryption policy that uses encryption keys controlled by Microsoft or by the customer (when Customer Key is used). | Yes | |
| TLS between Microsoft 365 and clients/partners | Exchange | Opportunistic TLS supporting multiple cipher suites | The TLS certificate for Exchange (outlook.office.com) is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. The TLS root certificate for Exchange is a 2048-bit SHA1RSA certificate issued by Baltimore CyberTrust Root. |
Yes, when TLS 1.2 with 256-bit cipher strength is used |
| SharePoint | TLS 1.2 with AES 256 Data Encryption in OneDrive and SharePoint |
The TLS certificate for SharePoint (*.sharepoint.com) is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. The TLS root certificate for SharePoint is a 2048-bit SHA1RSA certificate issued by Baltimore CyberTrust Root. |
Yes | |
| Microsoft Teams | TLS 1.2 with AES 256 Frequently asked questions about Microsoft Teams – Admin Help |
The TLS certificate for Microsoft Teams (teams.microsoft.com, edge.skype.com) is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. The TLS root certificate for Microsoft Teams is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. |
Yes | |
| TLS between Microsoft datacenters | All Microsoft 365 services | TLS 1.2 with AES 256 Secure Real-time Transport Protocol (SRTP) |
Microsoft uses an internally managed and deployed certification authority for server-to-server communications between Microsoft datacenters. | Yes |
| Azure Rights Management (included in Microsoft 365 or Azure Information Protection) | Exchange | Supports Cryptographic Mode 2, an updated and enhanced RMS cryptographic implementation. It supports RSA 2048 for signature and encryption, and SHA-256 for hash in the signature. | Managed by Microsoft. | Yes |
| SharePoint | Supports Cryptographic Mode 2, an updated and enhanced RMS cryptographic implementation. It supports RSA 2048 for signature and encryption, and SHA-256 for signature. | Managed by Microsoft, which is the default setting; or Customer-managed, which is an alternative to Microsoft-managed keys. Organizations that have an IT-managed Azure subscription can use bring your own key (BYOK) and log its usage at no extra charge. For more information, see Implementing bring your own key. In this configuration, nCipher Hardware Security Modules (HSMs) are used to protect your keys. |
Yes | |
| S/MIME | Exchange | Cryptographic Message Syntax Standard 1.5 (Public Key Cryptography Standard (PKCS) #7) | Depends on the customer-managed public key infrastructure deployed. The customer manages the keys, and Microsoft never has access to the private keys used for signing and decryption. | Yes, when configured to encrypt outgoing messages with 3DES or AES256 |
| Microsoft Purview Message Encryption | Exchange | Same as Azure RMS (Cryptographic Mode 2 - RSA 2048 for signature and encryption, and SHA-256 for signature) | Uses Azure Information Protection as its encryption infrastructure. The encryption method used depends on where you obtain the RMS keys used to encrypt and decrypt messages. | Yes |
| SMTP TLS with partner organization | Exchange | TLS 1.2 with AES 256 | The TLS certificate for Exchange (outlook.office.com) is a 2048-bit SHA-256 with RSA encryption certificate issued by DigiCert Cloud Services CA-1. The TLS root certificate for Exchange is a 2048-bit SHA-1 with RSA encryption certificate issued by GlobalSign Root CA – R1. For security reasons, our certificates do change from time to time. |
Yes, when TLS 1.2 with 256-bit cipher strength is used |
*TLS certificates referenced in this table are for US datacenters; non-US datacenters also use 2048-bit SHA256RSA certificates.
Encryption technologies available in Government cloud community environments
| Encryption Technology | Implemented by | Key Exchange Algorithm and Strength | Key Management* | FIPS 140-2 Validated |
|---|---|---|---|---|
| BitLocker | Exchange | AES 256-bit | AES external key is stored in a secret safe and in the registry of the Exchange server. The secret safe is a secured repository that requires high-level elevation and approvals to access. Access can be requested and approved only by using an internal tool called Lockbox. The AES external key is also stored in the Trusted Platform Module in the server. A 48-digit numerical password is stored in Active Directory and protected by Lockbox. | Yes |
| SharePoint | AES 256-bit | AES external key is stored in a secret safe. The secret safe is a secured repository that requires high-level elevation and approvals to access. Access can be requested and approved only by using an internal tool called Lockbox. The AES external key is also stored in the Trusted Platform Module in the server. A 48-digit numerical password is stored in Active Directory and protected by Lockbox. | Yes | |
| Skype for Business | AES 256-bit | AES external key is stored in a secret safe. The secret safe is a secured repository that requires high-level elevation and approvals to access. Access can be requested and approved only by using an internal tool called Lockbox. The AES external key is also stored in the Trusted Platform Module in the server. A 48-digit numerical password is stored in Active Directory and protected by Lockbox. | Yes | |
| Service encryption | SharePoint | AES 256-bit | The keys used to encrypt the blobs are stored in the SharePoint Content Database. The SharePoint Content Databases is protected by database access controls and encryption at rest. Encryption is performed using TDE in Azure SQL Database. These secrets are at the service level for SharePoint, not at the tenant level. These secrets (sometimes referred to as the master keys) are stored in a separate secure repository called the Key Store. TDE provides security at rest for both the active database and the database backups and transaction logs. When customers provide the optional key, the Customer Key is stored in Azure Key Vault. The service uses the key to encrypt a tenant key, which is used to encrypt a site key, which is then used to encrypt the file level keys. Essentially, a new key hierarchy is introduced when the customer provides a key. | Yes |
| Skype for Business | AES 256-bit | Each piece of data is encrypted using a different randomly generated 256-bit key. The encryption key is stored in a corresponding metadata XML file. A per-conference master key encrypts this XML file. The master key is also randomly generated once per conference. | Yes | |
| Exchange | AES 256-bit | Each mailbox is encrypted using a data encryption policy that uses encryption keys controlled by Microsoft or by the customer (when Customer Key is used). | Yes | |
| TLS between Microsoft 365 and clients/partners | Exchange | Opportunistic TLS supporting multiple cipher suites | The TLS certificate for Exchange (outlook.office.com) is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. The TLS root certificate for Exchange is a 2048-bit SHA1RSA certificate issued by Baltimore CyberTrust Root. |
Yes, when TLS 1.2 with 256-bit cipher strength is used |
| SharePoint | TLS 1.2 with AES 256 | The TLS certificate for SharePoint (*.sharepoint.com) is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. The TLS root certificate for SharePoint is a 2048-bit SHA1RSA certificate issued by Baltimore CyberTrust Root. |
Yes | |
| Microsoft Teams | Frequently asked questions about Microsoft Teams – Admin Help | The TLS certificate for Microsoft Teams (teams.microsoft.com; edge.skype.com) is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. The TLS root certificate for Microsoft Teams is a 2048-bit SHA256RSA certificate issued by Baltimore CyberTrust Root. |
Yes | |
| TLS between Microsoft datacenters | Exchange, SharePoint, Skype for Business | TLS 1.2 with AES 256 | Microsoft uses an internally managed and deployed certification authority for server-to-server communications between Microsoft datacenters. | Yes |
| Secure Real-time Transport Protocol (SRTP) | ||||
| Azure Rights Management Service | Exchange | Supports Cryptographic Mode 2, an updated and enhanced RMS cryptographic implementation. It supports RSA 2048 for signature and encryption, and SHA-256 for hash in the signature. | Managed by Microsoft. | Yes |
| SharePoint | Supports Cryptographic Mode 2, an updated and enhanced RMS cryptographic implementation. It supports RSA 2048 for signature and encryption, and SHA-256 for hash in the signature. | Managed by Microsoft, which is the default setting; or Customer-managed (also known as BYOK), which is an alternative to Microsoft-managed keys. Organizations that have an IT-managed Azure subscription can use BYOK and log its usage at no extra charge. For more information, see Implementing bring your own key. In the BYOK scenario, nCipher HSMs are used to protect your keys. |
Yes | |
| S/MIME | Exchange | Cryptographic Message Syntax Standard 1.5 (PKCS #7) | Depends on the public key infrastructure deployed. | Yes, when configured to encrypt outgoing messages with 3DES or AES-256. |
| Office 365 Message Encryption | Exchange | Same as Azure RMS (Cryptographic Mode 2 - RSA 2048 for signature and encryption, and SHA-256 for hash in the signature) | Uses Azure RMS as its encryption infrastructure. The encryption method used depends on where you obtain the RMS keys used to encrypt and decrypt messages. If you use Azure RMS to obtain the keys, Cryptographic Mode 2 is used. If you use Active Directory (AD) RMS to obtain the keys, either Cryptographic Mode 1 or Cryptographic Mode 2 is used. The method used depends on your on-premises AD RMS deployment. Cryptographic Mode 1 is the original AD RMS cryptographic implementation. It supports RSA 1024 for signature and encryption and supports SHA-1 for signature. All current versions of RMS support this mode, except for BYOK configurations that use HSMs. |
Yes |
| SMTP TLS with partner organization | Exchange | TLS 1.2 with AES 256 | The TLS certificate for Exchange (outlook.office.com) is a 2048-bit SHA-256 with RSA Encryption certificate issued by DigiCert Cloud Services CA-1. The TLS root certificate for Exchange is a 2048-bit SHA-1 with RSA Encryption certificate issued by GlobalSign Root CA – R1. For security reasons, our certificates do change from time to time. |
Yes, when TLS 1.2 with 256-bit cipher strength is used. |
*TLS certificates referenced in this table are for US datacenters; non-US datacenters also use 2048-bit SHA256RSA certificates.