Shielded VM overview

This page discusses key concepts and terminology for Shielded VM. Toget started using Shielded VM, try thequickstart orseeModifying Shielded VM options.

Shielded VM offers verifiable integrity of your Compute Engine VMinstances, so you can be confident your instances haven't been compromised byboot- or kernel-levelmalware orrootkits.

Key benefits of Shielded VMs

Shielded VMs deliver multiple strategic advantages such ascomprehensive protection against firmware-level attacks, bootloadermodifications, and kernel-level compromises.

  • Operational benefits: include reduced security incident response time,simplified compliance management, and enhanced visibility into systemintegrity.

  • Business advantages: include increased confidence in cloud infrastructure,reduced risk of security breaches, and improved regulatory compliance posture.

Core security architecture of Shielded VMs

Shielded VMs implement a triple shield architecture. This architectureprovides robust protection from the ground up as described in the followingtable.

FeatureWhat it isHow it helps
Secure boot technologyA UEFI firmware feature that ensures your VM boots only with authentic, signed software by verifying the digital signature of all boot components such as firmware drivers, OS bootloader, and the kernel.
For more information, seeSecure boot.		Prevents unauthorized or tampered bootloaders and kernels from loading, stopping many bootkits and rootkits. Halts the boot process if a component lacks a trusted signature.
Virtual trusted platform module (vTPM)A virtualized security processor, providing each Shielded VM with a dedicated vTPM for hardware-level security.
For more information, seeVirtual trusted platform module (vTPM).		 Provides the following features:
  • Measured boot: Takes cryptographic hashes of critical boot components such as firmware, bootloader, kernel, and drivers and stores them securely, creating a verifiable boot chain.
  • Secure key generation and storage: Generates and stores cryptographic keys, for example, for BitLocker, releasing them only if the measured boot verifies the boot state as trusted.
Advanced integrity monitoringA monitoring system that establishes a golden baseline of boot measurements taken during the measured boot.
For more information, seeIntegrity monitoring.		Compares current boot measurements against the trusted baseline on subsequent boots. Generates alerts in Cloud Logging and Security Command Center if it detects discrepancies, enabling proactive investigation of potential integrity violations.

Secure Boot

Secure Boot helps ensure that the system only runs authentic software byverifying the digital signature of all boot components, and halting the bootprocess if signature verification fails.

Shielded VM instances run Google-built UEFI firmware. As an additionallayer of security, and in line with standard Google practices for all itsproduction software, this firmware is cryptographically signed and verifiedusing Google's internal Certificate Authority, and this validation is done onall firmware, regardless of whether the Secure Boot feature is enabled. Thisverification ensures the firmware's integrity, confirming it's authentic andunmodified and establishing theroot of trust for Secure Boot.

TheUnified Extensible Firmware Interface (UEFI) 2.3.1firmware,securely manages the certificates that contain the keys used by the softwaremanufacturers to sign the system firmware, the system boot loader, and anybinaries they load. Shielded VM instances use UEFI firmware.

On each boot, the UEFI firmware verifies the digital signature of each bootcomponent against the secure store of approved keys. Any boot component thatisn't properly signed, or isn't signed at all, isn't allowed to run.

If this occurs, the VM instance'sserial console logwill have an entry containing the stringsUEFI: Failed to load image andStatus: Security Violation, along with a description of the bootoption that failed. To troubleshoot the failure, disable Secure Boot byusing the instructions inModifying Shielded VMoptions so that you can boot theVM instance, diagnose and resolve the issue, then re-enable Secure Boot.

Virtual Trusted Platform Module (vTPM)

A vTPM is a virtualizedtrusted platformmodule,which is a specialized computer chip you can use to protect objects, like keysand certificates, that you use to authenticate access to your system. TheShielded VM vTPM is fully compatible with theTrusted Computing Group (TPM) library specification 2.0and uses theBoringSSL library.The BoringSSL library relies on the BoringCrypto module. For FIPS 140-2 detailsabout to the BoringCrypto module, seeNIST Cryptographic Module Validation Program Certificate #3678.

The Shielded VM vTPM enablesMeasured Boot byperforming the measurements needed to create a known good boot baseline, calledtheintegrity policy baseline. The integrity policy baseline is used forcomparison with measurements from subsequent VM boots to determine if anythinghas changed.

You can also use the vTPM to protect secrets through shielding orsealing.See theGo-TPM project onGitHub for Go language examples that illustrate how to use a vTPM for thispurpose.

