What is Privileged Remote Access?
Privileged Remote Access (PRA) refers to controlled remote access to administrative systems or protocols. Zscaler PRA can provide authorized users with browser-based RDP, SSH, or VNC connections to configured privileged consoles.
The problem: Maintenance access becomes permanent network access
External technicians often receive VPN accounts, jump host access or shared credentials. Although the desired access only affects one system, technically a larger network area can be reached.
In addition, there is a lack of clear runtimes, device requirements and a consistent handover between system owner, service management and security. Secure access therefore needs more than MFA.
A manufacturer is supposed to maintain a Linux appliance for two hours. Instead of providing general VPN access, identity, target system, protocol, time window and responsible owner are modeled as a limited access process.
Privileged access needs multiple control points
The technical connection is only one part of the overall process.
Identity
Uniquely authenticate and assign internal and external administrators.
Objective
Define specific servers, jump hosts, or desktops as authorized resources.
Protocol
RDP, SSH or VNC and the required functions are deliberately limited.
Policy
Combine role, device, time, context, and, if necessary, sharing.
Meeting
Start, end, termination and permitted interaction operationally control.
Lifecycle
Control onboarding, change, expiration and revocation of access in a comprehensible way.
What needs to be checked before making a decision?
- Who needs access and on whose behalf?
- To what specific goal and via which protocol?
- What are the device and identity requirements?
- Is a time slot or additional release required?
- What session and audit features are licensed?
- How are emergency access and withdrawal tested?
Definition: PRA does not automatically replace full privileged access management with password vault, credential rotation, or session recording. The supported range of functions must be checked.
How SourcingBlox designs privileged access
We start with roles, goals and operational risk instead of a blanket approach.
Access Discovery
Record administrators, service providers, target systems, protocols and existing access paths.
Policy Pilot
Test a maintenance case with identity, device, time window, release, and fallback path.
Lifecycle & Governance
Establish onboarding/offboarding, reviews, emergency access, and audit handoffs.
Typical mistakes
- Introduce PRA as a mere VPN replacement without a role model.
- Define goals and protocols too broadly.
- Manage external identities without an expiration date.
- PAM features that are not part of the selected edition.
Frequently Asked Questions
Does the external user need a client?
Zscaler describes PRA as browser-based access for supported privileged consoles. The specific suitability and configuration must be checked for each use case.
Is PRA the same as PAM?
No. PRA focuses on controlled remote access. PAM can also include credential vaulting, rotation, and other governance functions.
Can access be limited in time?
Time and release requirements should be part of the policy and lifecycle design; the concrete technical implementation depends on the scope of the product.
Make privileged remote access secure and auditable.
We connect the target system, identity, protocol, release and lifecycle.
Related Content
Sources and further information
Protocols, session functions, scope of licenses and portal options must be checked against the current ZPA documentation before implementation.