The warning signs are familiar: long lived keys, inconsistent permission rules, manual firewall exceptions, and remote access paths that vary by team or server. If session activity is hard to audit, or if administrators need separate workarounds for different environments, SSH is still behaving like a legacy privilege channel rather than a zero trust access mechanism.
What standing trust looks like in SSH
SSH becomes a standing-trust problem when access is persistently available instead of being narrowly granted for a specific need. That usually shows up as keys that stay valid for long periods, accounts that can reach too many hosts, and exceptions that outlive the task they were created for. The issue is not SSH itself, but the amount of durable privilege wrapped around it.
Another sign is when SSH is used as the default escape hatch for operational problems. If teams rely on ad hoc firewall openings, shared jump paths, or environment-specific workarounds to make remote administration work, the access model is drifting away from controlled, verifiable trust. The more the path changes by team or server, the less it behaves like a governed access channel.
For practitioners, the key question is whether SSH access is issued, bounded, and revoked as part of a lifecycle, or whether it is effectively treated as a permanent right. If the latter is true, remote access is not just convenient, it is cumulative privilege.
Operational signals that the trust model is too loose
Several practical signals point to excess standing trust. Long-lived keys are a clear one, especially when there is no defined rotation cadence or ownership for revocation. Another is inconsistent permission rules, where the same operator or automation account can reach different systems with materially different guardrails depending on who configured the host.
Manual firewall exceptions are another strong indicator. They often mean access was granted to solve a point-in-time need, then left in place because removing it felt risky or time-consuming. When paired with weak auditability, that creates a control gap: the organisation can no longer tell whether a connection is still justified, still used, or still exposed.
Remote access paths that vary by team or server also deserve attention. If one group uses bastion-style workflows, another uses direct host access, and a third has a bespoke bypass, the access model is inconsistent enough that policy cannot be applied cleanly. That inconsistency is often the practical evidence that privilege is being managed locally instead of centrally.
- Ultimate Guide to NHIs is a useful baseline for checking whether SSH-related secrets, keys, and rotation practices are being governed as identity material.
- Ultimate Guide to NHIs, Key Challenges and Risks helps frame why visibility gaps, sprawl, and over-privilege are the recurring failure modes behind standing trust.
- 52 NHI Breaches Analysis provides real incident patterns that show how long-lived access material can become a breach path.
Risk and Threat Considerations
Excess standing trust in SSH increases the blast radius of a stolen key, a compromised admin workstation, or an abused automation path. If the same access works broadly and persists indefinitely, an attacker does not need to win a fresh approval step each time they move from initial foothold to lateral movement.
Failure mechanism: access is granted once, then left in place across hosts, teams, or environments, so the organisation loses the ability to distinguish legitimate administration from durable overreach or abuse.
Impact: compromise becomes easier to scale, rotation becomes harder to execute cleanly, and audit evidence becomes less trustworthy because the access path no longer reflects current business need.
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 NIST CSF 2.0, CIS Controls v8 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 — Secret Sprawl and Rotation | SSH keys and long-lived credentials are standing trust risks. |
| NHI-02 — Excessive Privilege | Overbroad SSH reach and team-specific bypasses indicate excess privilege. | |
| NHI-05 — Visibility and Inventory | Hard-to-audit SSH paths point to weak visibility and inventory. | |
| Recommendation — Rotate SSH keys on a defined schedule and remove unmanaged credentials. Constrain SSH access to least privilege and remove broad host reach. Inventory SSH access paths and keep ownership, scope, and usage reviewable. | ||
| NIST CSF 2.0 | PR.AC — Access Control | SSH standing trust is an access-control and trust-boundary problem. |
| DE.CM — Continuous Monitoring | Auditable session activity is central to detecting SSH misuse. | |
| Recommendation — Enforce least-privilege remote access and remove persistent exceptions. Continuously monitor SSH sessions and alert on anomalous access paths. | ||
| CIS Controls v8 | 6 — Access Control Management | SSH access should be provisioned, reviewed, and revoked as controlled access. |
| 8 — Audit Log Management | The question highlights whether SSH activity is sufficiently auditable. | |
| Recommendation — Review SSH entitlements regularly and revoke stale access immediately. Centralise SSH logging so administrators can trace who accessed what and when. | ||
| NIST Zero Trust (SP 800-207) | AC-3 — Policy Enforcement at the Resource | SSH should not rely on durable trust paths that bypass policy checks. |
| AC-4 — Information Flow Control | Varying firewall exceptions and server-specific paths reflect weak flow control. | |
| Recommendation — Enforce policy-based SSH access at each protected host or service. Restrict SSH connectivity to approved paths and segment remote administration flows. | ||
Practitioner Guidance
What to verify: confirm that every SSH key or equivalent credential has an owner, a purpose, an expiry or rotation expectation, and a revocation path that is actually used. If you cannot tie a key to a current business need, treat it as standing privilege until proven otherwise.
What good looks like: the access path is predictable, centrally reviewable, and narrow enough that different teams do not need bespoke exceptions to reach production systems. Healthy SSH governance should make it easy to answer who can connect, to what, through which path, and for how long.
Practitioner takeaway: SSH is still carrying too much standing trust when access survives longer than the task, the exception, or the team that needed it; the practical fix is not more convenience, but tighter lifecycle control and fewer durable bypasses.
Related resources from NHI Mgmt Group
- Why does identity-based access reduce risk in SSH environments that still depend on passwords or shared keys?
- What are the signs that ERP access governance is too weak to manage risk effectively?
- What are the signs that an age assurance step is creating too much user drop off?
- What are the signs that OpenID Connect may be creating too much login risk?
