9.4 CyberArk Remote Access (Vendor PAM): Administering Third-Party Privileged Access

9.4 CyberArk Remote Access (Vendor PAM): Administering Third-Party Privileged Access

Quick Answer: CyberArk Remote Access — sold as Vendor PAM, and previously named Alero — is a SaaS service that gives external vendors privileged access to PAM - Self-Hosted without VPN clients, agents, or passwords. Vendors authenticate with native smartphone facial or fingerprint recognition through the CyberArk Mobile app and are provisioned just-in-time, so no third-party identity is ever created in the corporate directory. The only on-premises component is the Remote Access connector, a Docker container behind the customer firewall that makes outbound connections on port 443 and acts as both a SAML identity provider and an OpenLDAP server to provision vendor users into the PVWA and the Vault.

---

The Third-Party Access Problem

Every control built in the preceding chapters assumes the user is an employee with a directory identity, a managed workstation, and a Vault user object. External parties break all three assumptions. The traditional answer — issue the vendor a VPN account and an Active Directory identity — creates exactly the conditions defenders fear:

• A network foothold. A VPN drops the vendor onto the corporate network, so a compromised vendor session becomes a launchpad for lateral movement rather than a connection to one target.
• A standing identity. A directory account for a contractor is one nobody remembers to disable when the engagement ends, and one an attacker can phish and reuse.
• Administrative drag. Provisioning, credential distribution, and deprovisioning all require the internal identity team for people the organization does not employ.

Remote Access removes both the VPN foothold and the standing credential while preserving the isolation, recording, and audit properties PSM already provides.

---

Architecture: One Connector, All Secrets Retained On-Premises

The connector is the component exam items focus on, because it carries three distinct responsibilities at once:

1. Tunnel termination and re-encryption. When a remote user's authentication attempt reaches the connector, the initial encryption tunnel from the user's browser ends, and a new encrypted channel is opened directly to the PVWA. Between those two encrypted sessions the connector validates the session and user cookies and the PVWA and HTML5 Gateway certificates to confirm their authenticity.
2. Identity provisioning. The connector is configured as a SAML identity provider (IdP) and as an OpenLDAP server, which is how Remote Access-configured users are provisioned into the PVWA and the Vault without existing in corporate Active Directory.
3. Key custody. The connector holds the secure data keys and unique private certificates that validate the Remote Access end-to-end encryption chain. This is the architectural answer to the obvious objection about a SaaS broker: customer secrets remain in the customer's control and ownership, because the keys never leave the connector.

Because the connector only makes outbound connections on 443, no inbound firewall rule and no published endpoint is required — the same design principle that lets the Credential Provider and the EPM agent work through restrictive egress-only networks.

---

Administering Vendors

Day-to-day administration is a small set of repeatable operations:

• Invite the vendor. A vendor user is created and invited from the Remote Access tenant. They install the mobile app, enrol biometrics, and are ready — no corporate account, no password, no token.
• Assign a Role. Vendors are assigned a Role, which determines which applications and target systems they may reach. Access is scoped to specific systems rather than to a network segment.
• Provision just-in-time. Access is granted in real time for the duration of the work, and users are removed by policy when access is no longer required — without administrator intervention and without adding vendor identities to the directory service.
• Automate at scale. Remote Access exposes REST APIs for provisioning and managing users, performing bulk actions such as inviting many vendors at once or deactivating users automatically, and extracting data for audit and compliance reporting.

Post-Installation Tasks the Exam Expects

Three administrative steps appear repeatedly in CyberArk's guidance and map directly to operational failures:

The VendorLDAP item is the one most often examined, because it ties Remote Access back to the directory-mapping mechanics of section 12.1: the mapping determines both the Vault authorizations a vendor receives and the license bucket they consume, and mapping priority order applies to vendor users exactly as it does to employees.

---

How Remote Access Differs from Internal PSM Access

The last row is the point worth carrying into the exam: Remote Access changes how the vendor is identified and routed, not how the privileged session is controlled. Safes, platforms, connection components, recordings, dual control, and PTA detections all continue to apply to vendor sessions unchanged.

Naming note. Following CyberArk's acquisition by Palo Alto Networks, current product documentation is published under the Idira brand, and the same service appears as Idira Remote Access. Exam objectives and question stems still use the CyberArk names — Remote Access, Vendor PAM, and the legacy Alero — so recognize all of them as the same product.