When bastion logs stay only on the jump host, the record is vulnerable to the same compromise that affects the access path. That creates a blind spot for incident response, compliance, and post-incident reconstruction. If the host is altered or deleted, the organisation loses the evidence needed to prove who accessed what and when.
Why This Matters for Security Teams
When bastion logs stay only on the jump host, the organisation makes the logging plane depend on the same system that grants access. That defeats the point of having an audit trail because compromise, tampering, deletion, or simple host failure can remove the record at the exact moment it is needed most. For incident response, that means weaker reconstruction of operator actions, session timing, and command history.
This is not just an engineering nuisance. It affects compliance evidence, internal investigations, and control validation for privileged access. NHI Management Group’s Ultimate Guide to NHIs notes that 5.7% of organisations have full visibility into their service accounts, which is a reminder that visibility gaps often begin with weak logging and end with missing accountability. The NIST Cybersecurity Framework 2.0 reinforces that logs must support detection, response, and recovery, not sit inside the same trust boundary as the access mechanism. In practice, many security teams discover the gap only after a privileged session has already been abused or the jump host has already been rebuilt.
How It Works in Practice
A bastion or jump host should be treated as an access broker, not as the final system of record. The useful pattern is to forward session telemetry off the host in near real time to an immutable or separately protected log store, where it cannot be altered by the same administrators who manage the bastion. That usually includes authentication events, session start and stop times, source and destination addresses, and command or keystroke capture where policy permits.
For privileged access management, the goal is to separate control from evidence. If the bastion is compromised, an attacker should not be able to erase the external record. If the host is lost, the external log stream should still preserve the timeline. This is why strong bastion designs use outbound log shipping, restricted write paths, and retention controls that are enforced outside the jump host. Current guidance suggests aligning this with least privilege and zero trust principles rather than assuming the bastion is inherently trustworthy.
- Send logs to a remote SIEM, log archive, or write-once destination as sessions occur.
- Protect log integrity with restricted access, retention policy, and tamper-evident controls.
- Correlate bastion events with identity, PAM, and network telemetry for reconstruction.
- Test whether logs survive host rebuild, snapshot rollback, and administrator compromise.
For environments that use NHI-driven automation, this becomes even more important because service accounts and automation identities may traverse the bastion without human supervision. The logging layer must capture the workload identity and the action context, not merely a terminal connection. NHI Management Group’s Ultimate Guide to NHIs also shows how common it is for secrets and access paths to be mishandled, which makes independent evidence retention a core control rather than an optional enhancement. These controls tend to break down in small environments where the jump host doubles as both management plane and log repository, because a single compromise then destroys access and evidence at the same time.
Common Variations and Edge Cases
Tighter logging controls often increase storage, operational overhead, and investigation complexity, so organisations have to balance retention depth against cost and administrative burden. That tradeoff is real, but it does not justify keeping logs only on the bastion.
There is no universal standard for session recording depth yet. Some teams capture full keystrokes, while others capture metadata only because of privacy, performance, or jurisdictional constraints. In highly regulated environments, command replay may be necessary; in others, preserving identity, destination, and timestamp evidence may be sufficient. The important point is that the evidence must outlive the host.
Edge cases often appear in ephemeral infrastructure, disaster recovery, and air-gapped systems. In those environments, local-only logging can seem convenient, but it creates a single point of failure for both security monitoring and auditability. If the bastion is rebuilt from an image, rolled back from a snapshot, or used as a break-glass system, local logs can disappear unless they are exported continuously. That is why mature programs pair bastion logging with external retention, periodic restore testing, and clear chain-of-custody handling.
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 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-08 | Session evidence and visibility are essential to NHI accountability. |
| NIST CSF 2.0 | DE.CM-7 | Continuous monitoring requires logs that remain available after host failure. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust expects auditable access decisions beyond a single trusted host. |
Separate bastion access from log custody so privileged actions stay verifiable outside the host boundary.
