Zero Trust Network Access: What and Why?

Legacy NAC and VPN for accessing corporate networks

ZTNA, NAC, SDP, RDP, VPN: Making sense of the remote access alphabet soup.

Zero Trust Security is a hot topic and with good reason. But what does it really mean in practice, when applied to solving remote access security challenges? In this post we provide an introduction on Zero Trust Security as it applies to Network Access (ZTNA) to help sort it out.

Before Zero Trust, a user or device was validated as having the correct credentials and the right to access the network. Once that step was complete the user or device had a wide open path to the network and resources. To mitigate the risk that a valid user would access systems they weren’t supposed to, role-based access control (or RBAC) was implemented. In theory this worked in conjunction with least-privileged access (the Principle of Least Privilege or PoLP) so that users were only granted access to the resources they needed and nothing more.

VPNs – Virtual Private Networks – are the ubiquitous technology for providing remote users access to enterprise resources. However, they are a network-layer technology, meaning that once the user is validated and logged in, the user’s device now has an open network connection to the corporate network. To mitigate the security risk of this open pipe, in addition to RBAC and PoLP, enterprises deploy Network Access Control (NAC) to verify first that a given device has the correct security posture – is the device allowed, independent of the user? Does the device have up to date AV running and passed a scan? And so forth.

Legacy NAC and VPN for accessing corporate networks

Once a user logged in to the VPN client, and his device passed the NAC security check, one of the most common resources accessed are remote desktops, most often with Remote Desktop Protocol or RDP. Although it is a proprietary Microsoft protocol, it does have cross-platform support for non-Windows devices.

That in essence is the technology stack most widely deployed in enterprises today to enable remote access: VPN clients where devices are validated by NACs. Users are granted access based on RBAC, PoLP to resources, including remote desktops over RDP.

Zero Trust Network Access (ZTNA) offers a simpler, more secure alternate vision. ZTNA turns the existing paradigm on its head – rather than open up a wide open pipe and then retroactively find ways to narrow it down, ZTNA assumes no device or user should be trusted, and no access granted by default except that explicitly required only for the duration required.

This is critical in a world where there is no fixed perimeter any more, but rather a software-defined perimeter (SDP).

TransientAccess takes ZTNA and SDP a step further, delivering true app-to-app connectivity over disposable networks. That is, there is never a device to device connection, nor is a user validated for anything more than what the user needs access to for the time the user is accessing it.

TransientAccess Zero Trust Network Access
TransientAccess Zero Trust Network Access

TransientX has a unique approach to Zero Trust Network Access (ZTNA):

  • A lightweight agent, creating a disposable virtual network connecting the local app to the enterprise resource on-prem or in the cloud.
  • A “Transient Virtual App Network”

This approach means TransientX can deliver on the promise of truly secure remote access for an organization’s workforce and business partners. Learn more in our intro video, contact us to get TransientAccess now or scroll below for further reading:

Further Reading:


TransientAccess Performance vs VPN

TransientAccess ZTNA performance vs Open VPN

Speed Matters.

While security is the prime consideration when moving from VPN to ZTNA, another important factor is performance. Not only do VPNs have a broad attack surface, they can impact dramatically network speeds for the endpoint. That’s why TransientAccess ZTNA’s performance vs traditional VPN clients like Open VPN is crucial.

Performance degradation in effect becomes a security issue, as the degraded user experience pushes users to avoid using VPNs and the already-limited security they provide. Shadow IT emerges and IT security teams get pressure to loosen controls.

Instead, with a Zero Trust Network Access (ZTNA) approach like TransientAccess, there’s no performance degradation. That’s in addition to the inherent security advantages of app to app security provided only when needed as needed on transient, disposable networks.

ZTNA Performance vs Open VPN

We’ve made a short video here showing the real-world performance hit of TransientAccess ZTNA vs a VPN client (in this example, Open VPN):

TransientAccess ZTNA Performance vs Open VPN

Whether remote access is via a mobile client or desktop, and whether it’s OpenVPN or a commercial VPN client, performance degradation will always be an issue. Contact us to compare for yourself.

File Access the Zero Trust Way

accessing Windows & Linux file shares securely without the VPN

Accessing Windows & Linux file shares securely without the VPN

Remote file access has always been a major use case for enterprise IT. In the 20th century (yes last century!) when VPNs were invented, they were used to solve pain points associated with offsite workers having to copy files from onsite computers to offsite. At the time floppy disks, CDs and USB sticks were the leading-edge technologies of choice.

