Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The availability key is a root key that is automatically generated and provisioned when you create a data encryption policy (DEP). 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 and use it programmatically.
Its primary purpose is to support recovery from unexpected loss of the root keys you manage (for example, through mismanagement or malicious actions). If you lose control of your root keys, contact Microsoft Support to recover encrypted data with the availability key and migrate to a new DEP with new root keys you provision.
The availability key differs from Azure Key Vault keys in three ways:
- It provides a recovery or break glass option if both Azure Key Vault keys are lost.
- Logical separation of control and storage adds defense in depth and helps prevent total loss of keys or data due to a single failure.
- It supports high availability during temporary Azure Key Vault access issues for Exchange or Multi-Workload service encryption. SharePoint and OneDrive only use the availability key during an explicit recovery you request.
Microsoft shares responsibility for protecting your data through layered key management protections and processes. This approach reduces the risk of permanent key or data loss. You have sole authority to disable or destroy the availability key if you leave the service. By design, no one at Microsoft can directly access the availability key; only Microsoft 365 service code can use it.
For more information about how Microsoft secures keys, see the Microsoft Trust Center.
Availability key uses
The availability key supports recovery if an external attacker or malicious insider gains control of your key vault or if mismanagement causes loss of root keys. This recovery capability applies to all Microsoft 365 services that support Customer Key. Some services also use it for limited high availability scenarios.
The shared behavior:
- Recovery: Supports decrypting data so you can re-encrypt it with a new DEP and new Customer Keys.
- Programmatic use only: Access is through Microsoft 365 service code. There's no direct admin access.
- Not a substitute for operational keys: Your two Customer Keys remain the primary encryption roots.
Service behavior by workload:
Besides recovery, the service uses the availability key during short Azure Key Vault outages or network errors. This capability keeps mailbox data accessible to required background tasks:
- Anti-malware and anti-virus scanning
- eDiscovery
- Microsoft Purview Data Loss Prevention
- Mailbox moves
- Indexing
If an unwrap attempt with one Customer Key returns a system error, Exchange tries the second key. If both attempts fail with system errors, it falls back to the availability key. Access denied errors don't trigger it for user actions.
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 information, 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 stored secrets. All operations (including rotation and deletion) occur through automated service code.
Management operations are limited to specific engineers and require privilege escalation through Lockbox. Requests must include justification, are manager approved, time bound, and automatically revoked on expiration or sign out.
Exchange and Multi-workload availability keys are stored in an Exchange Active Directory secret store inside tenant specific containers in the Active Directory Domain Controller. This store is isolated from the one used by SharePoint and OneDrive.
SharePoint and OneDrive availability keys are stored in an internal secret store with front end servers providing application endpoints and a SQL Database back end. Keys are wrapped with secret store encryption keys that use AES-256 and HMAC. Those keys are stored in a logically isolated database area and further encrypted using RSA-2048 certificates issued by the Microsoft certificate authority (CA). Certificates are stored on the front end servers that perform database operations.
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 information, 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, the availability key lets you decrypt affected data and re-encrypt it under a new DEP with new Customer Keys.
- Create two new Customer Keys in separate Azure subscriptions.
- Create a new Exchange DEP.
- Assign the DEP to impacted mailboxes.
- Allow background re-encryption (can take up to 72 hours). Availability key protects data during transition.
How the availability key is used
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:
- Decrypt the DEP Key using a Customer Key.
- Use the decrypted DEP Key to decrypt the Mailbox Key.
- Use the decrypted Mailbox Key to decrypt the mailbox and provide access to the data.
Availability key triggers
Microsoft 365 triggers the availability key only in specific circumstances, and those circumstances differ depending on the service.
Microsoft 365 follows this sequence when it needs a DEP Key for a mailbox operation:
- It reads the data encryption policy (DEP) assigned to the mailbox to identify the two Customer Keys stored in Azure Key Vault.
- It randomly selects one of the two keys and sends a request to Azure Key Vault to unwrap (decrypt) the DEP Key.
- If that request fails, it sends a second request using the alternate key.
- If both requests fail, Microsoft 365 evaluates the failure type:
- System errors (for example, Azure Key Vault service unavailable, timeouts, transient network faults): The availability key is used to unwrap the DEP Key. The DEP Key then decrypts the mailbox key and the service completes the operation.
- Access denied errors (key deleted, permissions removed, intentional, or accidental removal during purge processes): The availability key isn't used for user initiated actions. The user request fails and returns an error.
Important
Service code maintains valid tokens for required internal processing. Until you delete the availability key, internal Exchange operations (such as mailbox moves, indexing, anti-virus scanning, eDiscovery, DLP) can still fall back to the availability key when both Customer Keys are unreachable—whether the cause was a system error or access denied. This design helps preserve service resilience while you investigate.
Audit logs and the availability key
Automated background processing (antivirus, eDiscovery, DLP, indexing) doesn't generate customer-visible logs; Microsoft personnel don't access data during normal operations.
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.
Fallback events create Unified Audit Log entries:
- Record type: CustomerKeyServiceEncryption
- Activity: Fallback to Availability Key
Fields include date, time, activity, organization ID, DEP ID, Policy ID, Scope Key Version ID, Request ID (Management Activity common schema).
Within the log details, the field Workload displays Exchange.
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.
- Multi-workload 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
