Data Encryption Technologies

in Office 365
Published: April 6, 2016

© 2016 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site
references, may change without notice. You bear the risk of using it. Some examples are for illustration only and are fictitious. No real association is intended or inferred. This document does
not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
Document Classification: Public Page | 1
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Introduction
The security, privacy, confidentiality, availability, and integrity of customer data within Microsoft Office
365 are high priorities for Microsoft. Office 365 data and systems are protected by a variety of
technologies and processes, including various forms of cryptography and encryption.

This document provides an overview of the various encryption technologies that are currently available
or recently announced for Office 365, including features deployed and managed by Microsoft, and
features available to and managed by Office 365 customers. This document also discusses some
common customer concerns regarding their data, and how encryption protects customer data in those
scenarios.

As you will read in this document, Office 365 uses service-side technologies that encrypt customer data
at rest and in transit. For customer data at rest, Office 365 uses volume-level and file-level encryption.
For customer data in-transit, Office 365 uses multiple encryption technologies for communications
between datacenters and between clients and servers, such as Transport Layer Security (TLS) and
Internet Protocol Security (IPsec). Office 365 also includes several encryption features that are
customer-managed, but irrespective of customer configuration, customer data stored within Office 365
is protected. Validation of our crypto policy and its enforcement is independently verified through the
multiple third-party auditors.

Encryption of Customer Data at Rest

Encryption of customer data at rest is currently provided by two service-side technologies: BitLocker
volume-level encryption, and per-file encryption in Skype for Business, OneDrive for Business, and
SharePoint Online.

Volume-level Encryption
Office 365 uses BitLocker to encrypt customer data at rest at the volume-level. BitLocker encryption is a
data protection feature that is integrated with Windows. BitLocker is one of the technologies used to
safeguard against threats in case there are lapses in other processes or controls (e.g., access control or
recycling of hardware) that could lead to someone gaining physical access to disks containing customer
data. In this case, BitLocker eliminates the potential for data theft or exposure as a result of lost, stolen,
or inappropriately decommissioned computers and disks.

BitLocker is deployed with Advanced Encryption Standard (AES) 128-bit+ encryption on disks containing
customer content in Exchange Online, SharePoint Online, and Skype for Business applications in Office
365 enterprise service. New servers are deployed using AES 256-bit and 128-bit encryption is being
phased out. BitLocker key management involves the management of recovery keys that are used to
unlock/recover encrypted disks in an Office 365 datacenter. Office 365 stores the master keys in a
secured share, only accessible by individuals who have been screened and approved. The credentials for
the keys are stored in a secret store, which requires a high level of elevation and approvals to access. All
elevated access is both approved and logged by a group other than the group requesting access.

BitLocker supports keys which generally fall into two management categories:
Document Classification: Public Page | 2
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

 BitLocker-managed keys, which are generally short-lived and tied to the lifetime of an operating
system instance installed on a server or a given encrypted disk. These keys are generally deleted
and reset during server reinstallation or disk formatting.
 BitLocker recovery keys, which are managed outside of BitLocker but used for disk decryption.
BitLocker uses recovery keys for scenarios where an operating system is reinstalled and
encrypted data disks already exist. Recovery keys are also used by Managed Availability
monitoring probes for BitLocker in Exchange Online where a Responder may need to unlock a
disk.
BitLocker-protected volumes are encrypted with a full volume encryption key, which in turn is encrypted
with a volume master key. BitLocker uses FIPS-compliant algorithms to ensure that encryption keys are
never stored or sent over the wire in the clear. In order to be to FIPS 140-2 compliant, a cryptographic
module must satisfy all of the security requirements specified by the FIPS 140-2 standard. In other
words, FIPS 140-2 compliance does not dictate which drives/volumes need to be encrypted; rather it
only requires that encrypted volumes must conform to FIPS 140-2 standards. The security requirements
for FIPS 140-2 are described in the spec released by NIST.

The following list of requirements have been validated for BitLocker:

 Cryptographic Module Specification (Section 2 of Spec)

 Cryptographic Module Ports and Interfaces (Section 2 & 4 of Spec)
 Finite State Model
 Operational Environment (Section 6.1.2, Item 3 & 4)
 Design Assurance
 Mitigation of Other Attacks
 Self-Tests (Section 8)

The Office 365 implementation of customer data-at-rest-protection does not deviate from the BitLocker
implementation. As a result, Office 365 meets those requirements by default.

File-level Encryption
Skype for Business, OneDrive for Business, and SharePoint Online include file-level encryption.

Skype for Business

In Skype for Business, customer data at rest may be stored in the form of files or presentations that have
been uploaded by meeting participants. The Web Conferencing server encrypts data content using AES
with a 128-bit key. The encrypted data content is stored on a file share. Each piece of content is
encrypted using a different randomly generated 128-bit key. The encryption key is stored in a
corresponding metadata XML file which is also encrypted by a per-conference master key. The master
key is also randomly generated once per conference. When a piece of content is shared in a conference,
the Web Conferencing server instructs the conferencing clients to download the encrypted content via
HTTPS. It sends the corresponding key to clients so that the content can be decrypted.

