Privileged Session Management Guide

Controlling who can obtain privileged access is only half the job. The other half is controlling and seeing what they do with it. Privileged session management (PSM) brokers, monitors and records sessions to servers, databases, network devices, cloud consoles, Kubernetes clusters and business applications, so that credentials stay hidden, risky commands can be blocked and every action can be reviewed. This guide explains how PSM works, which systems to put behind it, what to detect and review, how to govern recordings lawfully and how to extend the same oversight to scripts, service accounts and AI agents. It is written for PAM owners, infrastructure engineers, security operations teams and auditors.

Key takeaways

Broker and record: PSM places an intermediary between the administrator and the target, injects the credential so the user never sees it, and records what happens in the session.
Cover the high-risk paths first: tier-zero identity systems, production servers and databases, cloud control planes, management consoles and all third-party and vendor access.
Review, do not just store: recordings only help if they are indexed, risk-scored, tied to change tickets and fed to detection. Unwatched video is not a control.
Protect the broker: a PAM gateway or jump server holds the keys to most privileged roles, so it must be hardened, patched and monitored as tier-zero infrastructure.
Extend oversight to machines and agents: automation, service accounts and AI agents performing administrative work need logged tool calls, human approval for high-impact actions and a way to stop them.

How privileged session management works

NIST SP 800-53 Rev. 5 describes the core capability in control AU-14 (Session Audit): the ability for defined users or roles to record, view, hear or log the content of a user session, developed and used in consultation with legal counsel. A typical brokered session runs through five steps:

Authenticate and request: the user signs in to the PAM platform with phishing-resistant MFA and, where policy requires, requests time-bound access with a reason and ticket number. See the JIT Access Guide.
Broker: the gateway or proxy opens a session to the target, injecting the privileged credential from its vault so the user never handles it.
Monitor and record: keystrokes, commands, SQL queries, screen video or API calls are captured, depending on protocol.
Enforce: policies block risky commands, raise alerts on sensitive actions, and allow a supervisor to watch live and terminate the session.
Close: the session ends on completion, timeout or termination, and the credential can be rotated so that anything observed during the session is worthless afterwards.

Architecture patterns

Microsoft's guidance on privileged access intermediaries lists jump servers, virtual desktops and access proxies as intermediaries, and notes that in the administrator scenario they consolidate administrative pathways and add just-in-time access and "session monitoring and recording". Most estates combine several patterns:

Pattern	How it works	Strengths	Watch for
PAM proxy or gateway	Protocol-aware proxy for SSH, RDP, database and web sessions with credential injection	Credentials hidden; command-level policy; central recording	Holds credentials for most privileged roles, so it is a prime target
Jump server	Hardened host that administrators reach before connecting onwards	Simple; works with legacy protocols	Many sensitive sessions pass through one host where credentials can be stolen
Cloud-native bastion or session service	Provider service brokers shell or RDP sessions, for example Azure Bastion or AWS Systems Manager Session Manager	No inbound ports; logs go to provider storage; smaller attack surface	Feature limits, such as Session Manager not logging port-forwarded or SSH sessions
API and control-plane logging	Cloud audit logs and Kubernetes API server audit events record each privileged call	Covers automation and consoles that have no interactive session	Logging depth depends on policy; some levels omit request bodies

What to protect with PSM

Apply session controls where a single session can do the most damage. See the Tiered Administration Guide.

Target	Why it matters	Suggested session control level
Domain controllers, identity providers, PKI	Control over every other identity	Brokered, recorded, live alerting, dual control for sensitive changes
Endpoint and device management consoles	One console can push commands or wipes to every device	Brokered, recorded, approval for bulk destructive actions
Production servers, databases, Kubernetes clusters	Data access and service availability	Brokered, command and query logging, deny lists
Cloud management consoles and privileged CLI	Control-plane changes across accounts and subscriptions	Just-in-time elevation plus provider audit logs
Network and security devices	Can disable logging, open paths or hide activity	Brokered and recorded
Business-critical application admin (ERP, payments, HR)	Fraud and segregation of duties risk	Recorded, linked to change tickets
Third-party and vendor remote access	Access from devices and people you do not manage	Brokered, recorded, time-bound, always reviewed

The levels above are NHI Mgmt Group suggestions rather than requirements of any standard. Management consoles deserve special attention: in the Stryker Cyberattack 2026, a source told BleepingComputer that an attacker compromised an administrator account, created a new Global Administrator and used Intune to wipe nearly 80,000 devices in about three hours. Vendor access needs its own discipline; see the Third-Party Access Guide and the Remote Access Identity Guide.

