You block project-wide SSH keys by disabling their use at the instance or project level so only instance-specific access is accepted. This prevents any key added to the project from granting access to every VM in it. Check existing instances, inherited metadata settings, and any automation that still depends on project-wide keys before making the change.
What Google Compute Engine is doing when project-wide SSH keys are enabled
Project-wide SSH keys are a convenience feature, but they change the trust model for every VM in the project. If a key is added at the project level, it can be accepted by many instances instead of just one, so a single credential becomes a shared access path. That is why the control is really about narrowing blast radius, not just about SSH configuration.
The practical distinction is between an instance that only trusts its own metadata and a project that lets inherited metadata act like a blanket access list. The Google Cloud Security Guide places this in the wider context of GCP hierarchy, IAM, and metadata-driven controls, which is useful when you are checking whether a setting is being inherited from the project, folder, or organization layer.
For administrators, the main decision is whether SSH access should be governed centrally or locally. If you leave project-wide keys enabled, you must assume that any operational shortcut, legacy automation, or reused key can become a fleet-wide access path. If you disable them, you force access to be explicit and instance-specific, which is usually the safer default for production VMs.
How to disable inherited SSH access without breaking legitimate access
The change itself is straightforward, but the safe rollout is not. You need to know which instances still rely on inherited keys, whether OS Login or another access path is already in place, and whether startup scripts or automation still expect project metadata to inject keys.
The cleanest pattern is to verify current access first, then disable project-wide keys where the instance or project settings allow it, and then confirm that instance-specific access still works. The SSH Key and SSH Certificate Management Guide is the best follow-on reference for understanding key sprawl, orphaned keys, and the difference between ad hoc SSH keys and more governable access patterns such as certificates.
Before making the change broadly, test one representative VM from each operating pattern: manually administered hosts, autoscaled hosts, and hosts touched by deployment automation. That avoids the common failure mode where the security setting is correct, but the surrounding access workflow was never migrated.
If you are standardising on stronger access governance, this is often the moment to remove stale keys, document the approved access path, and make sure the operating team can still reach break-glass paths when normal automation fails. The setting is easy to change, but the surrounding dependency graph is what usually causes outages.
What usually breaks when project-wide keys are turned off
The most common breakage is hidden dependency, not direct SSH failure. Older scripts, golden images, and provisioning tools may assume they can push a key into project metadata and have it appear everywhere automatically. Once that shortcut disappears, those tools may still “succeed” from a deployment perspective while silently losing admin access.
There is also a trust issue with inherited metadata. When access is inherited from the project, the effective audience is larger than many operators realise, especially in projects that host multiple environments or teams. That is why the safer design is to pair the SSH setting with a stricter project structure, so access patterns match the actual operational boundary.
For teams that need a broader cloud control baseline, the CSA Cloud Controls Matrix is a useful reference point for cloud IAM and infrastructure governance, because this change sits at the intersection of access control, configuration management, and operating model discipline.
If you are already managing SSH at scale, the setting should be treated as part of an access lifecycle, not a one-time hardening task. The real success condition is that no VM still depends on a project-level key to remain reachable, and no automation path is left using an access method you no longer intend to support.
Risk and Threat Considerations
Project-wide SSH keys create a broad blast radius because one credential can unlock many VMs. If that key is leaked, reused, or planted through a compromised automation path, an attacker may gain access across systems that were supposed to be separated by workload, team, or environment.
Failure mechanism: The control fails when inherited metadata remains enabled, when legacy automation still writes keys into project metadata, or when operators assume a per-instance restriction exists even though the project setting still permits shared access.
Impact: A stolen or injected key can become fleet-wide SSH access, which increases the likelihood of lateral movement, persistence, and difficult-to-audit administrative access across the project.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Project-wide SSH keys are a cloud access-control and identity-governance issue. |
| Recommendation — Enforce instance-specific access paths and remove shared project-level SSH access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Disabling project-wide keys reduces unnecessary shared access across VMs. |
| IA-5 — Authenticator Management | SSH keys are authenticators whose scope and lifecycle must be governed. | |
| Recommendation — Restrict SSH access to the minimum instance scope required. Inventory, rotate, and retire SSH keys that are no longer needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The setting governs how access is granted and inherited across cloud assets. |
| A.8.9 — Configuration management | The control is implemented through cloud configuration and metadata settings. | |
| Recommendation — Define and enforce access rules that prohibit project-wide SSH key inheritance. Standardise and review VM metadata settings that affect SSH access. | ||
Practitioner Guidance
What to verify: Confirm which VMs still accept inherited SSH keys, and validate that the approved access path still works after the setting changes. Pay special attention to instances created by templates, autoscaling, or older tooling, because those are the systems most likely to hide inherited assumptions.
Common mistake: Treating the control as a single toggle instead of an access-model change. If you disable project-wide keys but leave old automation, shared admin accounts, or undocumented break-glass procedures in place, you have reduced one exposure while leaving the operational dependency intact.
Practitioner takeaway: The security win is not merely disabling a metadata option, it is proving that every legitimate SSH workflow still functions without a shared project-level credential path.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org