The Web Conferencing server also authenticates conferencing clients before it allows the clients access
to conference content. When joining a Web conference, each conferencing client establishes a SIP dialog
with the conferencing focus component running inside the front-end server over TLS first. The
conferencing focus passes to the conference client an authentication cookie generated by the Web
Document Classification: Public Page | 3
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Conferencing server. The conferencing client then connects to the Web Conferencing server presenting
the authentication cookie to be authenticated by the server.

SharePoint Online (including OneDrive for Business)

All customer content in SharePoint Online is protected by unique, per-file keys that are always unique to
a single tenant. When a file is uploaded, encryption is performed by SharePoint Online within the
context of the upload request, before being sent to Azure storage. When a file is downloaded,
SharePoint Online retrieves your encrypted content from Azure based on your unique document
identifier, and decrypts the content before sending it to the user. Azure has no ability to decrypt, or
even identify or understand content. All of the encryption and decryption happens in the same systems
that enforce tenant isolation, which are Azure Active Directory and SharePoint Online.

In SharePoint Online, all content that a customer uploads is encrypted, potentially with multiple AES
256-bit keys and distributed across the datacenter as follows. Every step of this encryption is FIPS 140-2
Level 2 validated.

Files in SharePoint Online

 Each file is broken into one or more chunks, depending on file size. Each chunk is encrypted
using its own unique key.
 When a file is updated, the update is handled in the same way: the change is broken into one or
more chunks and each chunk is encrypted with a separate unique key.
 All of these chunks – files, pieces of files, and update deltas – are stored as blobs in Azure
storage that are randomly distributed across multiple Azure storage accounts.
 The set of encryption keys for these chunks of content is itself encrypted using an
independently-generated master key.
o The encrypted keys are stored in the SharePoint Content Database.
o The master key to decrypt the keys to the shreds is stored in a separate secure store
called the Key Store.
 The “map” used to re-assemble the file is stored in the SharePoint Content Database along with
the encrypted keys, separately from the master key needed to decrypt them.
 Each Azure storage account has its own unique credentials per access type (read, write,
enumerate and delete). Each set of credentials is held in the secure Key Store and is regularly
refreshed.

As described above, there are three different types of stores, each with a distinct function:

 Content is stored as encrypted blobs in Azure storage. The key to each chunk of content is
encrypted and stored separately in the Content Database. The content itself holds no clue as to
how it can be decrypted.
 The Content Database is a SQL Server database. It holds the map required to locate and
reassemble all of the content blobs held in Azure storage as well as the keys needed to encrypt
those blobs. However, the set of keys is itself encrypted. The master key is held in a separate
Key Store.
 The Key Store is physically separate from the Content Database and Azure storage. It holds the
credentials for each Azure storage container and the master key to the set of encrypted keys
held in the Content Database.
Document Classification: Public Page | 4
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Each of these three storage components – the Azure blob store, the Content Database and the Key Store
– is physically separate. The information held in any one of the components is unusable on its own.
Without access to all three, it is impossible to retrieve the keys to the chunks, decrypt the keys to make
them usable, associate the keys with their corresponding chunks, decrypt each chunk, or reconstruct a
document from its constituent chunks.

The master keys, which protect the per-blob keys, are stored in two locations:

 First, the secure store (a built-in SharePoint secret store) which is protected by the Farm Key.
 Second, the master keys are backed-up in the central SharePoint Secret Store.

These keys are updated (and the blob keys re-encrypted) every 60 days. The credentials used to access
the Azure storage containers are also held in the central SPO Secret Store, and delegated to each
SharePoint farm as needed. These credentials are Azure storage SAS signatures, with separate
credentials used to read or write data, with policy applied so that they auto-expire every 60 days.
Different credentials are used to read or write data (not both) and SharePoint farms are not given
permissions to enumerate.

Note For Office 365 Government customers, data blobs are stored in Azure Government
Storage. In addition, access to SharePoint keys in Office 365 Government is limited to Office 365
staff has have been specifically screened. Azure Government operations staff do not have access
to the SharePoint key store that is used for encrypting data blobs.

For more information about data encryption in SharePoint, see Data Encryption in OneDrive for Business
and SharePoint Online.

List Items in SharePoint Online

List Items are smaller chunks of content that are created ad-hoc or that can live more dynamically within
a site, such as rows in a user-created list, individual posts in a SharePoint Blog, or entries within a
SharePoint Wiki Page.

List item contents are encrypted at rest by BitLocker drive encryption, which as mentioned previously is
enabled on all of the back-end and storage servers used by SharePoint Online.