Monitoring and review

Recording every privileged session creates more material than anyone can watch, so make sessions searchable and spend human attention where it matters.

Index everything: tag recordings by user, target, account, ticket, commands and time.
Risk-score sessions: rank by commands run, target tier, time of day and ticket status, and review the highest-scoring ones rather than a random sample.
Correlate with change records: privileged activity with no matching ticket or approved change is a finding to investigate.
Analyse commands as text: SP 800-53 enhancement AU-6(8) calls for full text analysis of logged privileged commands on a separate, dedicated component.
Review vendor sessions every time: MA-4(1) asks organisations to log nonlocal maintenance and diagnostic sessions and review those records to detect anomalous behaviour.
Feed the SOC: send session start, end, alert and termination events to the SIEM and identity threat detection tooling. See the ITDR Guide.

Know what each platform does not capture. AWS documents that Session Manager logging is not available for sessions that connect through port forwarding or SSH, and that EventBridge cannot see actions inside a session, such as an exit command, that make no API call. Kubernetes records nothing unless an audit policy file is passed to the API server, and its Metadata level logs who did what without request or response bodies.

Detection and monitoring

NIST CSF 2.0 DE.CM-03 asks that personnel activity and technology usage are monitored to find potentially adverse events, and DE.CM-06 extends this to external service provider activities. Build these detections first.

Signal	Why it matters	Source
Account creation or privileged group or role change inside a session	Common persistence and escalation step	Session command log, directory audit log
Logging or security tooling disabled, audit policy changed	Attackers blind defenders before acting	Command log, platform audit events
Bulk export, archive creation or large file transfer	Possible data theft	Session file transfer log, database query log
Encoded or obfuscated scripts, download of remote tools	Typical of hands-on-keyboard intrusion	Command-line logging
Bulk destructive commands (wipe, delete, drop)	One session can cause an outage	Console audit log, command log
Privileged access that bypasses the broker	Unrecorded path to the target	Target authentication logs compared with broker session list
Session at an unusual time, from a new location or with no ticket	Account misuse or stolen credentials	Broker logs, IdP sign-in logs, ticketing system

The bypass detection is the one most often missing: any privileged logon on a target that the broker cannot explain is either a coverage gap or an intruder. SP 800-53 AC-2(12) (Account Monitoring for Atypical Usage) and CIS Safeguard 8.11 (Conduct Audit Log Reviews) give the control basis.

Controls within sessions

Recording tells you what happened; in-session controls stop some of it happening. Apply them by target tier so routine work is not slowed.

Control	What it prevents	Related SP 800-53 control
Command allow and deny lists for shell and database sessions	Destructive or out-of-scope commands	AC-6(9) Log Use of Privileged Functions; AC-3(2) Dual Authorization for listed commands
Restrictions on file transfer, clipboard and port forwarding	Data exfiltration and tunnelling around the broker	AC-17(1) Monitoring and Control
Live monitoring with the ability to terminate	Damage continuing while a reviewer watches	AU-14(3) Remote Viewing and Listening; AC-17(9) Disconnect or Disable Access
Session time limits and idle termination	Abandoned sessions being reused	AC-12 Session Termination; SC-10 Network Disconnect
Dual control (four-eyes) for the most sensitive operations	Single-person insider or stolen-account abuse	AC-3(2) Dual Authorization
Credential rotation at session end	Reuse of anything observed during the session	IA-5 Authenticator Management

Dual control is the strongest and most expensive of these. Microsoft's intermediaries guidance recommends setting up a second person in business-critical workflows to raise the cost of insider collusion. Reserve it for actions such as changing tier-zero group membership, bulk wipes and disabling security tooling. See the Segregation of Duties Guide.

Privacy and governance

Session recording is monitoring of workers, and data protection law applies. AU-14 itself says session auditing should be developed and used in consultation with legal counsel. In the UK, the ICO's guidance on monitoring workers says that employers must tell workers about monitoring in a way that is accessible and easy to understand, must carry out a data protection impact assessment (DPIA) before processing likely to cause high risk, and lists keystroke monitoring among its examples of high-risk processing.

