Compute Engine instances should have 'Block Project-wide SSH keys' enabled
It is recommended to use Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances. Compute Engine VMs are evaluated for the metadata key `block-project-ssh-keys` set to `true`.
Use of project-wide SSH keys means that a compromise of any one of these key pairs can result in all instances being compromised. Allowing project-wide SSH keys lets a single compromised key reach many VMs, amplifying blast radius. Per-instance revocation and accountability are weakened.
What this control checks
Checks whether Compute Engine instances have Block Project-wide SSH keys enabled
Common pitfalls
KICS flags instances without block-project-ssh-keys
KICS flags a google_compute_instance with no block-project-ssh-keys in metadata.
Template-based instances cannot pass without the key
If source_instance_template is present (indicating a google_compute_instance_from_template) and block-project-ssh-keys is not present, this check cannot PASS, since we don't know what the underlying source template looks like.
Audit evidence
Evidence that deployed resources meet this control: Prowler check compute_instance_block_project_wide_ssh_keys_disabled (prowler gcp --checks compute_instance_block_project_wide_ssh_keys_disabled); PowerPipe control gcp_compliance.control.compute_instance_block_project_wide_ssh_enabled.
Scans of the Terraform code that flag the same setting before deployment: Checkov check CKV_GCP_32; KICS query "Project-wide SSH Keys Are Enabled In VM Instances" (3e4d5ce6-3280-4027-8010-c26eeea1ec01); Trivy check GCP-0030.
Framework-specific interpretation
SOC 2: Mapped to CC6.6 (The entity implements logical access security measures to protect against threats from sources outside its system...).
PCI DSS v4.0: Mapped to 8.2.5 (User identification and related accounts for users and administrators are strictly managed throughout an accounts...).
NIS2 Directive (EU 2022/2555): Mapped to 11.1.1 (For the purpose of Article 21(2), point (i) of Directive (EU) 2022/2555, the relevant entities shall establish...), 6.7.2.b (determine and apply controls to protect the relevant entities internal network domains from unauthorised access;), 9.2.c (the relevant entities approach to key management, including, where appropriate, methods for the following:) and 3 more clauses.
NIST SP 800-53 Rev 5: Mapped to AC-17 (Remote Access), IA-5 (Authenticator Management) and SC-8 (Transmission Confidentiality And Integrity).
NIST Cybersecurity Framework v2.0: Mapped to ID.AM-01 (Inventories of hardware managed by the organization are maintained.).
Framework mappings
The clauses this control is mapped to in each framework.
- CC6.6: The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
- 8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- 6 Security in network and information systems acquisition, development and maintenance
- 9 Cryptography
- 11 Access control
- AC-17 Remote Access
- IA-5: Authenticator Management
- Transmission Confidentiality And Integrity (SC-8)
NIST Cybersecurity Framework v2.0
- ID.AM-01: Inventories of hardware managed by the organization are maintained.
- 4.3 Ensure 'Block Project-Wide SSH Keys' Is Enabled for VM Instances
- 4.3 Ensure 'Block Project-Wide SSH Keys' Is Enabled for VM Instances
- IAM-08.05B The cloud service provider documents, communicates and makes available to all users under its responsibility rules and recommendations for the management of credentials, including at least: - Non-reuse of credentials;- Trade-offs between entropy and ability to memorise;-...
- OIS-08.02B The following aspects are taken into account when identifying risks, insofar as they are applicable to the cloud service provided and are within the area of responsibility of the cloud service provider: - Processing, storage or transmission of cloud service customer data and cloud...
- PSS-05.01B The cloud service provider provides authentication mechanisms that can force strong authentication (e.g. two or more factors) for users, IT components or applications within the cloud users' area of responsibility. These authentication mechanisms are set up at all access points that...
- 4.3 Ensure 'Block Project-wide SSH keys' is enabled for VM instances
- 4.3 Ensure 'Block Project-wide SSH keys' is enabled for VM instances
- 4.3 Ensure 'Block Project-wide SSH keys' is enabled for VM instances
NIST Cybersecurity Framework v1.0
- PR.DS-2: DData-in-transit is protected.
Related controls
- Compute Engine instances should have Shielded VM enabled at launch
- Compute Engine instances should have permissions to disrupt logging restricted
- Projects should prohibit default networks
- IAM users should not hold both service account admin and service account user roles
- Compute Engine external backend services should have IAP enabled
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
- Compliance.tf Control:
compute_instance_block_project_wide_ssh_enabled - Checkov Check:
CKV_GCP_32 - Powerpipe Control:
gcp_compliance.control.compute_instance_block_project_wide_ssh_enabled - Prowler Check:
compute_instance_block_project_wide_ssh_keys_disabled - KICS Query:
3e4d5ce6-3280-4027-8010-c26eeea1ec01 - Trivy Check:
GCP-0030
Last reviewed: 2026-10-09