Your Ultimate Guide for Multi-Cloud SSH Key Management

AWS hands you a downloadable .pem file. Azure drops a public key into a single VM’s authorized_keys. GCP, if you turn on OS Login, ties SSH access to an IAM identity instead of a key file at all. Three clouds, three different models for the same credential, and most security teams discover this the hard way: during an audit, an offboarding, or an incident, when nobody can produce one list of who can SSH into what across the whole environment.

Published: March 2026. Updated: August 2026. Reviewed by Encryption Consulting’s Key Management team.

Why Is Multi-Cloud SSH Key Management Harder Than Single-Cloud?

Multi-cloud SSH key management is harder than single-cloud because there is no shared SSH key control plane across AWS, Azure, and GCP. Each provider injects, stores, and governs keys through its own mechanism, and none of those mechanisms talks to the others. A key generated for an AWS EC2 instance has no relationship to a key deployed on an Azure VM or a GCP Compute Engine instance, even if the same engineer manages all three and reuses the same key pair out of convenience.

That gap shows up in three concrete ways once an organization actually runs workloads on more than one cloud:

• Fragmented inventories. AWS tracks key pairs per region and account, Azure tracks public keys per VM’s authorized_keys file (or per Azure Key Vault resource, if a team goes to the trouble of wiring that up), and GCP tracks keys in project or instance metadata, or in IAM if OS Login is enabled. No single console shows all of it.
• Inconsistent baselines. A key-type and rotation policy enforced in AWS through internal process has to be separately, manually enforced in Azure and GCP, because none of the three clouds will apply another cloud’s policy for you.
• Reused keys, no shared identity. Engineers commonly copy the same public key across all three clouds for convenience. That key now has three separate blast radii, three separate revocation points, and no single record tying it back to one owner.

For a full treatment of what SSH key lifecycle management means in any single environment, ownership, rotation triggers, access policy, and audit evidence, see Encryption Consulting’s Comprehensive SSH Key Lifecycle Management for Enterprise Security guide. This guide builds on that foundation and focuses specifically on what changes when the same discipline has to hold across AWS, Azure, and GCP at once.

The Data Behind the Sprawl

SSH key sprawl is not a theoretical risk. Recent analyst reports, vendor research and industry surveys put numbers behind exactly how far unmanaged credentials, including SSH keys, have outpaced governance:

• Secrets sprawl is accelerating faster than teams can track it. GitGuardian’s State of Secrets Sprawl 2026 report, published March 17, 2026, found 29 million new hardcoded secrets exposed on public GitHub in 2025 alone, a 34% year-over-year increase and the largest single-year jump the firm has recorded. The same report notes that recent supply-chain incidents, including the LiteLLM compromise, specifically harvested SSH keys alongside cloud credentials.
• Machine identities, including SSH keys, now dwarf human accounts. CyberArk’s 2025 State of Machine Identity Security Report, based on a survey of 1,200 security leaders, found that organizations anticipate machine identities to keep climbing and that manual processes can no longer track them at scale, putting the ratio of machine identities to human identities at roughly 82 to 1.
• Credential-based breaches are the slowest and among the costliest to catch. IBM’s 2025 Cost of a Data Breach Report found that breaches beginning with stolen or compromised credentials averaged $4.67 million and took 246 days to identify and contain, one of the longest breach lifecycles the report tracks.

Multi-cloud estates compound every one of these numbers, because the same key can exist, unaccounted for, in three separate inventories instead of one.

How Do AWS, Azure, and GCP Each Handle SSH Keys Natively?

AWS, Azure, and GCP each treat SSH key access as an instance-level or project-level detail rather than a governed, centrally managed credential. GCP is the partial exception: its OS Login feature can bind SSH access to IAM identity instead of a stored key, something AWS and Azure only offer as separate, opt-in services layered on top of their default key model.

AWS: EC2 key pairs

AWS’s default model is the EC2 key pair. When you launch an instance through the console, CLI, or CloudFormation, AWS stores the public key with the instance and gives you exactly one chance to download the private key, per AWS’s own EC2 User Guide. Key pairs are scoped per region, with a documented limit of 5,000 key pairs per region per account, and there is no built-in mechanism for sharing a key pair across regions or accounts. AWS supports both RSA and ED25519 key types and lets you import an externally generated public key instead of using AWS-generated material, but the documentation does not describe any automated rotation capability. Rotating an EC2 key pair means generating a new key, updating authorized_keys on every affected instance, and retiring the old key pair, manually or through your own automation.

