Bring your own key (BYOK) - Details - Azure Information Protection (2023)

  • Article
  • 13 minutes to read


you are looking forMicrosoft Scope Information Protection, previous Microsoft Information Protection (MIP)?

The Azure Information Protection Add-in for Office is now in maintenance mode and we recommend that you use itLabels built into your Office 365 applications and services. learn more aboutSupport status of other Azure Information Protection components.

Organizations with an Azure Information Protection subscription can configure their tenant with their own key instead of a Microsoft-generated default key. This setting is often referred to as Bring Your Own Key (BYOK).

BYOK eusage logWork seamlessly with apps integrated with the Azure Rights Management service that uses Azure Information Protection.

Compatible apps include:

  • Cloud-Services, such as Microsoft SharePoint or Microsoft 365

  • local servicesRunning Exchange and SharePoint applications that use the Azure Rights Management service through the RMS connector

  • client applications, als Office 2019, Office 2016 und Office 2013


If necessary, apply additional security to specific documents by using an additional local key. For more information, seeDouble Key Encryption (DKE)-Schutz(nur Unified Labeling-Client).

Azure Key Vault key store

Customer-generated keys must be stored in Azure Key Vault for BYOK protection.


Using HSM protected keys in Azure Key Vault requires aAzure Key Vault premium service tier, which incurs an additional monthly subscription fee.

Sharing keystores and signatures

We recommend using adedicated key safeto your tenant key. Dedicated key stores help ensure that calls from other services have no causeservice limitsbe surpassed. Exceeding service limits for the key store that stores the tenant key can result in a throttling of the response time for the Azure Rights Management service.

Because different services have different key management requirements, Microsoft also recommends usinga dedicated Azure subscriptionfor your key safe. Dedicated Azure subscriptions:

  • Protect yourself against misconfigurations

  • You are more secure when different services have different administrators

    (Video) Secure your cloud by securing your keys - Bring your own key (BYOK) for Microsoft Azure

To share an Azure subscription with other services that use Azure Key Vault, ensure that the subscription has a common group of administrators. Confirming that all admins using the subscription have a solid understanding of all the keys they have access to means they are less likely to misconfigure their keys.

Example- Use a shared Azure subscription if the administrators of your Azure Information Protection tenant key are the same people who manage your Office 365 customer keys and online CRM keys. If the main administrators of these services are different, we recommend using dedicated subscriptions.

Benefits of using Azure Key Vault

Azure Key Vault provides a consistent, centralized key management solution for many cloud-based and on-premises services that use encryption.

In addition to managing keys, Azure Key Vault gives your security administrators the same management experience for storing, accessing, and managing certificates and secrets (such as passwords) for other services and applications that use cryptography.

Storing your tenant key in Azure Key Vault provides the following benefits:

Integrated interfacesAzure Key Vault supports several built-in interfaces for managing keys, including PowerShell, CLI, REST API, and the Azure portal.

Other services and tools have been integrated with Key Vault for features optimized for specific tasks, such as: B. Surveillance.

For example, analyze your primary usage logs with Operations Management Suite log analysis, set alerts when certain criteria are met, and so on.

segregation of dutiesAzure Key Vault provides role separation as an accepted security best practice.

The segregation of duties ensures that Azure Information Protection administrators can focus on their most important priorities, including managing classification and data protection, as well as encryption keys and policies for specific security or compliance needs.

Master key locationAzure Key Vault is available in multiple locations and supports organizations with restrictions on where master keys can be located.

For more information, seeProducts available by regionPage on the Azure website.

Separate security domainsAzureKey Vault uses separate security domains for its data centers in regions such as North America, EMEA (Europe, Middle East and Africa), and Asia.

Azure Key Vault also uses different Azure instances like Microsoft Azure Germany and Azure Government.

unified experienceAzure Key Vault also allows security administrators to store, access, and manage certificates and secrets such as passwords for other services that use encryption.

Using Azure Key Vault for your tenant keys provides a seamless user experience for admins managing all of these items.

To get the latest updates and learn how you use other servicesAzure key store, visit aBlog des Azure Key Vault-Teams.

Usage log for BYOK

Each application that makes requests to the Azure Rights Management service generates usage logs.

