How should security teams manage SSH access as insurers move infrastructure to the cloud?

Security teams should treat SSH access as part of cloud governance, not as a leftover admin convenience. The practical goal is to discover every key, map who or what uses it, remove obsolete credentials, and restrict access to the minimum task scope needed. That reduces hidden lateral movement paths, supports audit readiness, and prevents legacy access patterns from reappearing in cloud environments.

Why SSH Access Becomes a Governance Problem in Cloud Migrations

SSH is not just a remote login method in a cloud environment. It is an access path that can bypass the visibility and approval model teams expect from cloud platforms, so unmanaged keys quickly become standing privilege. The first job is to inventory every SSH credential, understand which systems it reaches, and decide whether that access is still justified.

That governance view matters because cloud migration often preserves old admin habits: shared keys, long-lived access, and unclear ownership. Those patterns are easy to miss during lift-and-shift work, but they create hidden paths into workloads that should otherwise be tightly segmented and auditable.

What Good SSH Access Management Looks Like in Practice

Effective management starts with discovery and classification. Teams should identify every key, certificate, or delegated access path; tie each one to a named owner or automation use case; and remove anything that no longer maps to a live business need. If the access is still required, it should be time-bounded, task-bounded, and limited to the smallest environment scope that actually needs it.

That usually means replacing persistent human access with stronger operational controls: short-lived credentials where possible, separate access for production and non-production, and a clear rotation or revocation process for any key material that remains in use. The practical test is simple, if a key cannot be explained, rotated, or revoked quickly, it is already too risky for cloud operations.

Cloud teams also need to treat SSH as part of the overall control plane, not as an isolated server setting. That means logging access, reviewing authentication events, and making sure remote admin access is visible to security operations and audit functions, rather than hidden inside ad hoc host configuration.

How to Keep Legacy SSH From Reappearing in Cloud Operations

The hardest part is not initial cleanup, it is preventing reintroduction. Cloud platforms make it easy for engineers and administrators to recreate old patterns if there is no explicit policy for who may use SSH, when it is allowed, and what compensating controls must exist. A strong operating model ties SSH approval to business justification, environment sensitivity, and monitoring requirements.

Teams should also separate emergency access from routine administration. Break-glass SSH paths, if they exist at all, should be rare, tightly logged, and regularly tested so they do not become a permanent back door. In practice, the same governance question should be asked every time a new workload is deployed: can this be administered without persistent SSH access, and if not, what is the smallest safe exception?

For insurers, the answer is especially important because cloud migration often increases the number of parties involved in administration, including managed service providers and platform teams. Each additional operator widens the set of keys, trust relationships, and review obligations that security teams have to govern.

Risk and Threat Considerations

Unmanaged SSH access creates a durable intrusion path, especially when old keys survive migration, are shared across teams, or are reused across environments. That turns a single credential into a lateral movement mechanism that may remain invisible until an attacker or careless admin uses it.

Failure mechanism: persistent keys, broad host reach, and weak ownership allow access to outlive the original need, which defeats cloud segmentation and makes revocation slow when a system or user is compromised.

Impact: exposed SSH access can lead to unauthorized administrative control, harder incident containment, and audit findings that show the environment still depends on legacy access assumptions.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	SSH access depends on account and credential governance across cloud workloads.
Recommendation — Inventory SSH-enabled accounts and remove unused or excessive access paths.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	SSH keys and certificates are authenticators that require lifecycle control and rotation.
	AC-6 — Least Privilege	SSH should be constrained to the minimum administrative scope needed.
Recommendation — Rotate, revoke, and expire SSH authenticators on a defined lifecycle. Limit SSH privileges to the smallest task and environment scope.
ISO/IEC 27001:2022	A.5.15 — Access control	Cloud SSH administration is an access-control governance issue.
Recommendation — Define and enforce approved SSH access rules across cloud environments.
CSA Cloud Controls Matrix	IAM — Identity & Access Management	Cloud SSH management sits within cloud IAM governance and control design.
Recommendation — Map SSH administration to cloud IAM policies and approvals.

Practitioner Guidance

What to prioritise: start with keys that reach production systems, shared accounts, and any credential with no named owner or expiry. Those are the fastest route to hidden privilege and the hardest to defend after an incident.

What to verify: confirm that every approved SSH path has an owner, an explicit business purpose, and a documented revocation method. If you cannot prove who can use it and how it is removed, the control is not operationally complete.

Practitioner takeaway: treat SSH as a governed access mechanism with a lifecycle, not as a convenience feature, because cloud migration only becomes safer when remote admin paths are explainable, limited, and removable.