AWS also offers AWS Systems Manager Session Manager as an IAM-based alternative that removes the need for a stored private key or an open inbound SSH port. It is not the default: it requires the SSM Agent running on the instance and an IAM role granting the instance permission to communicate with Systems Manager. Session Manager gives you IAM-controlled access and session logging, but it coexists with EC2 key pairs rather than replacing them across an estate that already has key-based access baked into scripts, images, and CI/CD pipelines.

Azure: per-VM SSH keys

Azure’s default model looks similar to AWS’s but is scoped even more narrowly, to the individual VM. Per Microsoft’s Azure Virtual Machines documentation, you generate a key pair (commonly RSA or ED25519, using ssh-keygen or the az vm create --generate-ssh-keys flag), and the public key is written into that VM’s ~/.ssh/authorized_keys file at creation. The private key stays on the local machine that generated it, and the same key pair can be reused across many VMs, which keeps setup simple but means one leaked private key can reach every VM it was ever copied to. Microsoft’s own documentation does not describe a subscription-level key inventory, an Azure Key Vault integration built into the standard VM creation flow, or any automated rotation enforcement; a team can wire Key Vault into a deployment script to generate and store a key pair, but that is a pattern you build, not a default Azure provides.

Azure’s IAM-based alternative is Microsoft Entra ID login for Linux VMs, which authenticates SSH sessions against Entra ID credentials and Azure RBAC role assignments instead of a static key. Like AWS Session Manager, it is opt-in: it requires installing the AADSSHLoginForLinux VM extension, enabling a system-assigned managed identity, and assigning roles such as Virtual Machine Administrator Login. Standard SSH public key authentication remains Azure’s default, and most estates run a mix of Entra-enabled and key-only VMs rather than one consistent model.

GCP: metadata keys, or OS Login bound to IAM

GCP starts from the same place as AWS and Azure: by default, Compute Engine reads SSH public keys from project or instance metadata and writes them into authorized_keys on the target VM, per Google’s own guidance on adding SSH keys to VMs. What sets GCP apart is OS Login, a feature that replaces metadata-based keys with IAM-governed access. With OS Login enabled, an administrator grants a user the roles/compute.osLogin or roles/compute.osAdminLogin IAM role instead of distributing a key file, and Google’s documentation describes continuous, per-session evaluation: when an administrator removes a user’s IAM permission, that user’s SSH access is revoked immediately, without anyone touching a VM or an authorized_keys file. OS Login also supports two-factor authentication through Google Authenticator, SMS, or security keys, and logs connection attempts for audit purposes, according to Google’s SSH login access best practices.

OS Login is not GCP’s default either; it has to be turned on with an enable-oslogin=TRUE metadata flag at the project or instance level, per Google’s OS Login setup documentation. The real differentiator is what happens once it is on: OS Login governs SSH access through the same ssh command and the standard OpenSSH client, using IAM as the source of truth, without requiring a separate agent or extension the way AWS Session Manager and Azure Entra ID login both do. That makes IAM-based SSH access a lighter lift to adopt consistently across a GCP estate than it is on the other two clouds, even though it still requires the same deliberate rollout AWS and Azure need.

Decision Table: Cloud Provider vs. Native SSH Key Handling vs. Centralization Gap

Cloud provider	Native SSH key handling	Centralization gap
AWS	Per-region EC2 key pairs; public key stored with the instance, private key downloadable once; RSA or ED25519; up to 5,000 pairs per region; optional IAM-based Systems Manager Session Manager as an add-on	No built-in rotation; no cross-region or cross-account key inventory; Session Manager requires separate SSM Agent and IAM role setup and does not remove existing key pairs
Azure	Per-VM authorized_keys entries, generated via CLI, portal, or ARM template; reusable across VMs; optional Microsoft Entra ID login for Linux as an add-on	No subscription-level key inventory documented; no automated rotation; Entra ID login requires the AADSSHLoginForLinux extension and RBAC role assignment on top of the default key model
GCP	Project or instance metadata keys by default; OS Login available to bind access to IAM identity instead, with continuous permission evaluation and optional 2FA	OS Login must be explicitly enabled; a GCP estate that never turns it on is exactly as decentralized as AWS or Azure; OS Login itself does not extend to AWS or Azure resources

Every row in that table describes a single cloud in isolation. None of the three mechanisms, EC2 key pairs, Azure authorized_keys files, or GCP OS Login, produces a record that spans the other two. That is the centralization gap a multi-cloud program has to close deliberately, because no provider closes it for you.

