In case you missed the third webinar of our new Inside Netskope series—where Netskope experts show you how we protect our users, applications, and data using our own cloud-based architecture—a recording and recap of our recent session on Netskope Client Enforcement for Secure Access to SaaS Applications can be found below. Feel free to comment and continue the discussion!
Watch on-demand 
Q: Is it Multi-Cloud/Multi-Vendor compatible or is integration available?
A: We are able to apply a Network ACL within those sign on policies within Okta. If it supports applying an ACL or you can define a custom SAML 2.0 application, yes it is compatible.
Q: How about for Contractors who are not issued a laptop but need to access Okta?
A: We do not block the initial access to Okta because there are some use cases where we may have former employees or even new hires that need to access Workday to set up some information.
Once those persons are onboarded, we require them to use the Netskope client connected to the corporate tenant. This allows us to drive adoption of Netskope client usage for the organization. Arguments have been made that some of the applications we use enforcement on are not needed. The reason for doing so with applications that are questionable is again to drive enforcement and a friendly reminder to turn on the client.
Q: If the employee ends up at the client download screen, is the client already linked to the Netskope tenant/user identity or are those required to be inputted as part of the installation?
A: Part of the prerequisites for implementing Netskope Client Enforcement is to have users provisioned in the tenant and the Netskope Client installed. Once the user is provisioned in the tenant and Netskope Client Enforcement is configured, there is no need to have the user input additional information. The user is redirected to the Netskope page (Client checker) for Client installation and activation.
Q: Does this work with SWG only or do you need to be licensed for CASB as well?
A: It works regardless of whether you are a CASB or SWG customer. We take the Netskope IP addresses, whether it's an egress or a range, and we apply that to accessing the application within Okta or any identity provider. We do have one off cases that we can't apply the IP address range to restrictions within the SaaS app itself, so we control access to the SaaS app using MFA through the identity provider.
Q: Do you have Device Classification rules that are also a factor in access?
A: We apply those device classification rules when we are accessing the SaaS applications itself. Not necessarily going into the identity provider for that initial access. Of course, that's also dependent on the identity provider since there's specific access policies you can apply within Google or even Okta.
Q: Does Netskope recognize the IP Chain in the Okta pipeline?
A: In the context of Okta and Netskope Client Enforcement, it is important for Okta to recognize or know about the IP address from which a remote machine originates for sign-on policy enforcement. Netskope's recognition of the IP Chain in the Okta pipeline is not relevant.
Q: Does this work with Azure Entra?
A: I believe Azure Entra supports a SAML 2.0 application and specific content access policies that would allow us to use Azure Entra.
Q: Will this allow the client machine to communicate using the SaaS apps own presented certificate?
A: Yes. In essence, we are applying a network access list to those individual applications within Okta—or any one of your identity providers—that allow for application of a network IP access list.
Q: How do you handle users that have name changes, which changes their email address?
A: It depends on whether the email address has been synced with the Netskope Client. If so, the identity can then get synced to the end user by reinstalling the Netskope Client.
Q: If you select all of the apps in the SSO panel for enforcement, can you still have client self-service available in the SSO?
A: Absolutely. As long as you create a SAML 2.0 application as mentioned in the article and allow access to it then that self-service option is available to all users once assigned.
Some responses above contain roadmap items. These are intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Netskope’s products remains at the sole discretion of Netskope.