One contractor, one incident:
Imagine you’ve turned your office into a fortress: biometric scanners at the entrance, armed guards, and surveillance cameras in every corner. You invest in secure architecture, segmentation, SIEM, SOC—the best of the best.
Yet, every day, you grant critical infrastructure access to external contractors—essentially handing them the keys to the front door and allowing them to roam without clear restrictions because "they need to get the job done."
Sounds absurd?
VPN, the “Trojan Horse” of the digital era
The traditional remote access model is built on trust. We create an account, open a VPN tunnel, and assume the situation is under control.
Of course, access can be strictly limited: network segmentation, firewall rules, and IP whitelisting. You can apply GPOs, EDR, or XDR to minimize the attack surface and connect the SOC for monitoring. All of this is correct and necessary.
However, these mechanisms operate primarily in a “detect and respond” model. The firewall limits the route. EDR flags suspicious activity. SIEM creates an incident. SOC can isolate the host.
But the key question lies deeper: What exactly is happening inside that privileged session?
If an administrator with legitimate rights makes changes, the system perceives it as a permitted action—until it violates a specific rule. Intent and context remain outside of network control. An incident may be logged, but the action has already been performed.
This is why even in a well-segmented environment, a blind spot emerges—not in the network, but at the moment of privileged command execution.
There is another issue rarely discussed openly: attribution.
Contractors often use separate admin accounts and, sometimes, shared or service accounts. When an incident occurs, a complex investigation begins: Who exactly made the change? A specific engineer? Their colleague? An automated script? Or an attacker using compromised credentials?
Without full session transparency, the answer becomes mere guesswork.
VPN itself isn't the problem. The problem is a model where access is granted upfront, and deep control only appears after the event. The real risk lies not in the network tunnel, but in the lack of manageability within it.
How CyberArk closes the main security gap
As we’ve established, the problem with the classic access model isn't the VPN itself; it’s the lack of a managed intermediary between the user and the critical system.
Modern architecture from CyberArk changes exactly this point. It doesn't just "improve the VPN"—it removes direct trust between the contractor and the internal resource. Every remote access instance passes through a full Privileged Access Management (PAM) circuit—including verification, session brokering, control, and auditing.
The contractor no longer connects to the network directly. They don't receive a VPN client, and they don't know the password to the target system. Access occurs through a controlled gateway that acts as a proxy between the user and the resource. The password is stored in the PAM vault and injected automatically, without disclosure. It cannot be recorded, forwarded, or reused.
This is a fundamentally different model: the user receives a specific, controlled session, not the "network."
The second key element is Just-in-Time (JIT) access. Instead of permanent accounts, access is activated only for the duration of the approved task. Once the session ends, privileges are automatically revoked, and credentials can be rotated if necessary. Temporary access stops being “forever temporary.”
From technology to access model: What changes for the oranization
In practical terms, this means much more than just another remote access tool. It changes the interaction model with external users entirely.
In the classic approach, a company expands its own perimeter every time it connects a new contractor. Every VPN account logically becomes part of the internal network: routes appear, firewall exceptions are made, permanent accounts are created, and privileges accumulate. Over time, these access points number in dozens or hundreds, and managing them becomes an operational burden. Deleting forgotten accounts, rotating passwords, verifying permissions, and investigating actions—all of this is reactive work that begins after the risk has already risen.
The controlled session brokering model works differently. The perimeter no longer expands for every new user. Instead, it remains stable, and all external connections pass through a single managed point of control. Architecturally, this is closer to Zero Trust principles: no access is considered trusted simply because the user authenticated successfully. Trust is re-verified every time through the context, policies, and limitations of the specific session.
Consequently, not only does security improve, but so does process manageability. Shared accounts disappear, attribution becomes simple, and auditing shifts from a complex investigation to a routine session log review. Access doesn't accumulate for years or get "forgotten" after projects end, and doesnʼt create hidden paths into the infrastructure. Each connection has a clear purpose, a limited lifetime, and a transparent history.
Frictionless security: How daily team operations change
In a traditional scenario, every new contractor undergoes a separate process: account creation, access approvals, opening segments, sharing passwords, subsequent rotation, and verifying that access remains active after work is completed. For administrators, this is constant manual operational work; for the security team, it involves endless checks and audits.
Controlled Remote Access within CyberArk simplifies these processes. A contractor connects via a browser, passes biometric authentication, selects the approved system, and immediately enters a ready session without password exchanges or additional configurations. Access is granted automatically according to policy and is just as automatically revoked upon completion. For the team, this means fewer manual operations, fewer exceptions, and fewer human errors.
For the SOC and audit teams, the difference is even more noticeable. Instead of collecting logs from various sources and reconstructing events post-factum, a full session history is already available: who connected, where exactly, when, and what they did. Incident investigations are reduced from hours to minutes, and a significant portion of manual checks becomes unnecessary.
Ultimately, controlled access becomes a way to reduce chaos around privileged accounts rather than an extra layer of complexity. Security stops conflicting with operational convenience—they begin to work together.
What’s under the hood?
So this model doesn’t look like an abstract concept, let’s see how it is implemented at the infrastructure level.
In your environment, Remote Access is built not as another VPN server, but as a separate controlled circuit between the external user and internal resources. Instead of a direct network tunnel, a session brokering point is created through which all connections pass. Effectively, it is a gateway that accepts user authentication, checks access policies, and only then establishes a connection to the target system on its own behalf.
From the contractor’s side, it looks remarkably simple: they open a web portal, authenticate via a mobile app with multi-factor confirmation (where app access is further protected by device biometrics), and see a list of systems they are authorized to access.
No VPN clients, routes to the internal network, or local credentials appear on their device. All interaction occurs at the level of an isolated session—RDP, SSH, or web access—proxied through the gateway.