There are three aspects of co-existence to discuss. The gateway deployment co-existence, the end user workflow co-existence, and the administrative management co-existence. We will walk through all three of these aspects.

The use cases for nZTA are fairly complete. nZTA will meet the needs of most users for resource access. It permits automatic split-tunneling access to many different hosted or cloud-based resources. Not just HTTP(s) based apps, but also different common protocols, like RDP and Terminal Services. If needed, it can give access to subnets or common networks. And all access is permitted, or denied, on granular, real-time posture assessment. That said, there are edge cases, sometimes vital ones, which nZTA has issues meeting. And this is where ICS comes into play, with gateway deployment co-existence.

The most common use case for ICS, which nZTA does not meet, is the basic “Contractor” access. This assumes that the admin is not able (or willing) to install a connection client on the contractor’s device. Since nZTA requires the end user have a certificate installed on the device, to complete a mTLS handshake before connecting to any gateway for resource access, this limits the ability to deploy nZTA where the user must access via a clientless access method. 

neurons for zero trust network access diagram

In the above diagram, the Secure Application Access is only permitted after an mTLS handshake occurs. This ensures that nZTA Gateways remain hidden from general public access, even though they exist on the public internet. They act as a default deny firewall, only permitting communications from an end user who can complete the mTLS handshake. This use case, of course, cannot be done via a clientless connection. So, for this use case, the admin may need to stand up an ICS gateway next to an nZTA gateway to permit this type of access.

The second common use case is during a transition between ICS to nZTA. This requires the end user workflow co-existence.  The admin may not want to transition 100% of users to 100% of nZTA access overnight. They may look to isolate some resources or users and bring them into the nZTA deployment slowly. This requires that not only can the Ivanti client make connections to both nZTA and ICS gateways, but it also requires these connections are able to co-exists at the same time, actively. Meaning that a user can connect to both types of deployments at the same time and access resources through both deployments at the same time, without taking any action on the user side. This ensures that an nZTA deployment can be brought online at the speed defined by the admin, with full flexibility in how and when the transition happens.

Lastly, the administrative co-existence. Using the Neurons for Secure Access (nSA) platform, the administrator can bring ICS appliances into their deployment alongside the nZTA deployment. nSA provides the same aspects of gateway visibility and management that nZTA provides, from the same administrative interface. This allows the full deployment to be managed from a single point, regardless of which kind of appliances are being deployed, or where they are being deployed.