Fast forward to today. Along with the dramatic increase in offsite workers, different file sharing problems have arisen: tracking changes, preventing data leaks, BYOD devices accessing corporate files etc. Companies like or focus on solving these problems. While they do solve certain pain points, there is a trade-off: corporate files/data must be moved to their cloud.

Windows and Linux file shares are still used in many enterprise workflows. But do they have a place in today’s modern zero trust solution architectures? After all, out of box, they have several issues that conflict with zero trust concepts:

1- VPN required: In order to facilitate access to file shares, a solution usually needs to have a VPN. Just like last century! VPN is an antonym for zero trust.

2- No MFA support: As a legacy technology, access to file shares is not secured by modern MF authentication mechanisms out of the box.

3- Access is permanent: Once the VPN connection is established, the access to the file share is permanent and untethered. A user will be able to access the files but so will ransomware if the PC is infected.

4 – BYOD/BYOPC and 3rd Party access issues: Allowing access from unmanaged devices, devices that are not corporate owned or managed e.g. BYOPC or contractors/affiliates and their devices, is a recipe for disaster. Data leak disasters, ransomware infections etc.

With TransientAccess, we implemented a true zero trust solution architecture for accessing Windows & Linux file shares, something unique in the market.

The basic solution architecture is outlined below. This architecture is not specific to file sharing and suitable for any other access scenario.

TransientAccess Solution Architecture

With TransientAccess, access to file shares is zero trust because:

1- No VPN is Required. While accessing the file share, even IP address or hostname of the file server are hidden to the users.

2- Built-in MFA Support. If an enterprise doesn’t have a modern IdP that supports MFA, TransientAccess has built-in support.

3- Access is Transient (i.e. Temporary). TransientX networks are application networks that are built and dissolved on demand, as opposed to VPNs. Even the data (i.e. files transferred to the accessing device) can be temporary if admins choose that configuration option.

4- BYOPC and 3rd-Party Friendly: Access to the network, shares and file data is temporary and not broad. Even if the PC is infected with a ransomware, shares wont be visible to the ransomware but only to the file manager.

5 – Zero Friction Solution: Security is delivered without compromising usability. TransientAccess also simplifies the use of file shares for end users as well as administrators. From IT teams’ perspective, the solution can be implemented in as little as 30 mins. From the end-user’s perspective, there is no need for advanced training on how to access file shares. It is as simple as logging into a web based portal and clicking on a link.

Below is a video of how it works from the end user’s perspective:

With TransientAccess, even a legacy use case like Windows file shares can be easily implemented in a zero trust way! Additional security comes hand-in-hand with enhanced usability. It’s simpler to use Windows file shares with TransientAccess.

Ready to try for yourself? Contact us.

Stop Ransomware Attacks at the Source.

Coveware report: Ransomware Attack Vectors

Secure RDP, Kill the VPN

Everyone knows by now that preventing ransomware is one of the top cybersecurity challenges. Yet most solutions focus on detection once the attack is underway. Wouldn’t it be better to stop ransomware attacks at the source?

In my previous post, I shared our insights on the attacks used against exposed RDP hosts and VPN servers. Most enterprises today are adapting to the new “work from home” reality through widespread deployment of VPNs and Remote Desktops (RDPs). However, as we outlined earlier, attackers exploit these solutions so extensively that it takes an average of 2 minutes for such a target to be attacked.

According to a recently-published report by Coveware, not surprisingly, RDP Compromise is the most common attack vector for ransomware with ~60% of the cases, followed by email phishing and software vulnerabilities.

Coveware report: Ransomware Attack Vectors
Fig. 1: Coveware report: Ransomware Attack Vectors

This data shows that Microsoft RDP is both one of most widely-used remote desktop solutions while also being the most common attack vector for ransomware.

ZTNA Stops Ransomware at its Source

In order to prevent public access, some companies use VPN solutions for further limiting access to RDP hosts but in reality this approach just shifts the attack vectors to VPN servers and cause additional problems. For full technical details, check out “Using RDP together with VPN/MFA gives a false sense of security”.

TransientAccess, on the other hand, offers a simple and highly effective Zero Trust Network Access (ZTNA) solution that alleviates all of the aforementioned problems and stops ransomware at its source because:

1- RDP hosts are NEVER accessible from the internet. Remote access is limited to authenticated users only.