Although usage logging is optional, we recommend using near real-time usage logs from Azure Information Protection to see exactly how and when your tenant key is being used.

For more information on key usage logging for BYOK, seeLogging and analysis of usage of Azure Information Protection protection.


For additional security, the Azure Information Protection usage log can be crossed withAzure Key Vault registration. Key Vault logs provide a reliable way to independently monitor that your key is being used only by the Azure Rights Management service.

If needed, instantly revoke access to your key by removing keystore permissions.

Options for creating and storing your key


For more information on the Managed HSM offering and how to set up a vault and key, seeAzure Key Vault-Dokumentation.

Further instructions for granting the key authorization are described below.

BYOK supports keys created in Azure Key Vault or on-premises.

If you create your key locally, you must transfer or import it to your key vault and configure Azure Information Protection to use the key. Perform any additional key management from Azure Key Vault.

Options to create and store your own key:

  • Created in Azure Key Vault. Create and store your key in Azure Key Vault as an HSM-protected key or software-protected key.

  • Created on the site. Create your key locally and transfer it to Azure Key Vault using one of the following options:

    • HSM protected key transmitted as HSM protected key. The most typical chosen method.

      (Video) The encryption dilemma - Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK)?

      While this method creates the lion's share of administrative overhead, your organization may need to follow certain regulations. HSMs used by Azure Key Vault are FIPS 140-2 Level 2 validated.

    • Software-protected key that is converted and pushed to Azure Key Vault as an HSM-protected key. This method is only supported ifmigrando zu Active Directory Rights Management Services (AD RMS).

    • Created locally as a software-protected key and transferred to Azure Key Vault as a software-protected key. This method requires a .pfx certificate file.

For example, to use a locally created key, do the following:

  1. Generate your tenant key on-site according to your company's security and IT guidelines. This key is the master copy. It stays in place and is needed as a backup.

  2. Make a copy of the master key and securely transfer it from your HSM to Azure Key Vault. During this process, the master copy of the key never leaves the hardware protection boundary.

Once transferred, the copy of the key is protected by Azure Key Vault.

Export your trusted publishing domain

If you decide to stop using Azure Information Protection, you will need a trusted publishing domain (TPD) to decrypt content protected by Azure Information Protection.

However, exporting your TPD is not supported when using BYOK for your Azure Information Protection key.

To prepare for this scenario, make sure you create an appropriate TPD in advance. For more information, seeHow to prepare an Azure Information Protection cloud exit plan.

BYOK implementation for your Azure Information Protection tenant key

Use the following steps to implement BYOK:

  1. Check the BYOK requirements
  2. Select a Key Vault location
  3. Create and configure your key

BYOK Requirements

BYOK requirements vary based on system configuration. Verify that your system meets the following prerequisites, if necessary:

blue subscriptionRequired for all configurations.
For more information, seeMake sure you have a BYOK-enabled Azure subscription.
Module AIPService PowerShell for Azure Information ProtectionRequired for all configurations.
For more information, seeInstalling the AIPService PowerShell module.
Azure Key Vault requirements for BYOKIf you're using an HSM-protected key that was created locally, make sure it also meets the requirementsBYOK Requirementslisted in the Azure Key Vault documentation.
Thales-Firmware-Version 11.62You must have Thales firmware version 11.62 if you are migrating from AD RMS to Azure Information Protection using a software key to a hardware key and are using Thales firmware for your HSM.
Bypass the firewall to get trusted services from MicrosoftIf the key vault that contains your tenant key uses virtual network service endpoints for Azure Key Vault, you must allow trusted Microsoft services to bypass this firewall.
For more information, seeVirtual network service endpoints for Azure Key Vault.

Make sure you have a BYOK-enabled Azure subscription

Your Azure Information Protection tenant must have an Azure subscription. If you don't have one yet, you can sign up for account. However, to use an HSM-protected key, you must have the Azure Key Vault Premium service tier.

The free Azure subscription, which provides access to Azure Active Directory settings and Azure Rights Management custom template settings, isNOenough to use Azure Key Vault.

