VM vTPM Not Enabled: Securing GCP Compute Engine Boot Integrity

Shielded VM is one of those GCP features that quietly does a lot of work to protect your instances from boot-level tampering, and most teams never notice it until an auditor or a security tool points out that it is missing. The VM vTPM Not Enabled check looks for Compute Engine VMs that are running without a virtual Trusted Platform Module, which is a core component of the Shielded VM stack.

This post walks through what the vTPM actually does, why a missing one is worth fixing, and how to remediate it without breaking your fleet.

---

What this check detects

The compute_novtpm check inspects each Compute Engine instance and reports any VM where the Shielded VM virtual TPM is disabled. In the instance configuration, this maps to the shieldedInstanceConfig.enableVtpm field being set to false (or absent on older instances created before Shielded VM defaults changed).

A vTPM is a virtualized, hardware-rooted Trusted Platform Module backed by Google's infrastructure. It provides two things that matter for security:

• Measured boot: the vTPM records cryptographic measurements of the boot sequence (UEFI firmware, bootloader, kernel) so that any tampering produces a different measurement.
• Key and secret isolation: applications can generate and store keys inside the vTPM so they never live in plain memory, and operations like sealing data to a known-good boot state become possible.

---

Why it matters

The threat Shielded VM defends against is not a noisy network attacker. It is a quieter, more dangerous category: malware that survives reboots and reinstalls by burrowing into the boot path. Rootkits and bootkits load before the operating system, which means they can hide from the OS and from most agent-based security tooling running inside the VM.

Here is the practical chain of consequences when vTPM is off:

• No boot integrity baseline. Without measured boot, there is no cryptographic record of what loaded during startup. If an attacker swaps a malicious kernel module or tampers with the bootloader, nothing flags the change.
• Integrity Monitoring is effectively useless. Even if you enabled Integrity Monitoring, it has no vTPM measurements to compare against, so the early-boot and late-boot integrity validation cannot run.
• Weaker key custody. Workloads that could anchor keys in a vTPM instead keep them in process memory, where a memory-scraping exploit or a compromised process can read them.
• Compliance gaps. The CIS Google Cloud Foundations Benchmark recommends Shielded VM features on production instances. A missing vTPM shows up directly in benchmark scans and audit reports.

---

How to fix it

The vTPM setting can only be changed while the instance is stopped. The fix is straightforward, but it requires a brief reboot, so plan accordingly.

1. Confirm the current state

gcloud compute instances describe INSTANCE_NAME \
  --zone ZONE \
  --format="value(shieldedInstanceConfig.enableVtpm)"

If this returns False or is empty, the vTPM is not enabled.

2. Stop the instance

gcloud compute instances stop INSTANCE_NAME --zone ZONE

3. Enable the vTPM

gcloud compute instances update INSTANCE_NAME \
  --zone ZONE \
  --shielded-vtpm

While you are here, it is worth turning on the related protections too, since they work as a set:

gcloud compute instances update INSTANCE_NAME \
  --zone ZONE \
  --shielded-vtpm \
  --shielded-integrity-monitoring \
  --shielded-secure-boot

4. Start the instance and verify

gcloud compute instances start INSTANCE_NAME --zone ZONE

gcloud compute instances describe INSTANCE_NAME \
  --zone ZONE \
  --format="value(shieldedInstanceConfig.enableVtpm)"

A return value of True confirms the fix.

---

Fixing it with infrastructure as code

If your instances are managed with Terraform, bake the setting into the definition so it never drifts:

resource "google_compute_instance" "app" {
  name         = "app-server"
  machine_type = "e2-standard-2"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "projects/debian-cloud/global/images/family/debian-12"
    }
  }

  shielded_instance_config {
    enable_vtpm                 = true
    enable_integrity_monitoring = true
    enable_secure_boot          = false # enable after validating boot compatibility
  }

  network_interface {
    network = "default"
  }
}

For instance templates feeding a managed instance group, the same shielded_instance_config block applies. Update the template, then perform a rolling replace so the change propagates.

---

How to prevent it from happening again

Remediating one VM is easy. Keeping vTPM enabled across a growing fleet is the real work. Use a layered approach.

Enforce at the organization level with Org Policy

GCP provides a built-in constraint that requires Shielded VM on all new instances:

gcloud resource-manager org-policies enable-enforce \
  compute.requireShieldedVm \
  --organization ORGANIZATION_ID

With this constraint active, any attempt to create a VM without Shielded VM (which includes the vTPM) is rejected at the API level. This is the strongest guardrail because it cannot be bypassed by a misconfigured Terraform file or a console click.

Gate it in CI/CD with policy as code

Catch misconfigurations before they reach GCP by scanning Terraform plans. A Conftest/OPA Rego rule does the job:

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_compute_instance"
  not resource.change.after.shielded_instance_config[_].enable_vtpm
  msg := sprintf("Instance %v must have vTPM enabled", [resource.address])
}

Wire this into your pipeline so a pull request that adds an unshielded instance fails before merge.

Detect drift continuously

Org policy and CI cover new resources, but settings can still drift through manual changes or imported infrastructure. Continuous scanning with Lensix surfaces any VM where the vTPM has been turned off, so the gap between "we enabled it once" and "it is still enabled" never grows unnoticed.

---

Best practices

• Treat the three Shielded VM features as a unit. vTPM alone gives you measured boot, but Integrity Monitoring is what turns those measurements into alerts. Enable both, and add Secure Boot once you have confirmed boot compatibility.
• Standardize on UEFI-compatible images. Build custom images with UEFI_COMPATIBLE from the start so Shielded VM is always an option, never a blocker.
• Apply protections at the template, not the instance. Configuring Shielded VM per instance invites drift. Set it once in your shared module or instance template.
• Combine prevention and detection. Org Policy stops new violations, CI gates catch them in code review, and continuous scanning catches drift. No single layer is enough on its own.
• Document the Secure Boot exceptions. Some legitimate workloads cannot use Secure Boot. When you grant an exception, record why, so the next reviewer does not assume it is a mistake.

The vTPM is cheap to enable and costs nothing extra to run, yet it closes one of the few attack surfaces that survive a reboot. For most fleets, the right end state is simple: Shielded VM on everywhere, enforced by policy, and verified continuously.