Who Owns SSH Key Lifecycle Across Cloud Boundaries?

In a single cloud, ownership is at least theoretically traceable back to whoever created the key pair, VM, or IAM binding in that one account. Across three clouds, that trail breaks unless ownership is assigned centrally and independently of which platform a given key happens to live on.

Lifecycle stage	Single-cloud reality	What breaks across three clouds
Generation	Engineer creates or imports a key pair in one console	The same key pair is frequently reused across AWS, Azure, and GCP for convenience, so one generation event now has three separate blast radii with no shared record
Approval	Team lead or security reviews the request in that cloud’s workflow	Approval workflows differ per cloud (IAM policy attach in AWS, RBAC role assignment in Azure, OS Login IAM role in GCP), so a single approval standard has to be layered on top of all three
Provisioning	Public key written to that cloud’s metadata, authorized_keys file, or IAM binding	There is no shared provisioning API; a centralized tool or documented runbook has to push the same policy through three different provisioning mechanisms
Usage	That cloud’s native logging (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) records the session	Three separate log formats and retention policies mean usage evidence has to be normalized before it is useful for a cross-cloud access review
Rotation and decommissioning	Key removed from that one cloud’s instance or metadata	Offboarding an engineer who had access in all three clouds means three separate removal actions, each of which can be missed independently, unless one system triggers all three

The practical fix is to name one accountable owner, a role, not just a person, for every key at the moment it is created, and record which cloud or clouds that key touches as part of the same record. That single change is what lets an offboarding checklist, or an audit, treat “this person’s SSH access” as one item instead of three.

What Should Trigger Rotation, and Why Is Cloud-Native Rotation Often Manual or Incomplete?

SSH key rotation should trigger on the same three conditions in every cloud: elapsed cryptoperiod, a personnel or role change, and suspected compromise, per the general framework in NIST IR 7966. What changes in a multi-cloud estate is that none of the three providers automates all three triggers, and none of them will rotate a key on your behalf without you building that automation yourself.

• AWS has no scheduled rotation for EC2 key pairs. Rotating means generating a new key pair, pushing the new public key to every affected instance’s authorized_keys file (manually, or via Systems Manager or your own configuration management), and deleting the old key pair from the account. Nothing in the platform reminds you this is overdue.
• Azure is the same story at the VM level: nothing forces a refresh of the key sitting in authorized_keys, and because the same key pair is commonly reused across many VMs, a rotation event in Azure often means updating dozens of VMs one by one unless configuration management handles it.
• GCP metadata keys behave like the other two: no automatic expiration or refresh. OS Login changes the shape of the problem rather than solving rotation outright, because access is tied to an IAM binding instead of a static key; revoking the IAM role is effectively instantaneous, which functions like rotation for human interactive access, but service account keys and any metadata-based keys still in use follow the same manual pattern as AWS and Azure.

The practical implication: a rotation policy written for “SSH keys” in general will silently fail in a multi-cloud estate unless it specifies, per cloud, exactly what action fulfills that policy, because “rotate the key” means a different sequence of steps on each platform.

How Do You Keep Access Policy Consistent Across Three Different IAM Models?

AWS IAM, Azure RBAC, and Google Cloud IAM all express access control differently enough that a policy statement written for one does not translate directly to the others. Keeping access policy consistent means defining the policy once, in cloud-agnostic terms, and then mapping it separately into each provider’s model, rather than trying to write one native policy and hope it generalizes.

• Least privilege, expressed per platform. “Production database administrators get SSH access to production database hosts” has to become a scoped IAM policy in AWS, a scoped RBAC role assignment in Azure, and a scoped OS Login IAM role in GCP, three separate configurations enforcing the same intent.
• Source and command restrictions. None of the three clouds enforces source-IP or command restrictions on SSH sessions natively at the platform level in the same way; those controls, when used, are typically configured in the key’s authorized_keys entry itself (AWS, Azure) or through OS Login’s supported options (GCP), so they have to be applied consistently by whatever process provisions the key, not assumed from the cloud.
• Separation of duties. The person who approves an access request should not be the same person who provisions it, a rule that is easy to enforce inside one cloud’s workflow and easy to lose track of when three separate workflows exist side by side.
• Service account and automation keys. CI/CD pipelines and configuration management tools frequently hold long-lived SSH keys with broad reach across cloud boundaries; those keys need the same policy discipline as human keys, arguably more, since they are used continuously and are harder to notice if compromised.