Measured Boot

During Measured Boot, a hash of each component (for example, the firmware,bootloader, or kernel) is created as the component is loaded, and that hash isthen concatenated and rehashed with the hashes of any components that havealready been loaded, as illustrated here:

Measured Boot process diagram

This information identifies both the components that were loaded, and theirload order.

The first time you boot a VM instance, Measured Boot creates the integritypolicy baseline from the first set of these measurements, and securely storesthis data. Each time the VM instance boots after that, these measurements aretaken again, and stored in secure memory until the next reboot. Having these twosets of measurements enablesintegrity monitoring,which you can use to determine if there have been changes to a VM instance'sboot sequence.

Integrity monitoring

Integrity monitoring helps you understand and make decisions about the state ofyour VM instances.

Integrity monitoring relies on the measurements created by Measured Boot,which useplatform configuration registers(PCRs) to store information about the components and component load order ofboth the integrity policy baseline (a known good boot sequence),and the most recent boot sequence.

Integrity monitoring compares the most recent boot measurements to the integritypolicy baseline and returns a pair of pass or fail results depending on whetherthey match or not, one for the early boot sequence and one for the late bootsequence. Early boot is the boot sequence from the start of the UEFI firmwareuntil it passes control to the bootloader. Late boot is the boot sequence fromthe bootloader until it passes control to the operating system kernel. If eitherpart of the most recent boot sequence doesn't match the baseline, you get anintegrity validation failure.

If the failure is expected, for example if you applied a system update on thatVM instance, you shouldupdate the integrity policy baseline.Updating the integrity policy baseline sets the baseline to the measurementscaptured from the most recent boot sequence. If it is not expected, you should stopthat VM instance and investigate the reason for the failure.

You can view integrity reports in Cloud Monitoring, and set alerts onintegrity failures. You can review the details of integrity monitoring resultsin Cloud Logging. For more information, seeMonitoring integrity on Shielded VM instances.

Integrity monitoring events

Shielded VM creates log entries for the following types of events:

  • clearTPMEvent: Identifies if the vTPM has been cleared, which deletes anysecrets stored in it. This doesn't affect any aspect of Shielded VM,so you will only care about this if you use the vTPM to shield sensitive dataas described inVirtual Trusted Platform Module(vTPM).
  • earlyBootReportEvent: Identifies whether the early boot sequence integritycheck passed, and provides details on the PCR values from the baseline andthe most recent boot sequence that were compared to make that determination.
  • lateBootReportEvent: Identifies whether the late boot sequence integritycheck passed, and provides details on the PCR values from the baseline andthe most recent boot sequence that were compared to make that determination.
  • setShieldedInstanceIntegrityPolicy: Logged each time you update the integritypolicy baseline.
  • shutdownEvent: Logged each time the VM instance is stopped.
  • startupEvent: Logged each time the VM instance is started. The interestinginformation in this event is thebootCounter value, which identifies howmany times this instance has been restarted.
  • updateShieldedInstanceConfig: Logged each time you enable or disable one ofthe Shielded VM options.

The typical event progression you see in the logs isstartupEvent,earlyBootReportEvent,lateBootReportEvent, and eventuallyshutdownEvent,all with the samebootCounter value to identify them as describing the sameVM instance boot sequence.

If you update the integrity policy baseline in response to anexpected integrity failure on a VM instance, you will see additionalearlyBootReportEvent andlateBootReportEvent events that describe the newintegrity policy baseline measurements. The following example shows theexpected sequence:

  • startupEvent
  • earlyBootReportEvent that compares original baseline to latest bootsequence (passes)
  • lateBootReportEvent that compares original baseline to latest bootsequence (fails)
  • setShieldedInstanceIntegrityPolicy when youupdate the integrity policybaseline,which sets the baseline to the measurements captured from the latest bootsequence
  • earlyBootReportEvent that compares new baseline to latest boot sequence(passes)

  • lateBootReportEvent that compares new baseline to latest boot sequence(passes)

Windows

earlyBootReportEvent