Advanced Encryption
One of the security principles used in the defense of Office 365 and Office 365 datacenters is Assume
Breach – the idea that every component or compartment of a computing system will at some point be
compromised by a malicious actor. Assume Breach is a concept that guides security investments, design
decisions and operational security practices within Office 365 and all Microsoft cloud services. This
Assume Breach mindset includes Windows administrator accounts and therefore suggests that if some
compartmentalization of data access from server administrative access is possible then it should be
considered. This conceptual model extends into the realm of data encryption because BitLocker is tied
to the Windows access control model and allows an administrator to configure BitLocker, and even
disable BitLocker. BitLocker also does not protect data that is copied or moved from an encrypted disk
volume to storage media that does not use BitLocker.
Document Classification: Public Page | 5
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

More importantly, BitLocker precludes bring your own key (BYOK) scenarios. BitLocker is a full volume
encryption technology that uses a common key across data on the same storage volume. This means
that a disk volume that contains data from more than one cloud service tenant would use the same
encryption key, thereby precluding scenarios in which a tenant controls encryption keys. To mitigate this
threat, Microsoft has compensating controls that prevent any unauthorized copying of data within the
service.

To overcome these limitations and enable tenant control and management of encryption keys,
Microsoft is adding capabilities to Office 365 known as Advanced Encryption.1 The scope for Advanced
Encryption is all customer content2 that is stored at rest within the Office 365 Exchange Online and
SharePoint Online cloud services (Skype for Business stores nearly all user-generated content within the
user’s Exchange Online mailbox and therefore inherits the Advanced Encryption features of Exchange
Online as those features become available).

Advanced Encryption provides multiple benefits. For example, it:

 Enables multi-tenant services to provide per-tenant key management.

 Provides separation of Windows operating system administrators from access to customer data
stored or processed by the operating system.
 Provides customers with a mechanism for rendering all customer data inaccessible to Office 365
services upon leaving Office 365.
 Enhances the ability of Office 365 to meet the demands of customers that have requirements
regarding encryption.

The implementation of Advanced Encryption within the Exchange Online application is intended to
address the risks and functional limitations of BitLocker. Providing customers with a method to control
key material used in the encryption of customer data provides a robust and desirable mechanism for
providing customers with the assurance that should the customer choose to leave the Office 365 service
that Microsoft will not have continued access to the customer’s data. A customer that revokes access to
their key material will be able to render all data held within Office 365 unreadable by the cloud service.
This is in addition (and a complement) to the Customer Lockbox feature that can be used to control
access to customer data by cloud service personnel.

Example Scenario for Advanced Encryption with Customer-Managed Key

Contoso is an Office 365 customer that has elected to use a Contoso key with the Advanced Encryption
BYOK feature in Exchange Online. To do this:

1. The Tenant Admin logs into the Contoso Azure subscription to configure encryption keys in
Azure Key Vault.

1
See Enhancing transparency and control for Office 365 customers for announcement.

2
For Exchange, all customer content includes everything that an end user generates and stores in the Exchange service, including calendar
items, notes, tasks, folders, etc. in addition to email messages. For SharePoint this means files.
Document Classification: Public Page | 6
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

2. The Tenant Admin creates one or more key vaults in their Azure subscription and then imports
keys in each key vault using the BYOK toolset; or the Tenant Admin requests a key from Azure
Key Vault.
3. The Tenant Admin configures access control using the Azure PowerShell cmdlet Set-
AzureKeyVaultAccessPolicy on the key vaults to allow Exchange Online to perform key
wrap/unwrap functions.3
4. The Tenant Admin creates a data encryption policy for use with Exchange Online mailboxes
using the New-DataEncryptionPolicy cmdlet in Remote PowerShell. This data encryption policy
will include the URI of the Azure Key Vault key that is to be used with mailboxes that the
customer assigns to that encryption key policy. Creation of the encryption policy within Office
365 provides the core information required to validate and begin using the key referenced in the
policy.
5. The Tenant Admin uses the Set-Mailbox cmdlet to assign the data encryption policy to one or
more Exchange Online mailboxes.
6. Once Office 365 has validated proper configuration of a key policy the service will enable the
Tenant Admin to assign objects (mailboxes in the case of Exchange) to that key policy.

The following illustration shows the process described above.

Figure 1 - Enabling Advanced Encryption with customer-managed keys

An optional step will be to generate or upload multiple keys (not a single key in multiple key vaults) for
use with Exchange Online and/or SharePoint Online resources, and to create additional encryption key
policies for use with those keys. This will allow a tenant to choose, as one example, to assign a key policy
that points to an Azure Key Vault key that is held in the Europe region for resources (such as Exchange

3
See https://msdn.microsoft.com/en-us/library/azure/dn878079.aspx for the operations available for keys and
https://msdn.microsoft.com/en-us/library/azure/mt620025.aspx for setting permissions on key vaults.
Document Classification: Public Page | 7
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Online mailboxes or SharePoint Online site collections) that are also located in Europe, while using a
second key policy that points to an Azure Key Vault key that is held in the United States for resources
that are located in the United States.