A cloud-agnostic SSH key management layer, sitting above AWS IAM, Azure RBAC, and GCP IAM rather than trying to be a fourth incompatible model, is what makes “one policy, three enforcements” achievable instead of aspirational.

How Do You Produce Audit Evidence Across Multiple Cloud Consoles?

Producing audit evidence across AWS, Azure, and GCP means pulling proof of request, approval, provisioning, usage, and termination from three separate logging systems, normalizing it, and presenting it as one record per credential rather than three disconnected fragments. Frameworks like SOC 2, ISO/IEC 27001, and PCI DSS all expect an organization to show that access is reviewed and revoked in a timely manner, and an auditor asking “who could SSH into this system, and prove it” does not care that the answer spans three different cloud consoles.

• AWS evidence comes from CloudTrail (API-level key pair actions) and, where used, Session Manager session logs; neither natively records which human held the private key for a given EC2 key pair, only that the key pair existed and what API calls touched it.
• Azure evidence comes from Azure Activity Log and VM-level authentication records; because a key pair can be reused across many VMs, tying a specific login event back to a specific person requires cross-referencing which private key that person actually holds, information Azure itself does not track.
• GCP evidence is strongest when OS Login is enabled, because Cloud Audit Logs then tie every session directly to an IAM identity rather than an anonymous key; without OS Login, GCP’s metadata-key logging has the same ownership gap as AWS and Azure.

The fix is the same one that solves lifecycle ownership: assign an owner at issuance, record which cloud or clouds a key touches, and feed usage logs from all three consoles into one system, a SIEM platform such as Splunk, or a dedicated SSH key management tool, so audit evidence is continuously assembled rather than reconstructed under deadline pressure every time an auditor asks.

A Practical Workflow for Centralizing Multi-Cloud SSH Key Management

Centralizing SSH key management across AWS, Azure, and GCP does not require ripping out existing access or disrupting running workloads. It means layering discovery, policy, and automation on top of what each cloud already does, in a defined sequence:

1. Inventory every key, in every account, project, and subscription. Scan AWS regions and accounts for EC2 key pairs, Azure subscriptions for VM authorized_keys entries, and GCP projects for metadata keys and OS Login bindings. Manual discovery at this scale is, in NIST IR 7966’s own words about SSH key inventories generally, “practically impossible,” so this step should be automated from the start.
2. Map every key to an owner and a cloud. Record who is accountable for each key and which cloud, or clouds, that key grants access to. A key copied across all three platforms should be flagged as a single higher-risk credential, not tracked as three unrelated entries.
3. Decide, per cloud, between native keys and the IAM-based alternative. Evaluate AWS Systems Manager Session Manager, Microsoft Entra ID login for Linux VMs, and GCP OS Login against your estate’s operational constraints. None is mandatory, but each removes a static private key from day-to-day human access where it is adopted.
4. Normalize policy across all three clouds. Set one key-type and length standard, one rotation cadence per risk tier, and one access-approval workflow, then enforce that single policy through provisioning in each cloud rather than writing three separate, drifting policies.
5. Automate rotation and deprovisioning centrally. An offboarding event should trigger key removal in AWS, Azure, and GCP as one action, not three separate tickets that depend on three separate people remembering to close them.
6. Feed usage logs from all three clouds into one view. Route CloudTrail, Azure Activity Log, and GCP Cloud Audit Log SSH-relevant events into a shared SIEM or dedicated SSH key management platform, so an access review or an audit pulls from one source instead of three.
7. Test cross-cloud incident response before you need it. Run a tabletop exercise for “this key is compromised, and it was reused in two of our three clouds” before that scenario happens for real.

How Should You Respond When an SSH Key Is Compromised Across Multiple Clouds?

A compromised SSH key that turns up in one cloud has to be treated as a multi-cloud incident until proven otherwise, because key reuse across AWS, Azure, and GCP is common enough that the same private key is frequently valid in more than one place.

1. Contain in the cloud where it was found first. Remove the AWS EC2 key pair, strip the entry from the affected Azure VM’s authorized_keys file, or revoke the GCP IAM role backing OS Login access, immediately, without waiting for a full investigation.
2. Check for reuse in the other two clouds. Search your inventory (built in the workflow above) for the same public key fingerprint anywhere in AWS, Azure, or GCP. A key generated once and copy-pasted into three environments is one of the most common multi-cloud sprawl patterns and the fastest way an incident in one cloud becomes an incident in all three.
3. Pull authentication logs from all three consoles. Reconstruct the access timeline using AWS CloudTrail, Azure Activity Log and VM authentication records, and GCP Cloud Audit Logs, looking specifically for sessions from unexpected sources or at unexpected times.
4. Rotate downstream credentials the key could reach. A key that opened a bastion host in one cloud can be a stepping stone toward credentials, secrets, or additional keys in another; treat anything reachable from the compromised session as potentially exposed.
5. Revoke IAM permissions immediately wherever IAM-based access was in use. Where OS Login or Entra ID login governs access, cutting the IAM or RBAC binding removes access instantly without touching every VM individually, faster than rotating a distributed static key.
6. Document one incident record, not three. Consolidate findings from all three clouds into a single record covering what was rotated, what was reviewed, and what evidence supports the response, feeding directly into the audit evidence process described above.