Tell users: explain that sessions are recorded, what is captured and why.
Do a DPIA: keystroke capture and screen recording are likely to need one; involve workers or their representatives, as the ICO says employers should seek and document their views unless there is a good reason not to.
Restrict and log viewing: limit access to recordings to named reviewers, train them, and log every playback. SP 800-53 AU-9(4) limits management of audit logging to a subset of privileged users.
Set and enforce retention: the ICO says monitoring data must not be kept longer than necessary and that you must have a retention schedule. Align it with audit and legal hold needs (AU-11 Audit Record Retention) and delete on schedule.
Keep secrets out of recordings: AWS recommends commands that suppress echo when entering passwords in Session Manager, because session logs capture commands and output.
Protect integrity: store recordings where administrators being recorded cannot alter or delete them. CISA's remote access software guide advises keeping log servers, and the ability to delete or alter logs, out of reach of remote management tools.

Where works councils or national rules apply, consult them before switching on recording. This guide is not legal advice.

Beyond human sessions

Much privileged activity no longer happens interactively: scripts, pipelines, service accounts and AI agents call APIs directly.

Automation and service accounts

Broker or shorten: automation using privileged credentials should connect through brokered access or use short-lived credentials, with every API call logged. The OWASP Non-Human Identities Top 10 lists Overprivileged NHI (NHI5) and Long-Lived Secrets (NHI7) among the main risks.
Log the control plane: cloud audit logs and Kubernetes API server audit events are the session record for automation. Use a Kubernetes audit level that captures request bodies (Request or RequestResponse) for sensitive resources.
Watch for humans using machine accounts: an interactive logon with a service account is a strong signal of misuse. See the Service Account Security Guide and the Cloud PAM and CIEM Guide.

AI agents performing administrative work

An AI agent with infrastructure tools is a privileged session that never ends unless you design an end. The OWASP Top 10 for Agentic Applications (2026) recommends, among other mitigations:

Immutable logs of every tool call: "Maintain immutable logs of all tool invocations and parameter changes" (ASI02 Tool Misuse and Exploitation), with monitoring for unusual tool chaining.
Human approval for privilege: require human approval for high-privilege or irreversible actions (ASI03 Identity and Privilege Abuse).
Task-scoped, time-bound credentials: short-lived, narrowly scoped tokens per task and per-agent identities (ASI03).
A kill switch: kill switches and credential revocation to disable a rogue agent quickly (ASI10 Rogue Agents).

In PSM terms, tool calls are the keystrokes, approval is dual control and the kill switch is session termination. See the AI Agent Observability and Incident Response Guide and the AI Agent Authorisation Guide.

Securing the session platform itself

The broker is the most valuable system in the privileged access chain. Microsoft notes that PIM/PAM solutions "typically store the credentials for most or all privileged roles in the organization, making them a highly lucrative target to compromise or to weaponize", and that jump servers give attackers a host where many sensitive sessions pass through.

Treat it as tier zero: restrict its administration, including the underlying operating system and cloud accounts, and patch quickly.
Remember the device: Microsoft warns that PAM cannot reliably mitigate a compromised workstation, because an attacker controlling the device can use the session while the user is logged on. Pair PSM with privileged access workstations.
Treat remote access vendors as tier-zero suppliers: in the BeyondTrust Breach 2024, a compromised API key for the Remote Support SaaS service could reset local application passwords on customer instances, and the US Treasury said an attacker used it to reach some of its workstations.
Keep credentials in the vault, not in scripts: in the Uber Breach 2022, the attacker claimed to have found a PowerShell script with hard-coded admin credentials; Uber did not confirm this, but credentials outside brokered paths defeat session controls entirely.
Patch edge brokers: remote access appliances are targets in their own right, as the Ivanti Connect Secure Exploitation 2024 showed when attackers harvested credentials from the appliance. See the Patch Management Guide.

Framework mapping

Control IDs below were checked against the NIST CSF 2.0 text, the SP 800-53 Rev. 5 OSCAL catalogue, the CIS Controls v8.1 safeguard list, a published ISO/IEC 27001:2022 Annex A list and the OWASP 2025 and 2026 lists. Mappings show where controls fit, not equivalence.