It is expected that every workload that supports Advanced Encryption will have a default encryption
policy key. For customers that do not choose to own and manage encryption keys, the default policy key
will be used to encrypt customer data. If the customer starts using their own encryption key at some
point in the future, the act of assigning a data encryption policy (DEP) to service resources would result
in the service re-wrapping the existing keys using the newly assigned DEP.

Key Management
There are two scenarios that may require additional key management tasks:

1. You want to stop using an existing key vault that has an associated DEP. In this scenario, you
would create a new DEP and assign it to all users.
2. You want to roll the key in the key vault. In this scenario, you would create a new key within, or
import a key into, the key vault containing the existing key, perform the process described in
Example Scenario for Advanced Encryption with Customer-Managed Key, and then enable the
newly configured key for use by using the Set-DataEncryptionPolicy cmdlet.

When you choose BYOK, you control the key that lets Microsoft services decrypt your data. If you delete
your key from Azure Key Vault, Microsoft services will eventually lose the ability to function with your
data. Microsoft cannot recover your deleted key. To help protect keys managed by your organization,
we recommend following these best practices:
 Never purge your keys; only revoke access, if need be. Removal of a root key without ensuring
that 100% of data encryption has been switched to your new key will result in permanent data
loss.
 Ensure that you minimize who has permissions to manage your key vault.
 Ensure that your personnel are trained properly.
 Lock your key vault.
 Keep an offline backup of your key just in case your key administrator makes a mistake.

Exiting the Office 365 Service

One of the benefits that Office 365 customers get from using Advanced Encryption with your own key
(BYOK) is the ability to leave Office 365 and then remove access to the encryption key used to encrypt
the customer’s data, thus rendering all customer data held in Office 365 inaccessible.

The design for the process of removing access to an encryption key is still under review. Because
revocation of access to a key will have major and potentially irreversible effects upon the ability to
deliver the affected service(s), Microsoft reserves the right to control when revocation will be honored
so as to allow action to be reversed (in case of mistake, rogue admin, etc.) within a predetermined time
period.

Encryption of Customer Data In-transit

In addition to protecting customer data at rest, Office 365 uses encryption technologies to protect
customer data in-transit. Data is in-transit when a client machine communicates with an Office 365
Document Classification: Public Page | 8
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

server, or when an Office 365 server communicates with another Office 365 server. All customer-facing
servers negotiate a secure session using TLS with client machines. This applies to various protocols such
as HTTP, POP3, etc., that are used by clients such as Outlook, Skype for Business, and Outlook Web App.

All implementation details such as the version of TLS being used, whether or not Perfect Forward
Secrecy (PFS) is enabled, the order of cipher suites, etc., are available publicly. One way to see these
details is to use a third-party Web site, such as Qualys SSL Labs (www.ssllabs.com). Below are the links
to automated test pages from Qualys that display information for the following services:

 Office 365 Portal

 Exchange Online
 SharePoint Online
 Skype for Business (SIP)
 Skype for Business (Web)
 Exchange Online Protection

For Exchange Online Protection, URLs vary by tenant names; however, all customers can test Office 365
using microsoft-com.mail.protection.outlook.com.

As for traffic between datacenters, Microsoft deploys applications so that the customer content in this
traffic is encrypted using TLS or IPsec. All traffic between Microsoft datacenters is encrypted: this
includes both application-layer encryption for the customer data itself, and network transport layer
encryption for the communication of the customer data.

Customer-managed Encryption Technologies

Along with the encryption technologies in Office 365 that are managed by Microsoft, Office 365 also
includes encryption features that customers can manage and configure. These technologies, which offer
a variety of ways to encrypt customer data at rest or in-transit, are:

 Rights Management Services

 Secure Multipurpose Internet Mail Extension
 Office 365 Message Encryption
 Secure mail flow with a partner organization

Information on these technologies can also be found in the Office 365 service descriptions.

Azure Rights Management

Azure Rights Management (Azure RMS) uses encryption, identity, and authorization policies to help
secure your files and email across multiple platforms and devices—phones, tablets, and PCs.
Information can be protected both within and outside your organization because protection remains
with the data. Azure RMS provides persistent protection of all file types, protects files anywhere,
supports business-to-business collaboration, and a wide range of Windows and non-Windows devices.
Azure RMS protection can also augment data loss prevention (DLP) policies. But very importantly,
authorized people and services (such as search and indexing) can continue to read and inspect the data
that Azure RMS protects, which is not easily accomplished with other information protection solutions,
Document Classification: Public Page | 9
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

such as S/MIME. This ability is sometimes referred to as “reasoning over data” and is a crucial element
in maintaining control of your organization’s sensitive data.

Microsoft offers Azure RMS for both Office 365 and on-premises servers and services. Azure RMS is
integrated with Office 365 and recommended for all Office 365 customers. To configure Office 365 to
use Azure RMS, see Configure IRM to use Azure Rights Management. If you operate on-premises Active
Directory (AD) RMS server then you can also Configure IRM to use an on-premises AD RMS server, but
we strongly recommend you to migrate to Azure RMS to use new features like secure collaboration with
other organizations.