This is a summary of the immediate multi-cloud response, not a full incident response playbook. For step-by-step handling of an exposed SSH key in general, see Encryption Consulting’s Incident Response for Exposed SSH Keys guide.

Limitations

• The native cloud behaviors described here reflect AWS, Azure, and GCP documentation reviewed in 2026; all three providers update IAM and VM access features regularly, so verify current behavior against each provider’s live documentation before finalizing a control that depends on it.
• GCP OS Login must be explicitly enabled per project or instance; it is not GCP’s out-of-the-box default. A GCP estate that never turns it on is exactly as decentralized as an AWS or Azure estate.
• AWS Systems Manager Session Manager and Microsoft Entra ID login for Linux VMs remove the local private key from day-to-day access, but both still depend on correctly scoped IAM or RBAC policy; a misconfigured IAM role simply moves the risk from an orphaned SSH key to an overprivileged identity.
• This guide covers AWS, Azure, and GCP, the three hyperscalers most enterprise multi-cloud estates run on. Smaller or regional cloud providers, and on-premises or hybrid infrastructure, need the same discovery and centralization discipline described here, even though their native tooling differs from all three covered here.
• Guidance here is general. Regulated environments (FIPS 140-3, PCI DSS, HIPAA, DORA) should validate specific rotation cadences and control decisions against their own compliance obligations before finalizing policy.

What Would Encryption Consulting Recommend?

We would treat multi-cloud SSH access as one governed credential population, not three cloud-specific problems handled by three separate teams. In our engagements, the pattern repeats: an organization has reasonably mature controls in one cloud, often wherever the security team’s attention started, and almost no visibility into the other two, because nothing in AWS, Azure, or GCP forces cross-cloud visibility to exist on its own.

Through SSH Secure, Encryption Consulting gives organizations one centralized inventory and lifecycle across AWS, Azure, GCP, and on-premises infrastructure, rather than three separate per-cloud views a security team has to reconcile manually. Here is how that plays out in practice:

1. Centralized visibility and ownership mapping

Through agent-based and agentless discovery, SSH Secure locates every SSH key across AWS, Azure, and GCP instances alongside on-premises servers, and stores them in a single inventory with ownership and usage details, eliminating the fragmented, per-cloud spreadsheets most teams start with.

2. Secure access control and enforce session-bound keys

Granular role-based access control ensures users receive the minimum access required, enforced identically whether the target system sits in AWS, Azure, or GCP. For sensitive or temporary operations, SSH Secure issues ephemeral, session-bound keys that expire automatically, limiting blast radius no matter which cloud the session touches.

3. Automated key lifecycle orchestration across clouds

SSH Secure automates generation, policy-driven rotation, scheduled expiration, and revocation as one workflow that reaches AWS, Azure, and GCP together, so an offboarding event removes access from all three clouds in a single action instead of three separate manual steps.

4. HSM-integrated protection

Private keys are secured within HSMs, ensuring non-exportability and tamper resistance regardless of which cloud a key ultimately authorizes access to. Keys are generated using strong algorithms such as RSA-4096, ECDSA, and Ed25519, and remain isolated from the operating system’s memory even if a host in any of the three clouds is compromised.

5. Policy-driven control for key operations

All key operations, generation, approval workflows, rotation, and revocation, are enforced through policy-based controls that apply identically no matter which cloud a request touches, replacing the three separate, drifting policies that build up organically when each cloud team writes its own rules.

6. Continuous monitoring, auditing, and compliance readiness

SSH Secure provides real-time monitoring with detailed event logging, integrated with Splunk or Loki-Grafana dashboards, so activity from AWS, Azure, and GCP flows into one audit trail instead of three disconnected console logs. Centralized, policy-based alerts enable faster anomaly detection and incident response across the whole multi-cloud estate.

Frequently Asked Questions