earlyBootReportEvent contains the following sections and elements:

  • actualMeasurements: Contains theplatform configurationregister(PCR) values for the latest boot sequence. The PCR values are whatidentify the boot components and component load order used by the latestboot sequence, and are what are compared to the integrity policy baseline(whose values are captured in thepolicyMeasurements section) todetermine if there has been any change in the VM instance boot sequence.The elements of theactualMeasurements section can vary, based on theOS, distribution, and configuration. The section typically includes thefollowing elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about theUEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR5, which contains information about thedisk's GUID partition table. It is not used when validating the latestboot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.

  • policyEvaluationPassed: Identifies whether the given section of the bootsequence passed verification against the integrity policy baseline.

  • policyMeasurements: Contains the baseline PCR values that integrityvalidation uses as expected values. ThepolicyMeasurements section canvary based on the OS, distribution and configuration, but typicallyincludes the following elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about theUEFI boot manager code and boot attempts. This value is not includedin first boot.
    • 2: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.

To learn how to useearlyBootReportEvent PCR values to diagnose a bootintegrity validation failure, seeDetermining the cause of boot integrityvalidationfailure.

lateBootReportEvent

lateBootReportEvent contains the following sections and elements:

  • actualMeasurements: Contains theplatform configuration register(PCR) values for the latest boot sequence. The PCR values are whatidentify the boot components and component load order used by the latestboot sequence, and are what are compared to the integrity policy baseline(whose values are captured in thepolicyMeasurements section) todetermine if there has been any change in the VM instance boot sequence.The elements of theactualMeasurements section can vary, based on theOS, distribution, and configuration. The section typically includes thefollowing elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about theUEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR5, which contains information about thedisk's GUID partition table. It is not used when validating the latestboot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.
    • 4: Contains the value for PCR11, which contains information aboutBitLocker Drive Encryption access control.
    • 5: Contains the value for PCR12, which contains information about dataevents. It is not used when validating the latestboot sequence against the integrity policy baseline.
    • 6: Contains the value for PCR13, which contains information aboutWindows kernel and boot drivers.
    • 7: Contains the value for PCR14, which contains information aboutWindows boot authorities.

  • policyEvaluationPassed: Identifies whether the given section of the bootsequence passed verification against the integrity policy baseline.

  • policyMeasurements: Contains the baseline PCR values that integrityvalidation uses as expected values. ThepolicyMeasurements section canvary based on the OS, distribution and configuration, but typicallyincludes the following elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about theUEFI boot manager code and boot attempts.
    • 2: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.
    • 3: Contains the value for PCR11, which contains information aboutBitLocker Drive Encryption access control.
    • 4: Contains the value for PCR13, which contains information aboutWindows kernel and boot drivers.
    • 5: Contains the value for PCR14, which contains information aboutWindows boot authorities.
Important: Elements 4 and 5 don't appear until after the first rebootfollowing VM instance creation. During that reboot, those PCR values arecaptured and added to the integrity policy baseline. Until then, bootintegrity validation uses only elements 1-3 and their associated PCRs.

To learn how to uselateBootReportEvent PCR values to diagnose a bootintegrity validation failure, seeDetermining the cause of boot integrityvalidationfailure.

Linux

earlyBootReportEvent

earlyBootReportEvent contains the following sections and elements:

  • actualMeasurements: Contains theplatform configurationregister(PCR) values for the latest boot sequence. The PCR values are whatidentify the boot components and component load order used by the latestboot sequence, and are what are compared to the integrity policy baseline(whose values are captured in thepolicyMeasurements section) todetermine if there has been any change in the VM instance boot sequence.The elements of theactualMeasurements section can vary, based on theOS, distribution, and configuration. The section typically includes thefollowing elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about theoperating system shim.
    • 2: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.

  • policyEvaluationPassed: Identifies whetherthe given section of the boot sequence passed verification against theintegrity policy baseline.

  • policyMeasurements: Contains the baseline PCR values that integrityvalidation uses as expected values. ThepolicyMeasurements section canvary based on the OS, distribution and configuration, but typicallyincludes the following elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about theoperating system shim. This value is not included in first boot.
    • 2: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.

To learn how to useearlyBootReportEvent PCR values to diagnose a bootintegrity validation failure, seeDetermining the cause of boot integrityvalidationfailure.

lateBootReportEvent

