VM Integrity Monitoring Not Enabled on GCP Compute Engine

Shielded VM is one of those Google Cloud features that quietly does a lot of heavy lifting and gets ignored until an auditor or a security scan points at it. Integrity monitoring is the part of Shielded VM that watches the early boot sequence of your instance and tells you when something changes that should not have. When it is off, a compromise at the firmware or bootloader level can sit underneath your operating system, invisible to your usual logging and endpoint tooling.

This post walks through what the VM Integrity Monitoring Not Enabled check looks at, why it is worth fixing, and how to remediate it without breaking your fleet.

---

What this check detects

The compute_nointegritymonitoring check looks at each Compute Engine instance and inspects its shieldedInstanceConfig. Specifically, it flags any VM where enableIntegrityMonitoring is set to false (or absent on a Shielded-capable image).

Integrity monitoring is a feature of Shielded VM, which bundles three related protections:

• Secure Boot — verifies that only signed firmware and boot components load.
• Virtual Trusted Platform Module (vTPM) — provides a hardware-rooted store for keys and a way to measure the boot process.
• Integrity monitoring — compares the boot measurements recorded by the vTPM against a known-good baseline and reports any drift.

This check is concerned with the third one. Integrity monitoring depends on the vTPM, so if the vTPM is disabled, integrity monitoring cannot function either.

---

Why it matters

The operating system is not the lowest layer of a machine. Below it sits the bootloader, the kernel, and the firmware. An attacker who gains enough access to modify any of these can install a persistent foothold that survives reboots and OS reinstalls, and that hides from agents running inside the OS. This class of attack is often called a bootkit or a kernel-level rootkit.

Integrity monitoring exists to catch exactly this. On each boot, the vTPM records measurements of the boot path. Integrity monitoring compares those measurements against the baseline captured the first time the VM booted in a known-good state. If a measurement no longer matches, Google Cloud raises an integrity validation failure that you can see in Cloud Monitoring and Cloud Logging.

Without integrity monitoring, you lose that signal entirely. Consider a realistic chain of events:

1. An attacker compromises a VM through an application vulnerability and escalates to root.
2. They modify the initramfs or install a malicious kernel module that re-establishes their access on every boot.
3. Your incident response team reimages the OS partition, believing the threat is gone.
4. The boot-level component persists, and the attacker walks right back in.

With integrity monitoring on, step 2 produces a measurable change in the boot path. That failure can be wired to an alert, giving you a chance to catch the persistence mechanism before it does damage.

There is also a compliance angle. CIS Google Cloud Foundations Benchmark recommends enabling Shielded VM, and frameworks like SOC 2, ISO 27001, and PCI DSS all expect host integrity controls. A fleet of VMs with integrity monitoring disabled is an easy finding for an auditor and an avoidable one.

---

How to fix it

Enabling integrity monitoring on an existing VM requires the instance to be stopped, because Shielded VM settings are part of the instance configuration that cannot change while it is running. Plan for a brief restart.

Using the gcloud CLI

First stop the instance:

gcloud compute instances stop INSTANCE_NAME \
  --zone=ZONE \
  --project=PROJECT_ID

Then enable integrity monitoring (and the vTPM it depends on):

gcloud compute instances update INSTANCE_NAME \
  --zone=ZONE \
  --project=PROJECT_ID \
  --shielded-vm-integrity-monitoring \
  --shielded-vm-vtpm

Start it back up:

gcloud compute instances start INSTANCE_NAME \
  --zone=ZONE \
  --project=PROJECT_ID

Confirm the change:

gcloud compute instances describe INSTANCE_NAME \
  --zone=ZONE \
  --project=PROJECT_ID \
  --format="yaml(shieldedInstanceConfig)"

You should see:

shieldedInstanceConfig:
  enableIntegrityMonitoring: true
  enableSecureBoot: false
  enableVtpm: true

Using the Google Cloud Console

1. Go to Compute Engine > VM instances and click the instance name.
2. Click Stop and wait for it to fully terminate.
3. Click Edit.
4. Scroll to the Shielded VM section.
5. Toggle Turn on vTPM and Turn on Integrity Monitoring.
6. Click Save, then Start the instance.

Using Terraform

For new and managed instances, declare the shielded_instance_config block so the setting is enforced in code:

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

  boot_disk {
    initialize_params {
      # Use a Shielded VM compatible image
      image = "debian-cloud/debian-12"
    }
  }

  shielded_instance_config {
    enable_integrity_monitoring = true
    enable_vtpm                 = true
    enable_secure_boot          = true
  }

  network_interface {
    network = "default"
  }
}

Fixing a fleet at once

To find and report on every instance missing integrity monitoring across a project, query the API directly:

gcloud compute instances list \
  --project=PROJECT_ID \
  --format="table(name, zone, shieldedInstanceConfig.enableIntegrityMonitoring)" \
  --filter="shieldedInstanceConfig.enableIntegrityMonitoring=false"

Loop over the results to remediate them, but treat the stop/start as a controlled change rather than a bulk script run against production all at once.

---

How to prevent it from happening again

Remediating once is fine. Stopping the next non-compliant VM from ever launching is better. A few layers work well together.

1. Organization Policy constraint

Google Cloud has a built-in constraint that requires Shielded VM on all newly created instances:

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

You can also scope this to a folder or project. With this enforced, any instance created without Shielded VM enabled is rejected at the API level, which includes integrity monitoring and vTPM.

2. Policy-as-code in CI/CD

Catch the misconfiguration before it merges. With Terraform, an OPA or Conftest policy can fail the pipeline when a compute instance omits integrity monitoring:

package terraform.shielded_vm

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_compute_instance"
  config := resource.change.after.shielded_instance_config[_]
  config.enable_integrity_monitoring == false
  msg := sprintf("Instance '%s' must enable integrity monitoring", [resource.address])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_compute_instance"
  not resource.change.after.shielded_instance_config
  msg := sprintf("Instance '%s' is missing shielded_instance_config", [resource.address])
}

Run it against a plan in your pipeline:

terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json
conftest test --policy policy/ tfplan.json

3. Continuous monitoring

Org policies and CI gates cover the resources created through your standard paths. Console clicks, one-off scripts, and exceptions slip through. A scheduled scan that flags drift is the backstop. This is where Lensix runs the compute_nointegritymonitoring check on a schedule and surfaces any VM that regresses, so a setting that gets toggled off during troubleshooting and never restored does not stay hidden.

---

Best practices

• Enable the full Shielded VM stack where you can. Integrity monitoring without Secure Boot still detects tampering, but Secure Boot prevents unsigned components from loading in the first place. Test Secure Boot in staging first, since custom kernel modules need to be signed.
• Bake it into your golden images and templates. The most reliable fix is making the secure configuration the default. Set shielded_instance_config in every instance template so individual engineers never have to think about it.
• Wire integrity failures to alerts. A detective control only helps if someone sees the detection. Create a Cloud Monitoring alert on the compute.googleapis.com/instance/integrity/early_boot_validation_status metric so a failed validation pages the right team.
• Update the integrity baseline deliberately. Legitimate changes, like a kernel upgrade, will change boot measurements and trigger a failure. When you know a change is expected, update the integrity policy baseline so future boots compare against the new known-good state rather than alerting forever.
• Verify image compatibility before enforcing org policy. Imported or legacy images without UEFI support cannot run as Shielded VMs. Sort that out before flipping on requireShieldedVm across the org.

Integrity monitoring is cheap to enable and gives you a signal that nothing else in your stack provides: visibility into the layer beneath the operating system. Turn it on, default it in your templates, and let a continuous scan make sure it stays on.