To confirm that you have a BYOK-compliant Azure subscription, follow the steps below to verify using the followingAzure-PowerShellCmdlets:

  1. Sign in to Azure PowerShell as an administrator.

  2. Sign in as a global administrator for your Azure Information Protection tenantConnect-The-Account.

  3. Copy the displayed token to the clipboard. Then go to in a browser paste the copied token.

    For more information, seeSign in with Azure PowerShell.

  4. Enter in your PowerShell sessionGet-AzSubscriptionand confirm that the following values ​​are displayed:

    • Your signature name and identification
    • Your Azure Information Protection tenant ID
    • Confirm that the state is enabled

    If no value is returned and you return to the prompt, it means you don't have an Azure subscription to use for BYOK.

Choosing the key location

When you create a keystore to store the key to be used as your tenant key for Azure information, you must specify a location. This location is either an Azure region or an Azure instance.

Make your choice first for compliance and then for minimizing network latency:

(Video) BYOK to Azure

  • If you choose to use the BYOK key method for compliance reasons, those compliance requirements may also determine which region or instance of Azure can be used to store your Azure Information Protection tenant key.

  • All cryptographic calls to the chain protection of your Azure Information Protection key. Therefore, you should minimize the network latency required for these calls by creating your key vault in the same Azure region or instance as your Azure Information Protection tenant.

To identify the location of your Azure Information Protection tenant, use theGet-AipServiceConfiguration​ PowerShell cmdlet and identify the region using the URLs. For example:


The region is recognizable, and in this example it is in North America.

The following table lists the recommended Azure instances and regions to minimize network latency:

Azure region or instanceRecommended location for your key store
effective valuevon.aadrm.comNorth Central USAÖEastern United States
effective valueUE.aadrm.comNorthern EuropeÖEastern Europe
effective​it is from asiaÖSouth East Asia
effective valueone.aadrm.comwestern United StatesÖEastern United States
effective​Central USÖUS East 2
effective valueaadrm.esUS Government VirginiaÖUS Government Arizona
effective valueaadrm.cnOstchina 2ÖNordchina 2

Create and configure your key


For information specific to managed HSMs, seeEnable key authorization for managed HSM keys using the Azure CLI.

Create an Azure Key Vault and the key you want to use for Azure Information Protection. For more information, seeAzure Key Vault-Dokumentation.

Consider the following to configure Azure Key Vault and the key for BYOK:

  • Key length requirements
  • Create an HSM-protected key locally and transfer it to your keystore
  • Configure Azure Information Protection with your key ID
  • Authorize the Azure Rights Management service to use your key

Key length requirements

When creating your key, make sure the key length is either 2048 bits (recommended) or 1024 bits. Azure Information Protection doesn't support other key lengths.


1024-bit keys do not provide adequate protection for active tenant keys.

Microsoft does not support using shorter key lengths, e.g. B. 1024-bit RSA keys, and the associated use of protocols that offer an insufficient level of protection, e.g. B. SHA-1.

Create an HSM-protected key locally and transfer it to your keystore

To create an HSM-protected key locally and transfer it to your key vault as an HSM-protected key, follow the procedures in the Azure Key Vault documentation:How to generate and transfer HSM protected keys to Azure Key Vault.

For Azure Information Protection to use the transferred key, all Key Vault operations must be allowed on the key, including:

  • encrypt
  • Description
  • wrap key
  • develop keys
  • Sign
  • check over

By default, all Key Vault operations are allowed.

Run the following PowerShell command to review the operations allowed on a specific key:

(Get-AzKeyVaultKey -VaultName <key store name> -Name <key name>).Attributes.KeyOps

Add allowed operations with if neededUpdate-AzKeyVaultKeyIt is inKeyOpsParameter.

Configure Azure Information Protection with your key ID

Keys stored in Azure Key Vault have a key identifier.

The key ID is a URL containing the key store name, key container, key name, and key version. For example:

Configure Azure Information Protection to use your key by providing the keystore URL.

(Video) Office365 Data Security With Customer (BYOK) Azure Key Vault

Authorize the Azure Rights Management service to use your key

The Azure Rights Management service must be authorized to use your key. Azure Key Vault admins can enable this authorization through the Azure portal or Azure PowerShell.

