Vendor Access Bypasses PSM Through a Jump Host
A global retailer has 300 third-party vendors and 80 internal administrators. CyberArk PSM handles about 40 concurrent sessions. Vendors access 600 servers: 200 Windows servers over RDP, 150 Linux servers over SSH, 100 network devices over SSH or Telnet, and 150 servers through a shared jump host. Audit finds 15 vendors connecting directly with shared local accounts, bypassing PSM entirely. Some PSM sessions time out after 10 minutes of inactivity, and vendors complain that long-running tasks fail. The network devices use shared enable passwords that are rotated manually once a year. The CISO wants all vendor access recorded, no direct access, and no shared accounts. The vendors say they need access within 24 hours of a request, and the security team has two engineers.
1. How would you close the direct-access bypass without stopping vendor support?
Read the worked answer
Closing the bypass is a network and identity problem before it is a PSM problem. First, remove the vendors' ability to reach the servers directly: firewall rules should allow vendor traffic only to the PSM appliances, and the jump host should be reachable only from PSM. If a vendor can still connect directly, the policy is not enforced. Second, eliminate shared local accounts by creating named vendor identities and mapping them to target accounts in PSM. The vendor authenticates to PSM, and PSM supplies the target credential, so the vendor never knows the server password.
For the 150 servers currently reached through the shared jump host, configure PSM to proxy the connection or use PSM as the jump point itself, so the session is recorded end to end. For network devices, use PSM connection components for SSH and Telnet and store the enable password in the safe.
To avoid breaking support, run a short parallel period: onboard the vendor, test the PSM path, then remove the direct firewall rule. The 24-hour request requirement can be met with a pre-approved onboarding workflow, not with standing direct access.
2. Why do PSM sessions time out after 10 minutes, and how should the team address the vendor complaints without disabling recording?
Read the worked answer
The 10-minute timeout is a configured session or idle timeout, not a recording failure. It may be set globally or per platform, and it is usually intended to release idle sessions and reduce risk. For vendors running long jobs, a fixed 10-minute idle timeout is too aggressive, but disabling recording or extending the timeout indefinitely is the wrong fix.
The team should review the connection component and platform settings for idle timeout, maximum session duration, and keepalive behavior. Set a longer idle timeout for the specific vendor platforms and use keepalive or heartbeats for long-running tasks. If the task is truly long-running and does not need an interactive session, move it to a scheduled job or a privileged task automation rather than keeping an interactive session open.
The compromise is to keep recording, keep a maximum session duration, and set the idle timeout based on the actual work pattern. Document the exception per vendor platform and monitor disconnected sessions. Vendors should also be told what the timeout is, so they do not assume the system is broken.
3. The 100 network devices use shared enable passwords rotated manually once a year. What is the target state, and what obstacles should the team expect?
Read the worked answer
The target state is that each network device has a unique enable password stored in the PAM safe, rotated automatically by CPM on a defined schedule, and accessed only through PSM. Administrators and vendors authenticate as themselves, and PSM injects the device credential. No human knows the enable password, and every session is recorded.
The obstacles are device support and change control. Some older network devices may not support the protocol or account model that CPM needs for automated rotation, and some vendors may have a single enable account that cannot be renamed. The team should inventory device platforms, test CPM rotation on a pilot group, and define a manual rotation procedure with evidence for devices that cannot be automated. For devices that truly cannot rotate, use PSM-only access and a compensating control such as network segmentation and session recording.
A second obstacle is operational ownership: network devices are often managed by a different team than servers. The rollout needs that team to own the platform configuration and the rotation schedule, or the passwords will drift back to manual.