lateBootReportEvent contains the following sections and elements:

  • actualMeasurements: Contains theplatform configurationregister(PCR) values for the latest boot sequence. The PCR values are whatidentify the boot components and component load order used by the latest bootsequence, and are what are compared to the integrity policy baseline(whose values are captured in thepolicyMeasurements section) todetermine if there has been any change in the VM instance boot sequence.The elements of theactualMeasurements section can vary, based on theOS, distribution, and configuration. The section typically includes thefollowing elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about thesecond stage boot loader and the kernel.
    • 2: Contains the value for PCR5, which contains information about thedisk's GUID partition table. It is not used when validating the latestboot sequence against the integrity policy baseline.
    • 3: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.

  • policyEvaluationPassed: Identifies whetherthe given section of the boot sequence passed verification against theintegrity policy baseline.

  • policyMeasurements: Contains the baseline PCR values that integrityvalidation uses as expected values. ThepolicyMeasurements section canvary based on the OS, distribution and configuration, but typicallyincludes the following elements:

    • 0: Contains the value for PCR0, which contains information aboutfirmware components and the memory encryption technology that isactive. This PCR diverges from theTCG PCClient platform firmwareprofile in thatit measures only the following events:
      • EV_S_CRTM_VERSION, the Compute Engine firmware version
      • EV_NONHOST_INFO, representing thememory encryptiontechnology
      • EV_SEPARATOR, the specified delimiter event firmware measureswhen it will add no more PCR0 events.This means PCR0 has a static value for the lifetime of a VM. The valueonly changes for new VMs after major version firmware updates orchange in encryption technology. It is not used when validating thelatest boot sequence against the integrity policy baseline.
    • 1: Contains the value for PCR4, which contains information about thesecond stage boot loader and the kernel.
    • 2: Contains the value for PCR7, which contains information about theinstance's Secure Boot policy.

To learn how to uselateBootReportEvent PCR values to diagnose a bootintegrity validation failure, seeDetermining the cause of boot integrityvalidationfailure.

Using BitLocker with Shielded VM images

You can enable BitLocker for Windows boot disks that are part ofShielded VM images. Shielded VM images offer security featuressuch as UEFI-compliant firmware, Secure Boot, vTPM-protected Measured Boot, andintegrity monitoring. vTPM and integrity monitoring are enabled by default, andGoogle recommendsenabling Secure Boot ifpossible.

If you choose to enable BitLocker on a Windows boot disk that is part of aShielded VM image, we strongly recommend saving the recovery key to asafe location, because if you don't have the recovery key, you can't recover thedata.

Take the following into account before enabling BitLocker on a Windows boot diskthat is part of a Shielded VM image:

  • On Shielded VM boot disks, BitLocker uses the vTPM to store theencryption keys, and the vTPM is permanently associated with the VM on which itwas created. This means that you can restore a snapshot of aShielded VM boot disk to another persistent disk, but you can't decryptit because the vTPM containing the BitLocker keys isn't available. If you havea recovery key, you can recover data by following the instructions in theBitLocker recovery guide.If you don't have a recovery key, the data on the disk is unrecoverable.

  • On Shielded VM data disks, persistent disk data is encrypted bydefault. Enabling BitLocker on top of persistent disk encryption doesn't affectthroughput, but it might increase vCPU utilization slightly. Enabling BitLockeron data disks that are attached to the VM doesn't pose the same recoverychallenges as for boot disks. This is because the BitLocker encryption keys fordata disks aren't stored on the vTPM. If you have lost the ability to unlock thedisk normally and have the recovery key, you can attach the disk to anotherunencrypted VM and recover it from there. If you don't have a recovery key, thedata on the disk is unrecoverable.

Identity and Access Management authorization

Shielded VM uses IAM for authorization.

Shielded VM operations use the following Compute Enginepermissions:

  • compute.instances.updateShieldedInstanceConfig: Allows the user to changethe Shielded VM options on a VM instance.
  • compute.instances.setShieldedInstanceIntegrityPolicy: Allows the user toupdate the integrity policy baseline on a VM instance.
  • compute.instances.getShieldedInstanceIdentity: Allows the user to retrieveendorsement key information from the vTPM.

Shielded VM permissions are granted to the following Compute Engineroles:

  • roles/compute.instanceAdmin.v1
  • roles/compute.securityAdmin

You can also grant Shielded VM permissions tocustomroles.

Organization policy constraints for Shielded VM

You can set theconstraints/compute.requireShieldedVmorganization policyconstrainttoTrue to require that Compute Engine VM instances created in yourorganization be Shielded VM instances.

Learn how to set theconstraints/compute.requireShieldedVm constraint inUsing boolean constraints in organizationpolicy.You must be anorganization policyadministratorto set a constraint.

Limitations

Shielded VM isn't supported onbare-metal instances.

What's next

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-11-24 UTC.