---
sourceDocument: Australia Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Configure Key Exchange

# Configure Key Exchange {#ariaid-title1}

* Release version: Australia
* 
* Updated May 26, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Key Management Framework (KMF) generates automatic key exchange requests for supported cryptographic modules during the fresh installation or upgrade of the instance, and manages the data encryption key locally for
the instance.

## Before you begin

A cryptographic module with a key must be created in both the target and source instances before using Key Exchange.

Role required: sn_kmf.cryptographic_manager

## About this task

Key Exchange requests are initiated from the target instance.

Automatic Key Exchange is active by default when cloning an instance, where the property is cloned to the target instance. Along with KMF, configure system properties to manage how keys are handled during an instance clone:  
* Turn off automatic key exchange: Set the glide_encryption.auto_key_exchange.enabled property to false for recurring clone requests.
* Send auto key exchange requests: Set this property to true.
{#configure-key-exchange__ul_b4x_fzt_tnb}  
Important:  
The base system property is set to true by default, meaning that automatic key exchange is activated when cloning an instance. This value must be set to false if you're using the [Rekey ciphertext with Key Exchange](https://www.servicenow.com/docs/clV8gGXj8UvxIA5sjtCU3w "Resource Exchange supports rekeying of ciphertext on the target instance that was encrypted with keys from the source. Rekey activity is tracked in the key life-cycle.") or the recurring Key Exchange functionality. See [Recurring Key Exchange walkthrough](https://www.servicenow.com/docs/cdlMugBlDun72VG8X082xQ "Use this walkthrough to set up a recurring key exchange in your instance using and Resource Exchange.") for additional details.

## Procedure

1. Navigate to AllKey ManagementResource Exchange RequestsNew.
2. On the form, fill in the fields.  
   {#configure-key-exchange__table_inh_bsr_b4b__entry__2}

   | Name | Description |
   |-|-|
   | Exchange Frequency | * Adhoc: Sends requests from the key target instance to the source instance. Enter the instance sys_id and the Host information for the Source. Not supported with Rekey of Key Exchange. * One Time Clone: One-time exchange of the keys from the source crypto specifications to the target instance. * Recurring Clone: Exchange keys from the selected source crypto specifications to the target instance on a defined recurring clone. {#configure-key-exchange__ul_kmc_2sr_b4b} |
   | \<Source or Target\> Instance sys_id | * Adhoc: Enter the sys_id for the source instance to request the keys from. * One Time Clone, Recurring Clone: Enter the sys_id for the target instance that sends the requests. Tip: Enter <kbd class="ph userinput">stats.do</kbd> in the application navigator to locate the instance ID. {#configure-key-exchange__ul_mdm_rqj_wpb} |
   | \<Source or Target\> Instance Host | Enter the host location or name of the source or target instance. Tip: For example <kbd class="ph userinput">instanceA.service-now.com</kbd> |
   | Crypto Specifications | The keys from the crypto specification in a crypto module define the keys to clone. For both one-time and recurring clone requests, your instance automatically creates a Resource Exchange module access policy. You don't need to configure a policy manually. Note: Select the lookup using list icon (![Lookup using list icon.]()) to browse the available cryptographic specifications. |
   | Enable Rekeying after Key Imported | Option to enable auto rekeying. |
   [Table 1. Resource Exchange Request form fields]

   {#configure-key-exchange__table_inh_bsr_b4b}
3. Select Submit.  
   If successful, a confirmation displays at the top of the form. The Requests table is updated with an entry of Request Pending in both the source instance and in the target instance. Open the Request Record to view the status of the request, the Imported Key Count, and the Total Key Count on the target or source host.  
4. In the source instance, approve the pending request to complete the exchange.  
   The approval process depends on the exchange frequency you selected.  

   One Time Clone or Recurring Clone
   :   The module access policy on the source instance auto-approves the request at clone time. No manual action is required.

   Adhoc

   :   Manually approve each pending request in the source instance:

       1. Log in to the source instance and navigate to AllKey ManagementResource Exchange Requests.
       2. Open a request with a status of Request Pending.
       3. Change the Status field to Request Approved.
       4. Select Update Request.  
          Important:  
          Select Update Request, not the standard Update button. Using the standard Update button does not complete the approval.
       5. Repeat for each remaining Request Pending entry.

       Note:  
   Not all crypto specifications requested may exist in the source instance. Requests for specifications not found in the source instance do not require approval.  
{#configure-key-exchange__steps_hqq_jrr_b4b}

## Result

After a key exchange is attempted, your non-production instance updates the protected.script.values.kmf.rekeyed system property. This property is visible in the System Properties \[sys_properties\] table after
a key exchange is attempted. If the encryption using the exchanged key is successful, this property has a value of true. Otherwise, the property has a value of false. If the value is
false, the instance will attempt to encrypt again the next day.

*[\>]: and then