Revocation and forensics both fail. If teams cannot see which operator reached which host through which jump server, they cannot prove scope, reconstruct misuse, or confidently retire access after a change. Bastion logging needs to connect the initiating identity, the relay host, and the final destination.
Why This Matters for Security Teams
End-to-end bastion logging is not a nice-to-have control. It is the only way to connect operator intent, jump host mediation, and the final target system when privileged access is being brokered through a relay. Without that chain, revocation becomes guesswork and forensic review becomes incomplete. Current guidance across OWASP Non-Human Identity Top 10 and NHI governance work from Ultimate Guide to NHIs points in the same direction: identity telemetry must preserve the full access path, not just the login event.
When logging stops at the bastion shell, teams lose the evidence needed to prove which session touched which asset, whether privilege was appropriate, and whether access can be retired after a change window. That gap also weakens Zero Trust validation because the control plane cannot verify what actually happened after authentication. In practice, many security teams discover the missing linkage only after a misuse investigation has already stalled, rather than through intentional control testing.
How It Works in Practice
Effective bastion logging should create an auditable chain from the initiating identity to the relay host and onward to the destination. That means recording who authenticated, when the session started and ended, what host was used as the jump point, what destination was reached, and which command or action occurred where that is technically feasible. For NHI and operator workflows, the important point is correlation, not just collection.
Practitioners usually implement this in layers:
- Authentication logs on the bastion capture the initiating user or service identity.
- Session logging records the relay host, timestamps, and session identifiers.
- Command or keystroke logging, where permitted, adds action-level traceability.
- Target-side logs validate that the destination system accepted the session and show what was changed.
- Central correlation ties all records to a single incident, review, or access request.
This is where the broader NHI visibility problem becomes operational. NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for bastion-operated environments as well. If the access path cannot be reconstructed, revocation decisions are slow and disputed, and controls like JIT access or PAM session approval lose evidentiary value. Standards such as OWASP Non-Human Identity Top 10 support this traceability expectation, while CISA Zero Trust Maturity Model reinforces continuous verification across the access path.
These controls tend to break down when bastion traffic is proxied again through nested tunnels, because the destination system can no longer be tied cleanly to the original initiating identity.
Common Variations and Edge Cases
Tighter session logging often increases storage, privacy review, and operational overhead, so organisations have to balance forensic depth against data-handling constraints. That tradeoff matters because some environments need full command capture, while others only need session metadata and immutable destination logs.
Best practice is still evolving for environments that mix human operators, service accounts, and automated admin agents on the same bastion. In those cases, separate identity classes and distinct session tags are essential, otherwise an audit trail becomes ambiguous the moment an automated workflow reuses a human-facing jump path. Guidance from 52 NHI Breaches Analysis shows that identity misuse often becomes visible only after lateral movement has already occurred. For teams that manage high-risk remote administration, this is where controls must be paired with strong retention, tamper resistance, and consistent time sync across the bastion and target estate.
There is no universal standard for how much command-level content must be retained, but the minimum expectation is clear: if an incident responder cannot answer who accessed what through which relay and what happened next, the logging design is incomplete.
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-01 | End-to-end session traceability supports identity visibility and misuse investigation. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring depends on complete access-path telemetry. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires verifying access decisions and session outcomes, not just login. |
Treat bastion logs as policy evidence and validate the full path on every privileged session.
