Why CPAM Needs Port 22
Imprivata Privileged Access Security (PAS) uses Secure Shell (SSH) protocol on port 22 as the primary communication protocol between the server, Gatekeepers, and Gateways. This communication enables secure, reliable, and audited remote access to customer systems without requiring inbound firewall exceptions.
Because many organizations perform security reviews before deploying their PAS server, firewall and security teams often ask why outbound SSH access is required.
This document explains the architectural reasons behind this requirement and the impact of blocking or replacing SSH with other protocols.
High-Level Explanation
PAS establishes encrypted outbound connections from each Gatekeeper to the PAS server. These connections carry the traffic required for remote support sessions, access, auditing, and session management.
SSH was selected as the primary transport protocol because it provides several capabilities that are essential to PAS:
-
Strong industry-standard encryption for all session traffic.
-
Reliable long-lived connections for interactive remote sessions.
-
Efficient tunneling of multiple application protocols.
-
Broad compatibility with enterprise firewalls and security appliances.
-
Consistent performance for interactive services such as RDP, SSH, file transfer, and other supported protocols.
Unlike traditional SSH servers, the PAS server is not used to provide shell access to customer systems. Instead, SSH functions as a secure transport mechanism between trusted PAS components.
Although HTTP/S is widely allowed through enterprise firewalls, it is not the primary transport protocol for PAS.
When SSH cannot be used, PAS can fall back to HTTP or HTTPS communication. These fallback methods exist to maximize connectivity in restrictive environments, but they introduce additional protocol overhead because SSH traffic must be encapsulated inside HTTP or HTTPS.
This additional encapsulation can result in:
-
Higher latency.
-
Increased bandwidth consumption.
-
Reduced performance during remote sessions.
-
Lower scalability in environments with many concurrent vendor connections.
For these reasons, HTTP and HTTPS are designed as fallback communication methods rather than the preferred operating mode.
If port 22 is unavailable between the Gatekeeper and the PAS server, the server attempts to communicate using its secondary and tertiary transport methods.
While remote access may still function, organizations should expect reduced performance compared to native SSH communication. Depending on the network environment, users may experience slower session responsiveness, particularly during high-bandwidth or latency-sensitive activities.
Blocking port 22 does not improve the security of PAS. Instead, it prevents the platform from using its most efficient communication method.
Security Considerations
Allowing SSH over port 22 for PAS does not expose your internal network in the same way as opening an inbound SSH service.
Several architectural characteristics reduce the security risk:
-
Outbound communication only: Gatekeepers initiate outbound connections to the PAS server. Organizations do not need to create inbound firewall rules that allow unsolicited external SSH connections into their networks.
-
Encrypted communication: All communication between the Gatekeeper and the PAS server is encrypted using SSH, protecting session traffic while it traverses untrusted networks.
-
Controlled access: The SSH connection transports only authorized PAS traffic. Vendors can access only the hosts, services, and applications that administrators explicitly authorize within PAS. The communication channel does not provide unrestricted network or shell access.
-
Auditing and access controls: Every vendor session is authenticated, authorized, and audited according to the policies configured in the server. Session activity remains subject to the same approval workflows, access restrictions, and auditing capabilities regardless of the transport protocol.
Frequently Asked Questions
HTTPS is supported as a fallback communication method. SSH remains the preferred transport because it provides better performance, lower protocol overhead, and greater reliability for long-running remote sessions.
No.PAS requires outbound connections initiated by the Gatekeeper. It does not require inbound SSH access from the Internet to your internal systems.
PAS is designed to use the standard SSH port. Using non-standard SSH ports may reduce compatibility with enterprise firewalls and network security appliances, potentially causing more connections to fall back to HTTP or HTTPS communication.
Yes. Organizations should allow outbound TCP port 22 only to the PAS server endpoints used by their deployment. This follows standard enterprise firewall practices while allowing PAS to operate as designed.
In many environments, PAS can establish communication using fallback protocols. However, Imprivata recommends allowing outbound TCP port 22 whenever possible to achieve the best performance, scalability, and user experience.