Privileged Session Manager changes privileged administration from a credential-distribution problem into a controlled-session problem. Instead of handing an administrator a high-impact password and hoping it is used only for the approved task, CyberArk can broker the connection through PSM. The user receives access to the target, while the credential can remain hidden and the session can produce evidence for monitoring, review, and investigation.
That model remains central to the current CyberArk Defender – PAM knowledge area and to the broader family of CyberArk certifications. PSM is valuable precisely because it sits in the live path to critical systems, so understanding connection components, network dependencies, recording, and troubleshooting is as important as understanding the security benefit.
PSM is a brokered access path, not merely a jump server
A conventional jump server centralizes administration but often still requires the user to know, paste, or cache a privileged credential. PSM is designed to broker the connection using a credential controlled by the PAM system. That creates a stronger separation between the person authorized to perform a task and the secret that authenticates the privileged account.
The distinction matters for revocation. If a user never learns the target password, removing authorization in PAM can stop future access without requiring the organization to prove that the user deleted a copied credential. Rotation can then change the secret independently of the administrator’s workflow.
PSM also creates a policy enforcement point. The organization can control which connection method is available for a given account, require the session to traverse approved infrastructure, and associate activity with the requesting identity even when multiple people use the same target-side administrative account.
Connection components translate policy into an actual protocol session
A PSM connection component defines how the broker reaches a target and launches the appropriate client experience. Different systems require different protocols and connection logic. An RDP-based Windows administration workflow, an SSH-based Unix workflow, and a database administration session are not interchangeable simply because they all use privileged credentials.
When a session fails, confirm that the selected connection component actually matches the target, account platform, and installed client requirements. A successful credential verification by CPM does not prove that PSM can launch the session. CPM and PSM can use different network paths and different protocol dependencies.
Custom connection components deserve lifecycle management. If an organization adds a client executable, browser automation, script, or special command line, document the supported version and test it after endpoint hardening or application upgrades. Otherwise a routine software change on the PSM server can unexpectedly break privileged access.
Follow the session path from request to target
The user begins by authenticating to the PAM service and selecting an account or target for which session access is permitted. Policy determines whether the user can use the account and which connection methods are available. PSM then receives the session request and obtains the secret or token it needs through the protected PAM flow rather than exposing it to the user’s desktop.
PSM launches the configured connection toward the target and acts as the controlled intermediary. The target sees the managed privileged identity, while PAM retains the relationship to the named human or service that requested the session. This correlation is critical when shared administrative accounts still exist for technical reasons.
During or after the session, monitoring data and recordings can provide evidence of what happened. The exact controls depend on product configuration and connection type, but the architectural outcome is consistent: access, credential custody, and evidence collection are linked in one governed workflow.
Session recording is sensitive security evidence
Recordings can be extremely valuable during incident response, audit, and dispute resolution because they show activity that target logs may not represent clearly. They can also contain highly sensitive material: customer records, configuration secrets displayed on screen, command output, database contents, or other privileged information.
Treat recordings as controlled evidence rather than ordinary media files. Limit who can view them, define retention according to legal and operational requirements, monitor access to the recordings themselves, and ensure storage capacity is planned for the expected session volume. An over-retained recording archive can become a high-value data repository of its own.
Correlate session evidence with target logs. PSM shows the brokered user workflow, while operating-system, application, database, and network logs show what the target processed. When both are time-synchronized, investigators can distinguish an administrator’s actions from background service activity more confidently.
Troubleshoot PSM by separating five failure layers
The first layer is authorization: can the user see and use the account, and is the required connection method permitted? The second is session infrastructure: is the PSM service healthy and able to receive the request? The third is connection-component execution: can the configured client or protocol launch correctly?
The fourth layer is network reachability from PSM to the target. This is different from reachability from the user’s workstation and different again from CPM’s password-management path. Firewalls, proxies, routing, DNS, certificates, or load balancers can affect only one of these paths. The fifth layer is target authentication and authorization: the account may be valid but denied an interactive logon or remote protocol.
Classifying the failure before changing settings prevents broad exceptions. If RDP is blocked from PSM to a server, retrieving the password and connecting directly does not fix the PAM architecture; it bypasses it. The correct repair is to restore the intended brokered path or use an approved emergency-access procedure.
Design availability around the fact that PSM is in the production path
When policy requires all high-risk access to go through PSM, a PSM outage becomes an administrative-access outage. Capacity, redundancy, maintenance windows, certificate renewal, and client software updates therefore need production discipline. Test whether planned maintenance can drain or redirect sessions without forcing users to bypass PAM.
Network placement should reflect the targets PSM must reach. A single session host with unrestricted connectivity everywhere is operationally simple but creates a broad security zone. Larger environments may use multiple session components or segmentation patterns so the broker can reach required targets without becoming a universal transit point.
Monitor the function, not only the server. A synthetic session that proves the broker can authenticate and reach a representative target provides more useful evidence than a simple “service is running” check. Availability means an authorized user can complete the intended privileged task through the controlled path.
Keep the user experience aligned with least privilege
Good PAM design does not make every privileged task equally difficult. Routine approved operations should have a predictable connection workflow, while higher-risk actions can require additional approval or stronger controls. If legitimate administration is consistently slower than informal workarounds, pressure to bypass the platform will grow.
At the same time, convenience should not turn into password retrieval by default. Session brokering is most valuable when users can perform required work without learning the secret. Retrieval should be reserved for cases where the target or emergency process genuinely requires it and where additional evidence and post-use rotation are appropriate.
This model complements zero-trust network access: the network path can be constrained while PAM governs the privileged identity and the administrative session. Neither control replaces the other. Together they reduce the assumption that being on the right network is enough to justify powerful access.
Do not troubleshoot by weakening the control model
Common shortcuts—sharing a privileged password, allowing direct target access “temporarily,” disabling recording, or giving users broad Safe rights—can make a ticket disappear while creating a larger audit and security problem. Record the reason for any emergency bypass, scope it narrowly, and remove it as part of incident closure.
For persistent failures, build a reproducible test case: user identity, Safe and account, connection component, PSM node, target, protocol, timestamp, error point, and relevant logs. This makes it possible to compare a working and failing path without guessing. It also reveals when only one target type, one subnet, or one connection component is affected.
The strongest PSM environments make the secure path the normal path. Administrators know where to launch sessions, troubleshooting owners understand the layered dependencies, recordings are protected, and availability is engineered so emergency work does not depend on bypassing the very controls intended to protect privileged access.
Protect the PSM host as privileged infrastructure
Because PSM brokers high-impact sessions, the PSM operating system and its administrative interfaces deserve stronger treatment than an ordinary application server. Restrict interactive administration, control which teams can modify connection components, keep software dependencies patched, and monitor changes to the session-broker configuration. An attacker who can alter a trusted connection component may be able to undermine the controls that users expect the broker to enforce.
Separate maintenance access from the sessions PSM brokers for other teams. Administrators who support PSM should use named, auditable identities and should not rely on the same privileged accounts being protected by the service unless the recovery path is explicitly designed for that dependency. This avoids a circular situation in which fixing PSM requires a session through the failed PSM path itself.
PSM’s security value comes from separating privileged use from privileged knowledge. The user receives a governed session, the Vault retains custody of the credential, the target receives the authorized connection, and the organization retains evidence. Maintaining that model requires disciplined connection design, network reachability, recording protection, and troubleshooting that repairs the brokered path instead of routing around it.