2- Unlike VPNs, no device is joining a private network, hence other PCs in the private network are not visible.

3- Even if the device is infected with Ransomware, malware does not even see the hidden “disposable network” created by TransientAccess.

4- TransientAccess builds a network of applications, not devices. Hence it is natively segmented at the application level.

See the benefits of using TransientAccess to protect RDP Solutions

This short video shows how simple it is to use RDP with TransientAccess. The user doesn’t need to know how to run RDP client itself. Everything is handled automatically for them. Put another way, simple isn’t easy. We’ve done the hard work of making it simple:

Accessing an RDP session with TransientAccess

So why TransientAccess?


  • ZTNA architecture provides private access to RDP hosts without any publicly exposed elements
  • Even with unmanaged devices or infected machines, RDP sessions are protected against credential-stealing malware or ransomware.
  • Multi-Factor Authentication (MFA) support built-in.


  • Zero-friction implementation with the simplicity and elasticity of a cloud delivered service.
  • No user education. Users do not even need to know how to use an RDP client. Everything is just one click away. RDP with TransientAccess is EASIER to use than RDP alone.

Low TCO:

  • No need to buy a VPN and MFA service, it’s built in.
  • No need to buy expensive licenses for alternative remote desktop tools like Teamviewer or Logmein

Stop Ransomware Attacks at the Source. Secure RDP and kill the VPN with TransientAccess ZTNA.

Ready to try for yourself? Contact us and we’ll get you set up today.

Welcome to the Disposable Network

Kill the VPN

Kill the VPN

Corporate networks are for the most part built with legacy networking concepts we inherited from 30 years ago. Those networks were fixed i.e. there were a known set of computers connected to each other with cables, hubs and switches. A network-centric security model which takes such a fixed environment as “the inside” and protect against “outside” worked well because there were few if any mobile or remote workers or BYOD devices that required outsider access to internal assets. And when remote access was needed, a VPN was the “best of breed” approach to solve the problem and bring those remote devices into the corporate network. Remote workers no longer had to copy files between home and office or other locations.

The fundamental problem with that old model and the VPN is that “trust” is part of the core fabric of those old networks.

The cloud transformation and BYOD world we live in now have invalidated that old security model, and necessitated the “kill the VPN” approach. The fundamental problem with that old model and the VPN is that “trust” is part of the core fabric of those old networks. That old paradigm operated on the principle of inherent trust for assets in a network. However, today, that interconnected trusted system is the main reason for a company like Travelex to be infected so broadly and easily by Sodinokibi ransomware.This approach is based on the assumption that every device, connection, assets, application, and share inside the perimeter of the network is safe and that there is no possibility of an internal compromise. 30 years ago, this “flawed” assumption did not create too many problems as the network was relatively static and the era of data breaches had not yet occurred. However that interconnected trusted system is the main reason why a company like Travelex can be infected so easily by Sodinokibi ransomware. Trust and trusted assets mean that once a device is a part of the network, infected or not, It likely has full access to all the other resources such as computers, file shares, applications etc. This trust and connectivity enable those compromises and attacks to spread like wildfire throughout supposedly “secure” networks. The VPN’s we rely on basically become “pipes” that funnel trusted connections for infected assets deeper into the core network. The whole system and approach are a house of cards.

It is apparent that extending legacy networks to remote users through VPNs, especially to 3rd parties such as partners, affiliates, contractors significantly increases the risk of breach, and that the modern enterprise must think differently to adapt to the new digital space we live in.

An ideal solution should

  1. Allow only secure private access without exposing the resources to the Internet or over-expose unnecessary resources
  2. Be cloud-native and have a zero-trust architecture to operate in environments of cloud and post-cloud era
  3. Offer full visibility into users’ activities, enabling security teams to manage 3rd party risks and auditing requirements for compliance
  4. Be friction-free to implement and use

The new network: “Application Networks”

What if, instead of trying to connect devices to each other, we simply connect the apps on those devices each other? After all, every workflow involves a form of app to app communication and as long as this is achieved, we would not need to fall back to legacy methods of building networks. In doing this we could essentially eliminate the entire issue that faces trying to re-engineer those already failed network systems.

At TransientX, we have created a new way of networking by approaching networking requirements with an app-centric approach. After all, applications are the tools that people use to access data. Applications are the “storage media” that keep keys to back-end systems, or store enterprise data. Applications can reside anywhere, on users’ mobile phones, on partners laptops, in a container on a private data center or in a server in a public cloud. In truth, they are the “real endpoints” that need to network with each other.

