Learn about the availability key for Customer Key

The availability key is a root key that is automatically generated and provisioned when you create a data encryption policy. Microsoft 365 stores and protects this key.

The availability key functions like the two root keys you supply for Customer Key. It wraps the keys one tier lower in the key hierarchy. Unlike the keys you manage in Azure Key Vault, you can't directly access the availability key. Microsoft 365 automated services manage it programmatically. These services perform automated operations without direct access to the key.

The main purpose of the availability key is to support recovery from unexpected loss of the root keys you manage. This loss might result from mismanagement or malicious actions. If you lose control of your root keys, contact Microsoft Support for assistance with recovery using the availability key. Use this key to migrate to a new data encryption policy with new root keys that you provision.

The availability key differs from Azure Key Vault keys in storage and control for three reasons:

• It provides a recovery or "break-glass" option if both Azure Key Vault keys are lost.
• Its separation of logical control and storage location adds defense-in-depth and helps protect against the total loss of keys or data due to a single point of failure.
• It supports high availability if Microsoft 365 can't reach your Azure Key Vault due to temporary errors. This scenario applies only to Exchange service encryption. SharePoint and OneDrive don't use the availability key unless you explicitly request recovery.

Microsoft shares responsibility for protecting your data through layered key management protections and processes. This approach reduces the risk of permanent loss or destruction of all keys and your data. You have sole authority to disable or destroy the availability key if you leave the service. By design, no one at Microsoft can access the availability key. It's accessible only by Microsoft 365 service code.

For more details about how Microsoft secures keys, see the Microsoft Trust Center.

Availability key uses

The availability key supports recovery in cases where an external attacker or a malicious insider gains control of your key vault, or when mismanagement causes the loss of root keys. This recovery capability applies to all Microsoft 365 services that support Customer Key.

Each service uses the availability key differently. Microsoft 365 uses the availability key only in the scenarios described in the following sections.

Exchange

In addition to supporting recovery, Exchange uses the availability key to maintain data access during transient or intermittent issues that prevent the service from reaching root keys in Azure Key Vault. If the service can't access either of your Customer Keys due to a temporary error, it automatically uses the availability key.

The service doesn't access the availability key directly. Instead, automated systems in Exchange use it as part of a fallback process during transient failures. This usage supports back-end operations such as anti-virus scanning, ediscovery, Microsoft Purview Data Loss Prevention, mailbox moves, and data indexing.

SharePoint and OneDrive

For SharePoint and OneDrive, the availability key is used only for recovery scenarios. It's never used during normal operations.

You must explicitly request that Microsoft use the availability key in a recovery event. Automated service operations rely solely on your Customer Keys in Azure Key Vault.

For more details about the key hierarchy and how these services handle encryption, see How SharePoint and OneDrive use the availability key.

Availability key security

Microsoft shares responsibility for protecting your data by generating the availability key and applying strict controls to safeguard it.

Customers don't have direct access to the availability key. For example, you can roll only the keys you manage in Azure Key Vault. Microsoft manages the availability key through automated service code without exposing it to users.

For more details, see Roll or rotate a Customer Key or an availability key.

Availability key secret stores

Microsoft protects availability keys in access-controlled internal secret stores, similar to Azure Key Vault. Access controls prevent Microsoft administrators from directly retrieving the secrets stored within. All secret store operations, including key rotation and deletion, are performed through automated commands that don't involve direct access to the availability key.

Management operations in these secret stores are limited to specific engineers and require privilege escalation through an internal tool called Lockbox. Escalation must be approved by a manager and include a valid justification. Lockbox ensures that access is time bound and automatically revoked when the time limit expires or the engineer signs out.

Exchange availability keys are stored in an Exchange Active Directory secret store. Keys are kept inside tenant-specific containers within the Active Directory Domain Controller. This storage location is separate and isolated from the secret store used by SharePoint and OneDrive.

SharePoint and OneDrive availability keys are stored in an internal secret store managed by the service team. This store includes front-end servers that expose application endpoints and a SQL Database as the back end. Availability keys are stored in the database and wrapped using secret store encryption keys.

These encryption keys use AES-256 and HMAC to protect the availability key at rest. The encryption keys are stored in a logically isolated part of the same database and are further encrypted using RSA-2048 certificates issued by the Microsoft certificate authority (CA). These certificates are stored on the front-end servers that handle operations against the database.

Defense-in-depth