Enable key authorization through the Azure portal
  1. Sign in to the Azure portal and go toSafes for keys><the name of your keystore>>access policies>Add new.

  2. VonAdd access policyBoard ofConfigure from template (optional)Select list boxAzure BYOK privacyand then clickOK.

    The selected model has the following configuration:

    • Öchoose mainThe value is defined asMicrosoft Rights Management-Dienste.
    • Selectedkey permissionscontainTake,Description, miSign.
Enable key authorization with PowerShell

Ejecute el cmdlet Key Vault PowerShell,Set-AzKeyVaultAccessPolicyand grant permissions to the Azure Rights Management service principal using the GUID00000012-0000-0000-c000-000000000000.

For example:

Set-AzKeyVaultAccessPolicy -VaultName 'ContosoRMS-kv' -ResourceGroupName 'ContosoRMS-byok-rg' -ServicePrincipalName 00000012-0000-0000-c000-000000000000 -PermissionsToKeys descifrar, firmar, obtener
Enable key authorization for managed HSM keys using the Azure CLI

How to grant user permissions to the Azure Rights Management service principal asManaged HSM encryptionUser, run the following command:

az Keyvault-Rollenzuweisung create --hsm-name "ContosoMHSM" --role "Managed HSM Encryption User" --assignee-principal-type ServicePrincipal --assignee --scope /keys/contosomhskey


  • ContosoMHSMis an example HSM name. When you run this command, replace this value with your own HSM name.

ÖUser-managed cryptographic HSMThe user role allows you to decrypt, sign, and obtain key credentials, all of which are required for the functionality of the managed HSM.

Configure Azure Information Protection to use su cle

After completing all of the above steps, you can configure Azure Information Protection to use this key as your organization's tenant key.

Run the following commands using the Azure RMS cmdlets:

  1. Connect to the Azure Rights Management service and enter the following:

  2. run orUse the AipServiceKeyVaultKey cmdlet, which specifies the URL of the key. For example:

    Use-AipServiceKeyVaultKey -KeyVaultKeyUrl "<version-chave>"


    In this example<key version>is the key version you want to use. If you don't specify the version, the current version of the key is used by default and the command seems to work. However, if your key is later updated or renewed, the Azure Rights Management service will stop working for your tenant, even if you change theUsar-AipServiceKeyVaultKeycommand again.

    use theGet-AzKeyVaultKeyas needed to get the current key version number.

    For example:Get-AzKeyVaultKey -VaultName "contosorbs-kv" -Keyname "contosorbs-byok"

    To confirm that the key URL is configured correctly for Azure Information Protection, run theGet-AzKeyVaultKeyCommand in Azure Key Vault to display the key's URL.

  3. If the Azure Rights Management service is already enabled, run itSet-aipServiceKeyPropertiesto instruct Azure Information Protection to use this key as the tenant active key for the Azure Rights Management service.

Azure Information Protection is now configured to use your key instead of the default Microsoft-generated key that was automatically generated for your tenant.

Next Steps

After configuring BYOK protection, proceed toIntroduction to the tenant root keyfor more information on using and managing your key.


1. Salesforce Shield Platform Encryption Bring Your Own Keys (BYOK)
2. Bring Your Own Key to the Cloud With Vault
3. Ready, Set, Secure: Bring Your Own Key
(Set Solutions)
4. Azure Information Protection Scanner Setup in 5 minutes!
(Graham Hosking)
5. Securing Microsoft 365 Data with Service Encryption
6. Setup Azure Information Protection
(Concepts Work)
Top Articles
Latest Posts
Article information

Author: Lakeisha Bayer VM

Last Updated: 04/15/2023

Views: 5559

Rating: 4.9 / 5 (69 voted)

Reviews: 84% of readers found this page helpful

Author information

Name: Lakeisha Bayer VM

Birthday: 1997-10-17

Address: Suite 835 34136 Adrian Mountains, Floydton, UT 81036

Phone: +3571527672278

Job: Manufacturing Agent

Hobby: Skimboarding, Photography, Roller skating, Knife making, Paintball, Embroidery, Gunsmithing

Introduction: My name is Lakeisha Bayer VM, I am a brainy, kind, enchanting, healthy, lovely, clean, witty person who loves writing and wants to share my knowledge and understanding with you.