Applications are the tools that people use to access data; they are the “storage media” that keep keys to back-end systems, or store enterprise data. In truth, they are the “real endpoints” that need to network with each other.

In this new paradigm, we treat applications as if they are devices, and build virtual networks of applications, instead of on the devices on which they reside. This way, when an Outlook application needs to connect to a private Exchange server, or an SSH client needs to connect to a private Linux server, a temporary virtual network over the internet is created, with Outlook and Exchange or SSH client and Linux Server being the only elements in the network. When they are done, the network is disposed. That connection and all its affiliated potential risks and threats are dynamically obliterated using our solution. The risk is effectively negated, period.

Applications can reside anywhere; on mobile devices, desktop PCs, Linux servers or under any network topology, behind firewalls, proxies, NATs etc. They can also use any protocol from IMAP to HTTPS, to communicate. Keeping all these complexities in mind, technically speaking, building an application network is not so straightforward. To be able to work with applications on any device, we introduced a new type of container called “micro-containers”. Our micro-containers are similar to docker containers but as the name implies, they are lighter. But unlike docker containers, they do not require application preparation, they support unmodified applications and work on unmodified devices, without requiring any admin or root privileges.

Our micro-containers communicate with each other, independent of the details and complexities of the underlying physical network topology. This is because they are armed with our custom TCP/IP stack that provides connectivity on any topology.

As a result of these innovations we are the only company which can offer “disposable networks” to address some of the most challenging problems that IT teams are facing, from zero trust transformation to 3rd party vendor risk management.

Disposable Networks and 3rd Party Access

Our application networks are built and destroyed with a very low computational cost, on demand, and hence are disposable. They are technically classified as overlay networks i.e. networks over networks and in our case, they are encrypted hidden overlay networks of apps built transparently over the internet. This new solution allows us to create a new network for every user in that each user has his/her own network of authorized apps, his/her own view of the same underlying physical network, isolated from other users.

While allowing 3rd party users to access private resources, IT teams can easily create a virtual network of apps and simply allow them to use their own private app network. In doing so, they would be solving the following challenges:

  1. 3rd party users are not brought into private networks

    Unlike when using VPNs, 3rd party users are not joining the private corporate networks for access. Instead, they are using a temporary app network built outside over the Internet. This way risk of breach and lateral movement is contained significantly.
  2. Resources are not exposed to the Internet

    Resources are not exposed to the Internet Application networks are private, and the applications being accessed are invisible. They cannot be accessed from the internet despite they could be accessed remotely by authorized users. Their pre-authenticated and ephemeral nature also effectively prevents DOS/DDOS attacks.
  3. Zero trust is in its fabric

    Application networks are built after authentication and authorization only. The set of resources or apps available in the network is user specific and can be dynamically adjusted by IT teams.

We are very excited about the potential for disposable network technology and that it’s core to our TransientAccess product.

You can learn more about it at: TransientAccess or Contact Us for a trial.

Using RDP together with VPN/MFA gives a false sense of security

The COVID19 pandemic has caught the world unprepared. Enterprises, from small businesses to Fortune 100 companies have been forced to enable “work from home” in literally a few days. Even companies which have already transformed most of their workflows to the cloud have to keep up with the unexpected demand for services which were NOT designed for the consumption by 100% of the available workforce.

A majority of companies on the other hand seem to be leveraging remote desktop services and VPN based solution architectures to allow their employees to access their workstations from home.

