Room for improvement is more on the policies offered for DLP.  Netskope detects certain data or contents, but there are some limitations on how we can customize those policies for DLP.

In the next release, I hope we can see more use cases for mobile devices, not just for laptops or servers but also for key features that will be available on mobile devices or smartphones.

We faced certain issues with China users as it can be rather challenging for them due to the presence of Great Firewall. This is a major drawback, and it poses a significant issue for all our users in China.

There could be an ability to access one server from another when we have console access to the first server. Netskope Private Access does not provide this feature.

Currently, there is no IPv6 support for Netskope Private Access. It is on the downline, and enhancement requests have been made.

The ability to provide more security around agentless access has room for improvement. 

This is the only thing that needs improvement is the agentless Landing Portal.

Netskope Private Access only supports TCP and UDP ports and does not support ICMP or ping. It makes troubleshooting and testing connectivity difficult, as ping is a common and simple way.

We want to add two options. The first option is ICMP. The second option is live monitoring. In general, we saw a lot of missing logs. We want to troubleshoot to find problems on a larger scale. It can improve the logging system and the reporting system.

Netskope needs to provide some kind of data protection strategy as well because, currently, if you connect through private access, we don't have any data protection policies or implementation. 

So, Netskope needs to be improved, along with the resources assessment. This should have some kind of data control. Like, if anyone is transferring the data from the internal server to another, then it should be monitored.

The main challenge we are facing across various Trust Network Access (TNA) technologies, including Netskope, is their inability to support broadcast applications or those relying on broadcasting protocols. These applications, such as security cameras and voice systems, require server-initiated connections, which TNA solutions, including Zero Trust Network Access (ZTNA), often do not handle well. This limitation becomes particularly problematic when dealing with legacy applications that have been in use for decades, featuring encryption, hashing, and other custom protocols that don't align with modern standards like HTTP version two.

Netskope Private Access needs improvement in the on-premises check. When users are out of the network, it's self-explanatory that they will be connected to their private app via the network. The area for improvement is that Netskope Private Access currently supports only one DNS mapping for an IP address. 

This means that when users are on-premises, Netskope needs to turn off its Private Access tunnel since users can access the private apps locally. 

Currently, Netskope Private Access allows mapping only one DNS server. If a user uses a secondary DNS on-premises, Netskope fails to disconnect them. This is an issue that needs to be addressed.

The solution needs to develop faster features. Its interoperability feature is not working. It takes six months to one year for any product to implement the improvements. However, the process should be faster to implement the changes quickly. 

The major problem that we are facing is if we deploy Netskope on the server level or if we get a new server in the EMEA factor, it will affect all the machines. Recently, this has caused us to fail some reviews.

Apart from that, sometimes Netskope isn't reachable from the client end. This happens when we sometimes try to reach them regarding an issue and troubleshooting request.

In the future, I would like to see a dashboard monitoring feature. If there are any human vulnerabilities, we will be able to see and monitor the kind of traffic with thought information, attacks, or requirements. 

The product is not easy to use. The product needs to be made easier to use.

In terms of market leadership, it seems to be lagging behind. Zscaler has taken over the ownership because they've launched multiple solutions, whereas Netskope hasn't launched as much. 

So, in my opinion, Netskope may require some R&D effort from the development team to stay on track. When they partnered with Meta, their graph didn't improve much. 

Zscaler is leading because of diversity and better security. In my conversations with customers across the globe, especially in the APAC, Dubai, Singapore, and Indian regions, Zscaler is more commonly used than Netskope in larger organizations. Netskope is good for smaller organizations due to its cost-effectiveness, but for larger ones, the customers prefer everything in a single place.

Netskope seems to be lagging behind, especially after its partnership with Meta.

The cost has room for improvement. There are cheaper options available.

I would like to see them go down the path of including SD-WAN. Currently, they don't do SD-WAN. If they could somehow natively do that inside of the platform, that would be amazing. I don't know if they're going to do it, but it would be amazing if they do.