Manual SSH keys and bastion hosts create operational drift, extra maintenance, and inconsistent access governance. Teams must patch and secure another server, manage public reachability, and keep key distribution under control. At scale, this usually leads to weaker oversight, more configuration burden, and more opportunities for stale credentials to persist.
Why Manual SSH Access Breaks Down for EC2 Operations
Managing EC2 access with manual SSH keys and bastion hosts turns simple access into a fragile control chain. Every new instance, user, key, and bastion change creates another point where access can drift from policy, and every exception increases the chance that access survives longer than intended. That matters because EC2 fleets change quickly, while manual key review, key rotation, and bastion hardening usually do not keep pace.
For practitioners, the deeper issue is not just convenience. Manual SSH access makes identity governance depend on humans remembering to update multiple moving parts at once: the key, the bastion policy, the security group, and the instance profile or host-level trust assumptions. When those steps diverge, access becomes hard to explain and harder to revoke. The operational burden also encourages workarounds such as shared keys, delayed rotation, and broad bastion reachability, all of which weaken auditability and enlarge blast radius.
NHIMG’s research on the wider NHI problem is directly relevant here: its Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which illustrates how quickly long-lived access tends to outlive its intended governance. In practice, many teams discover the weakness only after a key must be revoked urgently and nobody can confirm where it was distributed.
How the Access Model Fails in Practice
SSH keys are durable credentials, so they work against the needs of elastic infrastructure. EC2 instances are often replaced, autoscaled, or rebuilt, but a manually managed key can remain valid across those changes unless someone actively tracks where it was installed. Bastion hosts do not remove that problem; they centralise it. Instead of many direct entry points, you now have one highly sensitive gateway that must be patched, monitored, restricted, backed up, and treated as a public exposure surface.
That creates several predictable failure modes. First, access review becomes approximate because teams cannot reliably answer who can reach which instance at any moment. Second, emergency revocation becomes slow because the team must coordinate key removal, bastion rule changes, and instance-level cleanup. Third, key sprawl and reused credentials tend to accumulate because manual distribution is easier than lifecycle discipline. Those conditions are exactly why the subject aligns with the broader identity-governance guidance in the OWASP Non-Human Identity Top 10 and why the lifecycle perspective in the NHI Lifecycle Management Guide is useful for teams still tied to static access paths.
- Manual SSH keys create a retention problem: if the key is not removed everywhere, access persists after the original need has ended.
- Bastion hosts create an availability and hardening problem: if the gateway is misconfigured, the whole access path inherits that weakness.
- Shared operational ownership creates an audit problem: security, platform, and application teams may each assume another group handled revocation.
Current guidance increasingly favors short-lived, centrally asserted access paths because they reduce dependence on human cleanup. The model breaks down fastest in fast-moving environments with many instances, frequent contractor access, or mixed operational ownership, because manual updates cannot keep pace with instance churn and credential turnover.
Where the Risk Becomes Material and What Practitioners Should Watch
Tighter SSH control often increases operational overhead, so organisations have to balance emergency access against the cost of maintaining it. The risk becomes material when a bastion host becomes the de facto trust anchor for production access, because then one compromise, one stale key, or one missed deprovisioning step can expose an entire EC2 estate.
Failure mechanism: The weakness materialises through credential persistence and control-plane drift. Long-lived SSH keys are copied, reused, or forgotten, while bastion hosts concentrate access and expand the number of systems that must be secured, monitored, and audited to preserve the illusion of central control.
Impact: The result is weaker revocation confidence, larger blast radius, and reduced assurance that the organisation can prove who accessed what and when. That creates both security exposure and governance exposure, especially when access must be removed quickly after a role change, incident, or third-party offboarding.
Practitioner Guidance: Treat manual SSH and bastion access as an exception path, not a normal operating model. Prioritise any environment where the same key reaches multiple instances or where the bastion can reach both production and non-production systems, because that is where stale access and lateral movement become hardest to contain.
What to verify: Confirm that every key has an owner, an expiry expectation, and a revocation path that actually removes access from all instances and all admin jump points. If the team cannot produce that evidence quickly, the access model is already too loose for reliable governance.
Decision rule: If access depends on humans remembering to rotate keys or clean up bastion rules, move to a design with shorter-lived credentials and stronger session attribution before the next scale increase or contractor onboarding event.
Practitioner takeaway: The real breakage is not SSH itself, but the assumption that static credentials and a single gateway can still provide trustworthy governance once EC2 operations become dynamic.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Static SSH keys are machine credentials that need controlled lifecycle and rotation. |
| NHI-02 — Identity Lifecycle Management | Manual key distribution and offboarding failures create orphaned EC2 access paths. | |
| Recommendation — Inventory SSH keys and enforce expiry, rotation, and revocation for every EC2 access credential. Tie EC2 access to joiner-mover-leaver workflows and remove unused keys on role change. | ||
| CIS Controls v8 | 6.3 — Access Control Management | The issue is unmanaged privileged access to hosts and jump points. |
| 5.3 — Account Monitoring and Control | Bastion-based access needs continuous visibility into who can still connect. | |
| Recommendation — Review and revoke SSH access paths that are no longer required for approved administration. Track privileged SSH accounts and alert on stale, shared, or unapproved access. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question concerns weak authentication governance for EC2 administration. |
| GV.5 — Roles, Responsibilities, and Authorities | Bastion and key ownership often fail when responsibility is unclear across teams. | |
| Recommendation — Apply stronger access governance so EC2 administration uses managed, reviewable authentication. Assign clear ownership for EC2 access paths, key rotation, and emergency revocation. | ||
| NIST Zero Trust (SP 800-207) | 3.2 — Continuous Diagnostics and Mitigation | Static keys and bastions weaken continuously verified access decisions. |
| Recommendation — Replace standing trust with continuously evaluated access decisions for administrative sessions. | ||
Related resources from NHI Mgmt Group
- What breaks when organisations keep using shared API keys for machine-to-machine access?
- What breaks when organisations keep managing non-human access separately in on-prem and cloud systems?
- What breaks when organisations rely on manual password and SSH key rotation to control access?
- What breaks when organisations rely only on posture management for agentic AI access control?