We can see this trend from data. According to Shodan ( there is about a 41% increase in RDP (Port 3389) services exposed to the Internet and about 33% increase in VPN servers exposed to the Internet.

Companies have been struggling to securely enable BYOD and remote employee access for over a decade now. In the time of crisis, use of decades old legacy solutions available to them, specifically RDP and VPN based ones, is an expected trend. However, this trend brings significant cybersecurity implications with it.

These solutions inherit all the cybersecurity problems associated with them from the last 20 years.


Brute force attacks are the attacks where the attackers try to find out the account credentials by trying all possible username and password combinations.

In our experiments, it took 2 minutes, on average, for an exposed RDP host to be a target of a brute force attack.

This literally means, as soon as the PC is booted, it is attacked in the background, even before the user starts working. In order to experiment, we created 15 different windows workstations publicly exposed through Amazon Cloud, Azure, Google Cloud or Verizon Wireless based public IP addresses. We then checked the windows security audit logs for failed login attempts. It took 2 minutes on average for the host to be discovered and attacked. Below is a screenshot of an audit log from one of the PCs. As soon as it is exposed, the attacker, possibly a bot, from Russia, probed it.

Today, password protection alone is as good as no protection. If a PC is exposed to the internet using windows RDP services without additional security measures, it should be assumed attacked and owned already. Because majority of passwords are weak and can be cracked instantly.

Even a relatively “strong” password with 7 letters containing numbers, upper and lower characters and special symbols can be cracked in 17 hrs.


Denial of service (DoS) attacks require attackers to consume available computing resources so that legitimate users cannot access the requested services. For the companies which use RDP as a solution for their day to day business operations, protection against DoS attacks is critical for their business continuity. Unfortunately, such a protection is not so straightforward to implement when legacy solutions like RDP or VPNs are used. Having most of the workforce on remote desktop services makes “the RDP” a critical component for any company; as critical as industrial control systems.

And keeping in mind the fact that most companies had only a few days to enable remote access, it is safe to assume that they are now vulnerable to a new type of ransomware attack: DoS against their business continuity

Attacking an unprotected host does not require too much from an attacker’s side: 1 mbs traffic is enough to disable a VPN or a Firewall or an RDP host!


In order to mitigate the cybersecurity risks, some companies couple their RDP based architectures with VPN and MFA (Multi-factor Authentication) solutions.

However, while they might mitigate certain attack vectors, the threats outlined above are not really addressed effectively.

Use of a VPN solution alone does not mitigate the risk of brute-force attacks or DoS service attacks but just moves attackers’ target from RDP host to the VPN server itself, potentially making the impact of a successful attack even worse because VPN servers become a single point of failure.

Use of a multi-factor authentication (MFA) solution mitigates the risk of brute-force attacks however when used to protect access to legacy solutions like VPNs and RDP services they do NOT address the fundamental problem: The authentication happens AFTER connections are established to the protected resources i.e. a VPN server. This unauthenticated connectivity makes the resources vulnerable to a wide range of attacks.

MFA solutions do not address the fundamental problem: The authentication happens AFTER connections are established to the protected resources i.e. a VPN server.

MFA does not protect against DoS attacks to VPN or RDP gateways. But in addition to DoS attacks, it offers no protection against direct exploitation attacks neither. VPN servers, just like RDP services, are direct targets of attackers. Bots are constantly scanning for exposed VPN servers to exploit vulnerabilities in them such as Palo Alto Networks (CVE-2019-1579), Fortinet (CVE-2018-13382CVE-2018-13383CVE-2018-13379), Pulse Secure (CVE-2019-11510CVE-2019-11508CVE-2019-11540CVE-2019-11543CVE-2019-11541CVE-2019-11542CVE-2019-11539CVE-2019-11538CVE-2019-11509), and Citrix (CVE-2019-19781):

Attackers have been hitting companies with these solutions, so that Airbus (using Palo Alto) and Travelex (using Pulse Secure) got breached recently through their exposed VPN servers.


TransientAccess and the disposable networking technology address all the security problems listed above while enabling remote desktop access services. A disposable network is a hidden and a temporary network built for each user, on demand. It is only exposed to the user for whom it is created and destroyed as soon as the user disconnects from it. More information on the technology can be found at: Disposable Networks. A video about TransientAccess and how it works can be found at


With TransientAccess, resources such as RDP hosts, are not exposed to the internet. Since they are not directly accessible, they are not vulnerable to DoS attacks. While orchestrating access requests, users are pre-authenticated by TransientX cloud first. After such an authentication, a hidden network with the remote host and the user’s device is built for the authenticated user allowing temporary remote access without internet exposure.


With TransientAccess, because access to RDP services happen in a hidden disposable network, nothing is exposed to the Internet and hence attackers cannot target the host. TransientAccess cloud employs modern authentication technologies such as integration with authentication providers like Okta or Azure AD. Administrators can also make use of MFA effectively, making the technology work for legacy solutions as well.


TransientAccess also provides endpoint data loss prevention (DLP) features specifically designed for unmanaged devices, making it a suitable BYOD solution without any dependency on MDM/MAMs. As part of our social responsibility, we are providing a no-cost subscription for it.