Microsoft uses a defense-in-depth strategy to help prevent malicious actors from compromising the confidentiality, integrity, or availability of customer data stored in the Microsoft Cloud. Specific preventive and detective controls are in place to protect the secret store and the availability key as part of this layered security approach.

Microsoft 365 is designed to prevent misuse of the availability key. The application layer is the only interface that can use keys—including the availability key—for encryption and decryption. Only Microsoft 365 service code can interpret and traverse the key hierarchy. Logical isolation exists between the storage locations of Customer Keys, availability keys, other hierarchical keys, and customer data. This separation reduces the risk of data exposure if any location is compromised. Each layer in the key hierarchy includes continuous intrusion detection to protect stored data and secrets.

Access controls prevent unauthorized access to internal systems, including availability key secret stores. Microsoft engineers don't have direct access to these stores. For more details, see Administrative Access Controls in Microsoft 365.

Technical controls also prevent Microsoft personnel from signing in to highly privileged service accounts, which attackers could otherwise use to impersonate Microsoft services. These controls block interactive sign-in attempts.

Security logging and monitoring are other safeguards in Microsoft’s defense-in-depth approach. Service teams deploy monitoring solutions that generate alerts and audit logs. All logs are uploaded to a central repository, where they're aggregated and analyzed. Internal tools automatically evaluate these records to ensure services remain secure, resilient, and operating as expected. Unusual activity is flagged for review.

Any event that signals a potential violation of the Microsoft Security Policy is escalated to Microsoft security teams. Microsoft 365 security alerts are configured to detect attempted access to availability key secret stores and unauthorized sign-in attempts to service accounts. The system also detects deviations from expected baseline service behavior. Any attempt to misuse Microsoft 365 services triggers alerts and can result in the offender being removed from the Microsoft Cloud environment.

Use the availability key to recover from key loss

If you lose control of your Customer Keys, you can use the availability key to recover and re-encrypt your data.

Recovery procedure for Exchange

If you lose control of your Customer Keys, you can use the availability key to recover your data and bring affected Microsoft 365 resources back online. The availability key continues to protect your data during recovery.

To fully recover from key loss:

1. Create new Customer Keys in Azure Key Vault.
2. Create a new Data Encryption Policy (DEP) using the new keys.
3. Assign the new DEP to the mailboxes that were encrypted with the compromised or lost keys.

This re-encryption process could take up to 72 hours, which is the standard duration for changing a DEP.

Recovery procedure for SharePoint and OneDrive

For SharePoint and OneDrive, the availability key is only used during a recovery scenario. You must explicitly ask Microsoft to activate the availability key.

To start the recovery process, contact Microsoft Support. Once activated, the availability key automatically decrypts your data so you can encrypt it with a newly created Data Encryption Policy (DEP) and new Customer Keys.

Recovery time depends on the number of sites in your organization. Most customers come back online within about four hours after requesting availability key activation.

How Exchange uses the availability key

When you create a Data Encryption Policy (DEP) with Customer Key, Microsoft 365 generates a DEP Key associated with that policy. The service encrypts the DEP Key three times: once with each of your Customer Keys and once with the availability key. Only the encrypted versions of the DEP Key are stored. A DEP Key can be decrypted only with one of the Customer Keys or the availability key.

The DEP Key is used to encrypt Mailbox Keys, which in turn encrypt individual mailboxes.

Microsoft 365 uses the following process to decrypt and provide access to mailbox data:

1. Decrypt the DEP Key using a Customer Key.
2. Use the decrypted DEP Key to decrypt the Mailbox Key.
3. Use the decrypted Mailbox Key to decrypt the mailbox and provide access to the data.

How SharePoint and OneDrive use the availability key

The SharePoint and OneDrive architecture for Customer Key and the availability key differs from Exchange.

When an organization begins using customer-managed keys, Microsoft 365 creates an organization-specific tenant intermediate key (TIK). Microsoft 365 encrypts the TIK twice—once with each of your Customer Keys—and stores only the encrypted versions. A TIK can only be decrypted using one of the Customer Keys. The TIK is then used to encrypt site keys, which encrypt blob keys (also called file chunk keys). For larger files, the service might divide them into multiple chunks, each with a unique key. These file chunks, or blobs, are encrypted with blob keys and stored in Azure Blob Storage.

Microsoft 365 uses the following steps to decrypt customer files:

