Ownership should sit with the operators who control access policy, retention, and storage for the tailnet, typically network admins or security platform teams. They need to decide where recordings are stored, who can review them, and how long they are kept. Clear ownership matters because session records are sensitive evidence, not ordinary operational logs.
Who should own SSH session recording when multiple teams share admin access?
Ownership belongs with the team that governs the access policy and the evidence lifecycle, not with every team that can use the access. In practice, that is usually the network administration or security platform function, because it can define who may initiate sessions, where recordings are stored, who may review them, and how long they are retained.
Why shared administrative access needs a single recording owner
ssh session recording is not just a convenience feature. It creates a record of privileged activity, which means the owner must be able to set the rules for collection, retention, access review, and deletion. If each consuming team controls its own copy of the evidence, you get inconsistent retention, uneven review rights, and a weaker chain of custody. A centralized Privileged Session Management Guide is the clearest reference point for how recording, session brokering, and session audit should stay under one accountable function.
That owner should also be the team that can reconcile recording policy with privileged access policy. If one group controls access and another controls the recordings, the result is often a split-brain process where nobody can confidently answer when a session must be captured, which sessions are exempt, or who is allowed to inspect evidence after an incident. When the environment includes SSH key handling and bastion access, the operational boundary becomes even more important, which is why SSH Key and SSH Certificate Management Guide is relevant to the surrounding control model.
What the owner is responsible for in a multi-team tailnet
The recording owner should define the control plane, while participating teams remain consumers of the service. That means setting policy for session capture, deciding whether recordings are stored centrally or in a restricted evidence store, and defining who can request or approve playback. The owner should also govern exceptions, because shared admin access almost always creates pressure for break-glass usage, temporary delegation, or vendor support sessions.
Good ownership also means treating recordings as sensitive security evidence rather than routine telemetry. The owner should be the function that can enforce review rights and preserve records long enough to support incident response, compliance, and dispute resolution. Where privileged access policy is already formalized, the broader governance model in the Privileged Access Management Guide helps anchor the decision in least privilege, zero standing privilege, and controlled session oversight.
How to avoid confusion when several teams need the same evidence
The safest operating model is one owner, multiple stakeholders. Network, platform, and security teams can all have legitimate interest in the recordings, but only one function should own policy, retention, and storage decisions. That prevents informal duplication of evidence and reduces the chance that a team with temporary operational access also becomes the de facto custodian of sensitive session data.
The most common mistake is to let the team that “runs the systems” also own the evidence without explicit governance. That works until there is a dispute about access review, an incident investigation, or a request to hold or delete records. At that point, ownership ambiguity becomes a control failure, not just an administrative inconvenience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | SSH session recording defines which privileged actions must be captured. |
| AU-9 — Protection of Audit Information | Recorded SSH sessions are sensitive evidence that needs protected storage and access. | |
| AC-6 — Least Privilege | Shared admin access should be constrained so recording ownership and access are separated. | |
| Recommendation — Define auditable SSH admin events and ensure they are recorded consistently. Protect session recordings from unauthorized access, alteration, and deletion. Limit who can administer access policy, playback, and retention settings. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Ownership of SSH recordings depends on controlled access to privileged evidence. |
| A.8.15 — Logging | Session recording is an evidentiary logging function for privileged activity. | |
| Recommendation — Assign and enforce access control responsibilities for session recordings. Ensure privileged SSH activity is logged and reviewable under a defined owner. | ||
Practitioner Guidance
What to verify: Confirm that one named function owns policy, retention, and storage, and that all other admin teams are only consumers or approvers within that model. If session playback, retention changes, or storage location changes can be made by the same teams that initiate administrative access, the control is too loosely owned.
What good looks like: The recording owner can show where sessions are stored, who can review them, how exceptions are approved, and when records are deleted. The operating model should make it easy to answer, “who controls the evidence?” without guessing across teams.
Decision rule: If a team can change both access policy and the recording lifecycle, that team should formally own session recording. If multiple teams need operational visibility, give them access to the records, not ownership of the recordkeeping function.
Practitioner takeaway: In shared-admin environments, session recording should follow accountability for evidence, not popularity of use. The right owner is the function that can keep capture, retention, and review controls consistent across every team that touches privileged access.
Related resources from NHI Mgmt Group
- Who should own identity control evidence when multiple teams share access governance?
- Who should own collection access when multiple teams share sensitive items?
- How should security teams implement SSH session recording for EC2 access in a way that supports audit and compliance requirements?
- How should security teams run access reviews for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org