Do AWS, Azure, or GCP rotate SSH keys automatically?

No. None of the three major clouds rotates SSH keys automatically by default. AWS EC2 key pairs and Azure VM authorized_keys entries stay valid indefinitely until someone manually replaces or removes them. GCP metadata keys behave the same way; GCP’s OS Login changes this only for IAM-governed access, where revoking a user’s IAM role functions like instant rotation, but it does not extend to service account or metadata-based keys.

What is the real difference between GCP OS Login and how AWS and Azure handle SSH keys?

OS Login binds SSH access directly to a Google IAM identity, so access updates automatically when IAM permissions change and does not depend on a stored private key for authorization decisions. AWS and Azure both offer comparable IAM-based alternatives, AWS Systems Manager Session Manager and Microsoft Entra ID login for Linux VMs, but both require installing a separate agent or extension and are opt-in additions layered on top of a key-based default, rather than a native SSH authentication path the way GCP’s OS Login is.

Can I replace SSH keys with IAM-based access in all three clouds?

You can move toward IAM-based access in each cloud individually, AWS Session Manager, Azure Entra ID login, and GCP OS Login all support it, but none of the three integrates with the others. Choosing IAM-based access in all three clouds still leaves you with three separate IAM systems to govern consistently, which is exactly the problem a centralized SSH key management layer is built to solve.

How do I get one inventory of SSH keys across AWS, Azure, and GCP?

You need a discovery process, or a dedicated SSH key management platform, that scans EC2 key pairs across every AWS region and account, VM authorized_keys entries across every Azure subscription, and GCP project or instance metadata and OS Login bindings, then normalizes all of it into a single record per key with an assigned owner. None of the three cloud consoles will produce that view natively, because none of them is aware the other two exist.

Does enabling GCP OS Login mean we no longer need an SSH key rotation policy?

No. OS Login removes stored private keys from the equation for interactive human logins on GCP Compute Engine, but service accounts, automation, and any instances or projects still using metadata-based keys keep the same rotation requirements as AWS and Azure. OS Login also only governs GCP, so a rotation policy is still required for whatever access model AWS and Azure are using.

Conclusion

AWS, Azure, and GCP each solve SSH key access for their own instances, and none of them solves it for your organization as a whole. That gap, not any single cloud’s weakness, is what turns multi-cloud SSH access into fragmented inventories, inconsistent rotation, and audit evidence that has to be assembled from three consoles under deadline pressure. Treating SSH keys as one governed credential population, with ownership assigned at issuance, rotation triggers that account for each cloud’s actual mechanics, policy enforced consistently through all three IAM models, and audit evidence gathered continuously rather than reconstructed, turns multi-cloud SSH access from a hidden, fragmented risk into a controlled, auditable part of the security program, regardless of which cloud a given key happens to touch.

Related Reading from Encryption Consulting

Further resources on SSH key lifecycle discipline, cloud cryptography, and the migration work discussed above:

• Comprehensive SSH Key Lifecycle Management for Enterprise Security, Encryption Consulting’s pillar guide to SSH key ownership, rotation, access policy, and audit evidence in any single environment.
• SSH Vulnerabilities and How to Protect Against Them covers protocol-level and implementation CVEs that affect SSH regardless of which cloud it runs in.
• Incident Response for Exposed SSH Keys is the full playbook behind the condensed steps in this guide’s incident response section.
• SSH Key Ownership goes deeper on assigning and enforcing ownership models for privileged credentials.
• PQC for Cloud Environments: Shared Responsibility Across AWS, Azure, and Google Cloud covers the same three-cloud comparison model applied to post-quantum migration responsibility.
• CBOM Secure extends cryptographic discovery beyond SSH keys to certificates and algorithms across every environment, cloud and on-premises alike.

References

• Create a key pair for your Amazon EC2 instance, Amazon Web Services
• AWS Systems Manager Session Manager, Amazon Web Services
• Detailed steps to create an SSH key pair, Microsoft Learn, Azure Virtual Machines
• Sign in to a Linux virtual machine in Azure by using Microsoft Entra ID and OpenSSH, Microsoft Learn
• About OS Login, Google Cloud, Compute Engine documentation
• Set up OS Login, Google Cloud, Compute Engine documentation
• Best practices for controlling SSH login access, Google Cloud, Compute Engine documentation
• NIST IR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH), National Institute of Standards and Technology
• State of Secrets Sprawl 2026, GitGuardian
• 2025 State of Machine Identity Security Report, CyberArk
• Cost of a Data Breach Report 2025, IBM