When you protect content with Azure RMS, Azure RMS uses a 2048-bit RSA asymmetric key with SHA-
256 hash algorithm for integrity to encrypt the content. The symmetric key for Office documents and
email is AES 128-bit (CBC mode with PKCS#7 padding).

In a default Azure RMS implementation, Microsoft generates and manages the root key that is unique
for each tenant. Customers can manage the lifecycle of their root key in Azure RMS with SharePoint
Online by using a method called Bring your Own Key (BYOK) that allows you to generate your key in on-
premises HSMs, and stay in control of this key after transfer to Microsoft’s FIPS 140-2 Level 2-validated
HSMs. Access to the root key is always limited to Office 365 applications (such as Exchange Online and
SharePoint Online) and is not given to any personnel. In addition, customers can access a near real-time
log showing all access to the root key at any time. For more information, see Logging and Analyzing
Azure Rights Management Usage.

Azure Rights Management helps mitigates threats such as wire-tapping, man-in-the-middle attacks, data
theft, and unintentional violations of organizational sharing policies. At the same time, any unwarranted
access of customer data in-transit or at rest by an unauthorized user who does not have appropriate
permissions is prevented via policies that follow that data, thereby mitigating the risk of that data falling
in the wrong hands either knowingly or unknowingly and providing data loss prevention functions.

Secure Multipurpose Internet Mail Extension

Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public key encryption and
digital signing of MIME data. S/MIME is defined in RFCs 3369, 3370, 3850, 3851, and others. It allows a
user to encrypt an email and digitally sign an email. An email that is encrypted using S/MIME can only be
decrypted by the recipient of the email using their private key, which is only available that recipient. As
such the emails cannot be decrypted by anybody other than the recipient of the email.

Microsoft supports S/MIME in Office 365. Public certificates are distributed to the customer’s on-
premises Active Directory and stored in attributes that can be replicated to an Office 365 tenant. The
private keys that correspond to the public keys remain on-premises and are never transmitted to Office
365. Users can compose, encrypt, decrypt, read, and digitally sign emails between two users in an
organization using Outlook, Outlook Web App, and Exchange ActiveSync clients. For more information,
see S/MIME encryption now in Office 365.

Office 365 Message Encryption

Office 365 Message Encryption (OME) is an easy-to-set-up-and-use email service that allows you to send
encrypted mail to anyone. OME requires activation of Azure RMS in customer’s Office 365 tenant. With
OME, tenant administrators can create transport rules that encrypt emails if they match certain criteria.
Document Classification: Public Page | 10
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encrypted messages can be sent inside or outside of customer’s tenant. External users can use either an
Office 365 account (from their company), a Microsoft account, or a one-time passcode to decrypt the
email they have received.

Like Azure Rights Management, OME also mitigates threats such as wire-tapping and man-in-the-middle
attacks, and other threats, such as unwarranted access of data by an unauthorized user who does not
have appropriate permissions.

Transport Layer Security

If you want to ensure secure communication with a partner, you can use inbound and outbound
connectors to provide security and message integrity. You can configure forced inbound and outbound
TLS on each connector, using a certificate. Using an encrypted SMTP channel can prevent data in emails
from being stolen via a man-in-the-middle attack.

Risks and Protection

Microsoft follows a control and a compliance framework that focuses on risks to the Office 365 service
and to customer data. Microsoft implements a large set of technology and process-based methods
(referred to as controls) to mitigate these risks. Identification, evaluation and mitigation of risks via
controls is a continuous process. The implementation of controls within various layers of the service
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 at different layers of
the service are implemented to protect against the same or similar risk scenarios. The multi-layered
approach provides fail-safe protection in case a control fails for some reason.

Some risk scenarios and the encryption technologies that mitigate them are listed below. These
scenarios are in many cases also mitigated via other controls implemented in Office 365.

Encryption
Technology Applies to Implementation Risk scenario Value
BitLocker Exchange Service Disks or servers in Office 365 are BitLocker provides a fail-
Online, implemented stolen or improperly recycled. safe approach to
SharePoint protect against loss of
Online, Skype data due to stolen or
for Business improperly recycled
hardware (server / disk).
Per-file encryption Skype for Service Internal or external hacker tries The encrypted data
Business implemented to access individual files / data cannot be decrypted
as a blob without access to keys.
Helps to mitigate risk of
a hacker accessing data.
Per-file encryption SharePoint Service Internal or external hacker tries The encrypted data
Online implemented to access individual files / data cannot be decrypted
as a blob. without access to keys.
There is an attempt to access Helps to mitigate risk of
data across tenant a hacker accessing data
and cross tenant access
of data.
TLS between Office Exchange Service Man-in-the-middle or other This implementation
365 and clients Online, implemented attack to tap the data flow provides value to both
SharePoint Microsoft and
Document Classification: Public Page | 11
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption
Technology Applies to Implementation Risk scenario Value
Online, Skype between Office 365 and client customers and assures
for Business, computers over Internet. data integrity as it flows
Yammer between Office and the
client.
TLS between Exchange Service Man-in-the-middle or other This implementation is
Microsoft Online, implemented attack to tap the customer data another fail safe
datacenters SharePoint flow between Office 365 servers method to protect data
Online, Skype located in different Microsoft against attacks between
for Business datacenters. Microsoft datacenters.
Rights Management Exchange Customer Data falls into the hands of a RMS provides value to
Service Online, managed person who should not have customers by using
SharePoint access to the data. encryption, identity, and
Online, and authorization policies to
OneDrive for help secure files and
Business email across multiple
devices. RMS provides
value to customers
where all emails
originating from Office
365 that match certain
criteria (i.e. all emails to
a certain address) are
automatically encrypted
before they get sent to
another recipient.
S/MIME Exchange Customer Email falls into the hands of a S/MIME provides value
Online managed person who is not the intended to customers by
recipient. assuring that email
encrypted with S/MIME
can only be decrypted
by the direct recipient
of the email.
Office 365 Message Exchange Customer Email falls in hands of a person OME provides value to
Encryption Online managed either within or outside Office customers where all
365 who is not the intended emails originating from
recipient of the email. Office 365 that match
certain criteria (i.e. all
emails to a certain
address) are
automatically encrypted
before they get sent to
another internal or an
external recipient.
SMTP TLS with Exchange Customer Email is intercepted via a man- This scenario provides
partner organization Online managed in-the-middle or other attack value to the customer
while in transit from an Office such that they can send
365 tenant to another partner / receive all emails
organization. between their Office
365 tenant and their
partner’s email
organization inside an
encrypted SMTP
channel.
Table 1 - Risk scenarios and encryption technology mitigation
Document Classification: Public Page | 12
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

The following tables summarize the encryption technologies available in Office 365 Multi-tenant and
Government Cloud Community environments.

Office 365 Multi-tenant

Encryption Implemented Key Exchange Algorithm FIPS 140-2
Technology by and Strength Key Management4 Level 2
Validated
BitLocker Exchange AES 128-bit+ Achieved via the Windows Certificate Yes, for
Online Store. The credentials for the keys are servers that
stored in central admin secure store and use AES 256-
needs high level elevation and approvals bit5
to access. All elevated access is both
approved and logged by a separate
group than the group requesting access.
SharePoint AES 256-bit Achieved via the Windows Certificate Yes
Online Store. The credentials for the keys are
stored in central admin secure store and
needs high level elevation and approvals
to access. All elevated access is both
approved and logged by a separate
group than the group requesting access.
Skype for AES 256-bit Achieved via the Windows Certificate Yes
Business Store. The credentials for the keys are
stored in central admin secure store and
needs high level elevation and approvals
to access. All elevated access is both
approved and logged by a separate
group than the group requesting access.
Per-file Skype for AES 128-bit Each piece of content is encrypted using No
encryption Business a different randomly generated 128-bit
key. The encryption key is stored in a
corresponding metadata XML file which
is also encrypted by a per-conference
master key. The master key is also
randomly generated once per
conference.
SharePoint AES 256-bit The master keys, which protect the per- Yes
Online blob keys, are stored in two locations:
1. First, the secure store (a built-in
SharePoint secret store) which is
protected by the Farm Key.
2. Second, the master keys are backed-
up in the central SharePoint Secret
Store.

These keys are updated (and the blob

keys re-encrypted) every 60 days.

4
TLS certificates referenced in this table are for US datacenters; non-US datacenters also use 4096-bit sha256RSA certificates.

5
The majority of servers in Office 365 multi-tenant have been deployed with AES 256-bit encryption for BitLocker. Servers using AES 128-bit are
being phased out.
Document Classification: Public Page | 13
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption Implemented Key Exchange Algorithm FIPS 140-2

Technology by and Strength Key Management4 Level 2
Validated
TLS between Exchange Opportunistic TLS The TLS certificate for Exchange Online Yes, when
Office 365 and Online supporting multiple (outlook.office.com) is a 4096-bit TLS 1.2 with
clients/partners cipher suites sha256RSA certificate issued by 256-bit
Baltimore CyberTrust Root. cipher
strength is
The TLS root certificate for Exchange used
Online is a 2048-bit sha1RSA certificate
issued by Baltimore CyberTrust Root.

Be aware that for security reasons, our

certificates do change from time to
time.
SharePoint The TLS certificate for SharePoint Online Yes
Online (*.sharepoint.com) is a 4096-bit
sha256RSA certificate issued by
Baltimore CyberTrust Root.

The TLS root certificate for SharePoint

Online is a 2048-bit SHA1RSA certificate
issued by Baltimore CyberTrust Root.

Be aware that for security reasons, our

certificates do change from time to
time.
Skype for TLS for SIP The TLS certificate for Skype for Business Yes
Business communications and (*.lync.com) is a 4096-bit sha256RSA
PSOM data sharing certificate issued by Baltimore
sessions CyberTrust Root.

The TLS root certificate for Skype for

Business is a 2048-bit sha256RSA
certificate issued by Baltimore
CyberTrust Root.
TLS between Exchange TLS 1.2 with AES 256 Microsoft uses an internally managed Yes
Microsoft Online, Secure Real-time and deployed certification authority for
datacenters SharePoint Transport Protocol server-to-server communications
Online, and (SRTP) between Microsoft datacenters.
Skype for
Business

Azure Rights Exchange Supports Cryptographic Managed by Microsoft or customer- Yes

Management Online Mode 2, an updated and managed keys (BYOK) Azure RMS uses
Service enhanced RMS Thales HSMs to protect your keys. For
cryptographic more information, see Thales HSMs and
implementation. It Azure RMS.
supports RSA 2048 for
signature and
encryption, and SHA-256
for hash in the signature.
Document Classification: Public Page | 14
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption Implemented Key Exchange Algorithm FIPS 140-2

Technology by and Strength Key Management4 Level 2
Validated
SharePoint Supports Cryptographic Managed by Microsoft, which is the Yes
Online Mode 2, an updated and default setting; or
enhanced AD RMS
cryptographic Customer-managed (aka Bring Your Own
implementation. It Key (BYOK)), which is an alternative to
supports RSA 2048 for Microsoft-managed keys. Organization
signature and that have an IT-managed Azure
encryption, and SHA-256 subscription can use BYOK and log its
for signature. usage at no extra charge. For more
information, see Implementing bring
your own key.

In both configurations, Thales HSMs are

used to protect your keys. For more
information, see Thales HSMs and Azure
RMS.
S/MIME Exchange Cryptographic Message Depends on the customer-managed Yes, when
Online Syntax Standard 1.5 public key infrastructure deployed. Key configured to
(PKCS #7) management is performed by the encrypt
customer, and Microsoft never has outgoing
access to the private keys used for messages
signing and decryption. with 3DES or
AES256
Office 365 Exchange Same as Azure RMS Uses Azure RMS as its encryption Yes
Message Online (Cryptographic Mode 2 - infrastructure. The encryption method
Encryption RSA 2048 for signature used depends on where you obtain the
and encryption, and RMS keys used to encrypt and decrypt
SHA-256 for signature) messages.

If you use Microsoft 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. This mode
continues to be supported by all current
versions of RMS, except for BYOK
configurations that use HSMs.
Document Classification: Public Page | 15
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption Implemented Key Exchange Algorithm FIPS 140-2

Technology by and Strength Key Management4 Level 2
Validated
SMTP TLS with Exchange TLS 1.2 with AES 256 The TLS certificate for Exchange Online Yes, when
partner Online (outlook.office.com) is a 4096-bit TLS 1.2 with
organization sha256RSA certificate issued by 256-bit
Baltimore CyberTrust Root. cipher
strength is
The TLS root certificate for Exchange used
Online is a 2048-bit sha1RSA certificate
issued by Baltimore CyberTrust Root.

Be aware that for security reasons, our

certificates do change from time to
time.
Table 2 - Encryption technologies used in Office 365 Multi-tenant

Office 365 Government Community Cloud

Encryption Implemented Key Exchange Algorithm FIPS 140-2
Technology by and Strength Key Management6 Level 2
Validated
BitLocker Exchange AES 256-bit Achieved via the Windows Certificate Yes
Online Store. The credentials for the keys are
stored in central admin secure store and
needs high level elevation and approvals
to access. All elevated access is both
approved and logged by a separate
group than the group requesting access.
SharePoint AES 256-bit Achieved via the Windows Certificate Yes
Online Store. The credentials for the keys are
stored in central admin secure store and
needs high level elevation and approvals
to access. All elevated access is both
approved and logged by a separate
group than the group requesting access.
Skype for AES 256-bit Achieved via the Windows Certificate Yes
Business Store. The credentials for the keys are
stored in central admin secure store and
needs high level elevation and approvals
to access. All elevated access is both
approved and logged by a separate
group than the group requesting access.
Per-file Skype for AES 128-bit Each piece of content is encrypted using No
encryption Business a different randomly generated 128-bit
key. The encryption key is stored in a
corresponding metadata XML file which
is also encrypted by a per-conference
master key. The master key is also
randomly generated once per
conference.

6
TLS certificates referenced in this table are for US datacenters; non-US datacenters also use 4096-bit sha256RSA certificates.
Document Classification: Public Page | 16
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption Implemented Key Exchange Algorithm FIPS 140-2

Technology by and Strength Key Management6 Level 2
Validated
SharePoint AES 256-bit The master keys, which protect the per- Yes
Online blob keys, are stored in two locations:
1. First, the secure store (a built-in
SharePoint secret store) which is
protected by the Farm Key.
2. Second, the master keys are backed-
up in the central SharePoint Secret
Store.

These keys are updated (and the blob

keys re-encrypted) every 60 days.
TLS between Exchange Opportunistic TLS The TLS certificate for Exchange Online Yes, when
Office 365 and Online supporting multiple (outlook.office.com) is a 4096-bit TLS 1.2 with
clients/partners cipher suites sha256RSA certificate issued by 256-bit
Baltimore CyberTrust Root. cipher
strength is
The TLS root certificate for Exchange used
Online is a 2048-bit sha1RSA certificate
issued by Baltimore CyberTrust Root.
Be aware that for security reasons, our
certificates do change from time to
time.
SharePoint TLS 1.2 with AES 256 The TLS certificate for SharePoint Online Yes
Online (*.sharepoint.com) is a 4096-bit
sha256RSA certificate issued by
Baltimore CyberTrust Root.

The TLS root certificate for SharePoint

Online is a 2048-bit SHA1RSA certificate
issued by Baltimore CyberTrust Root.

Be aware that for security reasons, our

certificates do change from time to
time.
Skype for TLS for SIP The TLS certificate for Skype for Business Yes
Business communications and (*.lync.com) is a 4096-bit sha256RSA
PSOM data sharing certificate issued by Baltimore
sessions CyberTrust Root.

The TLS root certificate for Skype for

Business is a 2048-bit sha256RSA
certificate issued by Baltimore
CyberTrust Root.
TLS between Exchange TLS 1.2 with AES 256 Microsoft uses an internally managed Yes
Microsoft Online, Secure Real-time and deployed certification authority for
datacenters SharePoint Transport Protocol server-to-server communications
Online, and (SRTP) between Microsoft datacenters.
Skype for
Business
Document Classification: Public Page | 17
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption Implemented Key Exchange Algorithm FIPS 140-2

Technology by and Strength Key Management6 Level 2
Validated
Azure Rights Exchange Supports Cryptographic Managed by Microsoft. Azure RMS uses Yes
Management Online Mode 2, an updated and Thales HSMs to protect your keys. For
Service enhanced RMS more information, see Thales HSMs and
cryptographic Azure RMS.
implementation. It
supports RSA 2048 for
signature and
encryption, and SHA-256
for hash in the signature.
SharePoint Supports Cryptographic Managed by Microsoft, which is the Yes
Online Mode 2, an updated and default setting; or
enhanced RMS
cryptographic Customer-managed (aka Bring Your Own
implementation. It Key (BYOK)), which is an alternative to
supports RSA 2048 for Microsoft-managed keys. Organization
signature and that have an IT-managed Azure
encryption, and SHA-256 subscription can use BYOK and log its
for hash in the signature. usage at no extra charge. For more
information, see Implementing bring
your own key.

In both configurations, Thales HSMs are

used to protect your keys. For more
information, see Thales HSMs and Azure
RMS
S/MIME Exchange Cryptographic Message Depends on the public key infrastructure Yes, when
Online Syntax Standard 1.5 deployed configured to
(PKCS #7) encrypt
outgoing
messages
with 3DES or
AES256
Office 365 Exchange Same as Azure RMS Uses Azure RMS as its encryption Yes
Message Online (Cryptographic Mode 2 - infrastructure. The encryption method
Encryption RSA 2048 for signature used depends on where you obtain the
and encryption, and RMS keys used to encrypt and decrypt
SHA-256 for hash in the messages.
signature)
If you use Microsoft 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. This mode
continues to be supported by all current
versions of RMS, except for BYOK
configurations that use HSMs.
Document Classification: Public Page | 18
Document Location: http://aka.ms/DET
Document Feedback: [email protected]

Encryption Implemented Key Exchange Algorithm FIPS 140-2

Technology by and Strength Key Management6 Level 2
Validated
SMTP TLS with Exchange TLS 1.2 with AES 256 The TLS certificate for Exchange Online Yes
partner Online (outlook.office.com) is a 4096-bit
organization sha256RSA certificate issued by
Baltimore CyberTrust Root.

The TLS root certificate for Exchange

Online is a 2048-bit sha1RSA certificate
issued by Baltimore CyberTrust Root.

Be aware that for security reasons, our

certificates do change from time to
time.
Table 3 - Encryption technologies used in Office 365 Government Cloud Community

Summary
Protection of customer data stored within and transmitted by these services is of paramount
importance to Microsoft. We use technologies and controlled processes to protect data. Among those
technologies is data encryption. Within Office 365, customer data is encrypted both at rest and while in
transit. Office 365 includes several encryption features that provide data protection out-of-the-box,
some of which are customer-managed and some of which are deployed as service-side controls.

The encryption technologies that are built into Office 365 and managed by Microsoft protect customer
data from specific risk scenarios and also provide failsafe in case other implemented controls fail to
protect customer data. The encryption technologies that are provided to customers enable them to add
additional layers of protection to their Office 365 content and data based on their own risk profiles.