1. Decrypt the TIK using a Customer Key.
2. Use the decrypted TIK to decrypt a site key.
3. Use the decrypted site key to decrypt a blob key.
4. Use the decrypted blob key to decrypt the blob.

To improve performance, Microsoft 365 sends two decryption requests to Azure Key Vault slightly offset in time. Whichever request finishes first provides the result; the other is canceled.

If you lose access to your Customer Keys, Microsoft 365 uses the availability key to decrypt the TIK. Microsoft encrypts each TIK with the availability key and stores this version alongside the Customer Key–encrypted versions. The availability key is only used if you contact Microsoft to initiate a recovery.

For scale and reliability, decrypted TIKs are cached in memory for a limited time. About two hours before a cached TIK expires, Microsoft 365 attempts to decrypt it again to extend its lifetime. If this process fails repeatedly, Microsoft 365 raises an alert to engineering before the cache expires. If recovery is needed, Microsoft decrypts the TIK using the availability key, then re-onboards your tenant using the decrypted TIK and a new set of Customer Keys.

Currently, Customer Key encrypts and decrypts SharePoint file data in Azure Blob Storage, but not list items or metadata stored in SQL Database. Microsoft doesn't use the availability key for SharePoint or OneDrive unless you explicitly request recovery. Human access to customer data remains protected by Customer Lockbox.

Availability key triggers

Microsoft 365 triggers the availability key only in specific circumstances, and those circumstances differ depending on the service.

Triggers for Exchange

Microsoft 365 follows this process when accessing Customer Keys for a mailbox:

1. It reads the data encryption policy (DEP) assigned to the mailbox to identify the two Customer Keys stored in Azure Key Vault.

2. It randomly selects one of the two keys and sends a request to Azure Key Vault to unwrap the DEP key.

3. If that request fails, it sends a second request using the alternate key.

4. If both requests fail, Microsoft 365 examines the results and responds in one of two ways:

   • If both requests failed with a system error (for example, Azure Key Vault is unavailable or can't respond):

     • Microsoft 365 uses the availability key to decrypt the DEP key.

     • It then uses the DEP key to decrypt the mailbox key and fulfill the user request.

   • If both requests failed with an "access denied" error (such as from deliberate, accidental, or malicious key removal, including during the data purge process):

     • Microsoft 365 doesn't trigger the availability key for user actions.

     • The user request fails and returns an error message.

Triggers for SharePoint and OneDrive

For SharePoint and OneDrive, Microsoft 365 never uses the availability key unless you're in a recovery scenario. To start the recovery process, you must contact Microsoft and explicitly request that the availability key be used.

Audit logs and the availability key

Automated systems in Microsoft 365 process data as it flows through the service. These systems support features like antivirus, eDiscovery, data loss prevention, and indexing. Microsoft 365 doesn’t generate logs that are visible to customers for this background activity. Also, Microsoft personnel don’t access your data during normal system operations.

Exchange availability key logging

When Exchange accesses the availability key to provide service, Microsoft 365 creates customer-visible logs. You can access these logs from the Microsoft Purview portal. Each time the service uses the availability key, it generates an audit log entry.

This entry uses a new record type called Customer Key Service Encryption with an activity type of Fallback to Availability Key. These labels help admins filter Unified Audit Log search results to find availability key records.

Log entries include the date, time, activity, organization ID, and data encryption policy ID. These records are part of the Unified Audit Logs and appear under the Audit Log Search tab in the Microsoft Purview portal.

Exchange availability key records follow the Microsoft 365 Management Activity common schema. They also include custom parameters: Policy ID, Scope Key Version ID, and Request ID.

SharePoint and OneDrive availability key logging

Availability key logging isn’t available yet for SharePoint or OneDrive. Microsoft only activates the availability key for recovery purposes when you request it. Because of that, you already know every event when the availability key is used for these services.

Availability key in the Customer Key hierarchy

Microsoft 365 uses the availability key to wrap the tier of keys below it in the Customer Key encryption hierarchy. Each service has a different key hierarchy. The key algorithms also vary between availability keys and other keys in the hierarchy.

The availability key algorithms used by each service are:

• Exchange availability keys use AES-256.
• SharePoint and OneDrive availability keys use RSA-2048.

Encryption ciphers used to encrypt keys for Exchange

Encryption ciphers used to encrypt keys for SharePoint

Related articles

• Service encryption with Customer Key

• Set up Customer Key

• Manage Customer Key

• Roll or rotate a Customer Key or an availability key