Using Cloud KMS to Destroy CUI Keys Before Repair (MA.L2-3.7.3)

MA.L2-3.7.3 requires an organization to sanitize CUI from equipment before that equipment leaves organizational control for off-site maintenance. You can use Google Cloud KMS destroy encryption keys before repair as a cryptographic-erase method when the equipment’s CUI is encrypted with unique, asset-specific keys and the key version reaches the DESTROYED state before release to the repair vendor.

How do you configure Google Cloud KMS destroy encryption keys before repair?

Google Cloud KMS does not directly wipe a hard drive. Instead, it can make encrypted CUI infeasible to recover by permanently destroying the Cloud KMS key version that unwraps the data-encryption key. This approach is appropriate only where the organization has designed the affected system so that its CUI is encrypted, its encryption keys are not stored on the device, and a destroyed key version affects only the equipment being sanitized.

For MA.L2-3.7.3, create a separate Cloud KMS key for each repairable CUI-bearing asset or logically isolated storage set. Do not use one broadly shared production key: destroying a shared key could make unrelated systems, backups, or records unavailable.

1. Identify the asset-to-key relationship before a repair event. Maintain an asset record that identifies the equipment serial number, the storage volume or application data set, the Cloud KMS key ring, the crypto key, and the key version used to protect that asset’s CUI. The system must use envelope encryption: local CUI is encrypted with a data-encryption key, and that data-encryption key is wrapped by a Cloud KMS symmetric key.

2. Create a dedicated key ring in the required location. In the Google Cloud console, go to Navigation menu > Security > Key Management. Select the correct Google Cloud project, select the location that meets the organization’s data-residency requirements, and select Create key ring.

   For example, create the key ring cui-repair-sanitization in us-central1. Cloud KMS key ring locations cannot be changed later, so document the selected location in the system security plan and asset procedure.

3. Create one symmetric encryption key per repairable asset. From Key Management > cui-repair-sanitization > Create key, use these settings:

   • Key name: cui-edge-07
   • Protection level: HSM where the system and budget justify hardware-backed protection; otherwise document the approved use of Software
   • Purpose: Symmetric encrypt/decrypt
   • Algorithm: Google symmetric encryption
   • Key destruction schedule: 24 hours
   • Rotation period: Set according to the organization’s key-management standard; do not rely on rotation as a repair-sanitization action

   The 24-hour destruction schedule is the minimum supported Cloud KMS destruction interval. It means a key version is not permanently destroyed at the moment an administrator requests destruction, so the equipment must remain on-site and under organizational control until verification confirms DESTROYED.

4. Restrict who can destroy and restore key versions. Go to IAM & Admin > IAM, or open the key and select the Permissions tab. Give workload service accounts only the minimum key-use permissions required for encryption and decryption. Give the designated sanitization approver a custom role containing cloudkms.cryptoKeyVersions.get, cloudkms.cryptoKeyVersions.list, cloudkms.cryptoKeyVersions.update, and cloudkms.cryptoKeyVersions.destroy.

   Do not grant cloudkms.cryptoKeyVersions.restore to the repair coordinator or to service accounts. Keep restore authority separately controlled during the 24-hour destruction window, and remove it from all personnel once the organization has approved the destruction request.

5. Stop access to CUI before destroying the key version. Stop the affected workload, detach the device from approved networks where practical, terminate active sessions, and remove access to any locally cached decrypted data-encryption keys. Confirm that no alternate copy of the unwrapped key is stored in configuration files, removable media, backup scripts, or a local secrets vault.

6. Disable the active key version, then schedule destruction. In the Google Cloud console, use Security > Key Management > cui-repair-sanitization > cui-edge-07. Select the applicable key version, such as version 1, select Disable, confirm the action, then select Schedule destruction and confirm.

   The equivalent controlled command-line procedure is:

   gcloud kms keys versions disable 1 \
     --key=cui-edge-07 \
     --keyring=cui-repair-sanitization \
     --location=us-central1
   
   gcloud kms keys versions destroy 1 \
     --key=cui-edge-07 \
     --keyring=cui-repair-sanitization \
     --location=us-central1

7. Hold the equipment until permanent destruction completes. A version in DESTROY_SCHEDULED is unavailable for cryptographic operations, but it can still be restored by an authorized identity before the destruction time. For a defensible NIST SP 800-171 Rev. 2 MA.L2-3.7.3 process, do not release the device to a repair vendor while that recovery window exists. Release it only after Cloud KMS reports DESTROYED.

What does this look like in a real repair workflow?

Consider Meridian Precision Fabrication, a fictional 180-person metal fabrication and precision machining company. Its engineering team uses an on-premises edge server to stage controlled CAD packages, CMM inspection reports, and defense-contract work instructions for CNC cells. The server encrypts its CUI staging volume with a unique data-encryption key, while the data-encryption key is wrapped by the Cloud KMS key cui-edge-07.

When the edge server develops a motherboard fault and must go to an external repair depot, the compliance officer opens the maintenance ticket and confirms that cui-edge-07 is not used by any other server. The IT administrator stops the staging service, verifies the encrypted volume is detached, disables key version 1, and schedules its destruction. After the 24-hour destruction period, the officer verifies that version 1 is DESTROYED, attaches the evidence to the repair ticket, and releases the server under the company’s chain-of-custody procedure.

How do you verify the key destruction took effect?

Verification must show both that the device can no longer retrieve CUI and that Cloud KMS permanently destroyed the relevant key version. In the console, navigate to Security > Key Management > cui-repair-sanitization > cui-edge-07 and inspect the version status. The final state must be DESTROYED, not ENABLED, DISABLED, or DESTROY_SCHEDULED.

gcloud kms keys versions describe 1 \
  --key=cui-edge-07 \
  --keyring=cui-repair-sanitization \
  --location=us-central1

The returned record should show state: DESTROYED. Perform and document a controlled access test as well: attempt to start the application or unwrap the relevant data-encryption key using the normal workload identity. The expected result is a failed decryption operation. Do not test by copying CUI to a new device or by creating a new key version; the purpose is to confirm that the retired encrypted data cannot be decrypted.

What evidence should a CMMC assessor see?

Where does Cloud KMS fall short, and what fills the gap?

Using Cloud KMS to destroy encryption keys before an off-site repair is not a complete maintenance sanitization program by itself. It does not erase plaintext CUI from unencrypted boot partitions, USB devices, printer buffers, diagnostic logs, local caches, memory dumps, paper records, or separate backup media. It also does not prove that a local data-encryption key was never copied outside the intended key hierarchy.

Your procedure should therefore require a pre-release inspection and use the appropriate NIST SP 800-88 Rev. 1 sanitization method for every media type. For encrypted storage designed for cryptographic erase, key destruction can be the sanitization action when key management is sound. For unencrypted drives or uncertain key custody, use secure erase, overwrite, degaussing where applicable, or physical destruction. Pair the technical action with a repair authorization form, documented chain of custody, vendor restrictions, and a rule that no device leaves until the compliance officer confirms the required evidence is complete.

Next step: Ask your IT and asset-management owners to identify one CUI-bearing repairable system this quarter and run the documented Cloud KMS destruction workflow through a tabletop maintenance ticket before an actual repair is needed.