Requirement	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	OWASP
Restrict and broker privileged access	PR.AA-05	AC-6(5), AC-17(4)	8.2 Privileged access rights; 8.18 Use of privileged utility programs	5.4, 6.5	NHI5
Record and audit session content	PR.PS-04	AU-14, AU-14(3), AC-6(9)	8.15 Logging	8.2, 8.5, 8.8	ASI02
Monitor and review sessions	DE.CM-03, DE.AE-02	AU-6, AU-6(8), AC-2(12)	8.16 Monitoring activities	8.11	ASI10
Vendor and remote maintenance sessions	DE.CM-06, GV.SC-07	MA-4, MA-4(1), PS-7	5.19, 5.20 Supplier relationships and agreements	8.12	NHI3
Terminate and disconnect sessions	RS.MI-01	AC-12, SC-10, AC-17(9)	No single equivalent	No single equivalent	ASI10
Dual control for sensitive actions	PR.AA-05	AC-3(2)	8.2 Privileged access rights	5.4	ASI03
Protect, retain and govern recordings	PR.PS-04	AU-9(4), AU-11	5.28 Collection of evidence; 5.34 Privacy and protection of PII	8.3, 8.10	ASI02

Common failure patterns

Recordings kept but never reviewed: no indexing, no alerting and no one assigned to look.
Direct paths that bypass the gateway: administrators keep local accounts, direct RDP or SSH, or cloud console access outside the broker, so the riskiest work goes unrecorded.
Vendors with standing remote access: third parties connect through their own remote tools without brokering, approval or recording. See the Third-Party Access Guide.
Credentials users can still retrieve: if users can check out and copy passwords, they can use them outside brokered sessions. Prefer injection and rotate after checkout.
The broker treated as an ordinary server: slow patching and broad admin rights on the PAM or jump host, the one system that holds credentials for most privileged roles.
Machine and agent activity left out: PSM covers people at keyboards while service accounts and AI agents make privileged API calls unrecorded.
Destructive console actions without a second approver: one stolen administrator identity can issue mass wipes or deletions, as the Stryker Cyberattack 2026 illustrates.
Recording without privacy governance: no DPIA, no notice and unrestricted playback put the programme at legal risk.

Metrics that show progress

Pick measures you can produce monthly from broker, target and ticketing data. See the Identity Security Metrics Guide for how to present them.

Metric	What it shows	Target direction
Share of tier-zero and production privileged logons that went through the broker	Coverage and bypass risk	Up, towards 100%
Number of unexplained privileged logons (no matching brokered session)	Bypass paths and possible intrusions	Down
Share of high-risk sessions reviewed within the agreed window	Whether review actually happens	Up
Share of privileged sessions linked to a ticket or approved change	Change discipline	Up
Vendor sessions brokered, recorded and time-bound	Third-party exposure	Up
Accounts whose credentials users can view or check out	Credential exposure outside sessions	Down
AI agents and automations with logged tool calls and a tested kill switch	Non-human session oversight	Up
Days from critical broker or jump host patch release to deployment	Protection of the session platform	Down

Implementation roadmap

Phase	Actions	Outcome
First 30 days	Inventory privileged paths to tier-zero systems and vendor connections; record vendor and domain controller sessions; send session events to the SIEM; publish a notice and start the DPIA	Highest-risk sessions visible and lawful
Days 31 to 90	Route production servers, databases, management consoles and cloud consoles through the broker; enable credential injection and rotation; build the bypass, logging-disabled and account-creation detections; link sessions to tickets	Broad coverage with useful alerts
Days 91 to 180	Block direct paths with network and firewall rules; add command policies and dual control for destructive actions; risk-score and review sessions on a schedule; harden and monitor the broker as tier zero; set retention and playback controls	Bypass closed and review routine
After 180 days	Extend oversight to service accounts, pipelines and AI agents; report metrics monthly; test termination and revocation	Human and non-human privileged sessions governed alike

For how PSM fits the wider programme, see the PAM Maturity Model; for emergency accounts that must still work when the broker is down, see the Break-Glass Account Guide.

Practitioner checklist

Route access to tier-zero, production and management systems through brokered, recorded sessions.
Block direct access paths, and alert on any privileged logon the broker cannot explain.
Inject credentials rather than revealing them, and rotate after sessions or checkouts.
Broker, record and time-limit every vendor and third-party session, and review each one.
Alert on high-risk actions: account and role changes, logging disabled, bulk export, destructive commands.
Risk-score sessions, review the highest-risk ones and correlate all sessions with change tickets.
Apply command policies, idle termination and dual control for the most sensitive operations.
Harden, patch and monitor the PAM platform and jump hosts as tier-zero systems.
Log every tool call by automation and AI agents, require approval for high-impact actions and test the kill switch.
Govern recordings: notice to users, DPIA, restricted and logged playback, tamper-resistant storage and a retention schedule.