Skip to main content
compliance · gcp

Compute Engine VMs with Secure Boot, vTPM and integrity monitoring all off

resource types
1
rule IDs covered
1
severity
medium

What does ZopNight detect here?

Compute Engine VMs are flagged when none of the three Shielded VM options in `shieldedInstanceConfig` is on: Secure Boot, the virtual TPM and integrity monitoring. Those options verify the boot chain and record measurements, so a VM without any of them has no defence or evidence against rootkits and bootkits that persist across reboots.

Signal and threshold

How ZopNight evaluates Compute Engine VMs with Secure Boot, vTPM and integrity monitoring all off.
Field Value
Rule IDsRC-1203
Categorycompliance
Severitymedium
Metricnone — pure configuration read
Thresholdno Shielded VM option enabled
SourceZopNight
Permissions usedcompute.instances.list · compute.instances.get

What each Shielded VM option guards against

Shielded VM bundles three controls. Secure Boot checks the signature of every boot component and halts the boot if one fails, which stops many bootkits and rootkits. The virtual Trusted Platform Module (vTPM) holds keys and supports Measured Boot, which hashes each boot stage. Integrity monitoring compares those measurements with a known-good baseline and reports when they drift.

With all three off, a compromised kernel or bootloader leaves no trace in the platform’s own records. Compliance frameworks that ask for verified boot integrity have nothing to point at.

Reading the three flags for your fleet

Each option is a separate boolean on the instance:

Terminal window
gcloud compute instances list --format="table(
name, zone,
shieldedInstanceConfig.enableSecureBoot,
shieldedInstanceConfig.enableVtpm,
shieldedInstanceConfig.enableIntegrityMonitoring)"

A row where all three are false or empty is what this rule targets.

The condition that triggers it

ZopNight records whether each Compute Engine instance has Shielded VM protection during inventory, and treats an instance as protected when any one of the three options is on. The rule fires when none is. An instance that was not fully inventoried is skipped.

What the rule does not judge

Because one option is enough to count as protected, a VM with only vTPM and integrity monitoring on is not flagged even though Secure Boot is off. That gap is common in practice, because Google notes that Compute Engine does not enable Secure Boot by default, because unsigned drivers and other low-level software might not be compatible. Use the table above if your policy requires all three.

Hardening with no price tag

This is a compliance rule with a $0 saving. The practical cost of fixing it is a short stop and start of the VM.

Enabling the options on an existing VM

Google’s procedure requires a stop, the change, then a start:

  1. gcloud compute instances stop VM_NAME --zone=ZONE
  2. gcloud compute instances update VM_NAME --zone=ZONE --shielded-vtpm --shielded-integrity-monitoring --shielded-secure-boot
  3. gcloud compute instances start VM_NAME --zone=ZONE
  4. Watch the first boot. If it fails, stop the VM, rerun step 2 with --no-shielded-secure-boot and start again.

See it fire on your bill.

Connect an account read-only. The first findings land in minutes.

472 rule families across 353 resource types on 22 platforms. Every threshold, metric, and IAM action is documented on these pages before you grant anything.

472 rule families documented
353 resource types covered
read-only default access level
Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console· Multi-cloud automation· Production-ready in 30 min· SOC 2 · ISO 27001· 20–60% off the bill, first month· 4 platforms · 1 console·