What do security teams get wrong about SSH logging for privileged access?

Why This Matters for Security Teams

SSH logging is often treated as a checkbox for privileged access, but that misses the control objective. A connection record proves that a session existed; it does not prove what changed, which commands were run, or whether the activity aligned with the intended administrative purpose. That gap becomes critical when SSH is used for break-glass access, production support, or automation on hardened hosts. The OWASP Non-Human Identity Top 10 frames this as an identity and trust problem, not just a logging problem.

For NHI-heavy environments, logging also supports evidence retention, control validation, and incident reconstruction. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes high-fidelity session data especially valuable for privileged access review. The lesson is simple: if a team cannot inspect the activity inside the SSH session, it is relying on incomplete proof for the highest-trust path in the environment. In practice, many security teams discover this only after a privileged incident has already moved laterally through an otherwise “logged” SSH channel.

How It Works in Practice

Effective SSH logging starts by deciding what question the logs must answer. For audit and forensics, teams usually need session start and stop times, source identity, destination host, privilege elevation events, keystroke or command capture, file transfer activity, and immutable retention. For control validation, logs should also show whether access was granted through a broker, whether the account was approved for the target system, and whether the session aligned with the expected change window or ticket.

Current guidance suggests combining SSH logs with stronger identity controls rather than treating logging as the primary safeguard. That means tying access to privileged access management, enforcing short-lived credentials where possible, and correlating session telemetry with identity, host, and change data. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports this broader evidence model through audit and accountability controls, while the NHIMG Ultimate Guide to NHIs emphasises that weak visibility and poor rotation are common contributors to compromise.

• Use session recording for high-risk hosts, not just connection logs.
• Protect logs with tamper-resistant retention and restricted access.
• Correlate SSH activity with ticketing, PAM approval, and endpoint telemetry.
• Separate human admin access from automation accounts and service accounts.
• Alert on unusual command sequences, off-hours use, or data movement from privileged shells.

Where this guidance breaks down is in legacy jump hosts or ephemeral cloud nodes that cannot reliably record interactive activity because session mediation, storage, or host hardening is incomplete.

Common Variations and Edge Cases

Tighter SSH logging often increases storage, processing, and review overhead, requiring organisations to balance forensic depth against operational friction. That tradeoff is real, especially in large estates where every admin session cannot be manually reviewed. Best practice is evolving toward risk-based logging: full session capture for crown-jewel systems, command-level logging for lower-risk estates, and stronger detection logic for everything else.

There is no universal standard for exactly how much SSH content must be recorded in every environment. Some teams record keystrokes only, while others capture full terminal playback or proxy-mediated sessions. The right choice depends on legal constraints, privacy expectations, and the sensitivity of the target systems. What matters is that the evidence can answer who accessed what, when, from where, and to do which task. The NHIMG Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how visibility gaps and excessive privileges compound each other.

Edge cases also matter. SSH used by automation or CI/CD pipelines should not be treated like a human admin shell, because a single service account may touch many systems at machine speed. Likewise, encrypted tunnels, bastion chaining, and proxy jumps can obscure the true source of a session unless telemetry is stitched together across layers. In these cases, session logging alone is not enough, and teams should pair it with strong workload identity, host attestation, and command-policy enforcement. The control usually fails when administrators equate “recorded login” with “proven safe activity” in highly automated or heavily proxied environments.

Related resources from NHI Mgmt Group

• What do security teams get wrong about access control when they focus only on login authentication?
• What do security teams get wrong about agentic access logging?
• What do security teams get wrong about privileged access governance?
• What do security teams get wrong about using chat for privileged access?