In case you missed the latest webinar in our 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 protecting lost/stolen managed devices with Netskope Client can be found below. Feel free to comment and continue the discussion!
Watch on-demand 
Q: Can a client be flagged as stolen via API?
A: The client cannot be directly flagged as stolen via API, but you can use APIs to move users or devices between groups. This will have to be done within the Groups section and not with the client directly.
Q: How to setup monitoring and tracking of stolen devices? Also, can we pinpoint the location of the lost/stolen device?
A: If the device comes back online and connects back to the tenant, we can get all of the location data (wifi connected to, geographic location, etc.). Regarding how to setup monitoring and tracking, the presentation covers quite a few use cases on how to get started.
Q: Is there a way we can restrict full internet from the machine?
A: Absolutely! The real-time policy can block everything except for talking back to the Netskope SWG.
Q: How would this work with BYOD running the NS client?
A: Great question! Here at Netskope, we prefer not to put the Netskope Client on personal devices. There would definitely be some challenges because if it's BYOD and all you have is the Netskope Client, you can have policies differentiating between managed and unmanaged devices. You can have controls for BYOD devices but they might not be optimal. Of course if your users are willing to have the Netskope Client installed on their devices, it's up to them, but it's more effective with managed devices.
Q: We have Netskope and would like the ability to quickly shut down access for a specific user account, is there an API method, or way we should do this?
A: A few methods come to mind. We have different ways to shut down access for specific user accounts. We can do this with the API method or programmatically doing it with the help of automation tools.
Q: Does the fail close still allow it to communicate with Netskope?
A: Yes it does. If fail close is looking for a connection back to the Netskope Gateway, once that connection is back up, "fail close" would resolve.
Q: Wouldn't the real time protection block policy also block those users activity on other devices as well? Can this be configured for specific devices only, rather than the user?
A: What we can do in this situation is that once a device is stolen, we can add the user to the stolen device group. After that device is added, you can use the other tools to make changes to the device. For example, you can push a file to a particular location and make a new device classification called "Stolen Devices" in your device classification page. Here you can have it as "if this particular file is located in the temporary folder, then this device gets marked as stolen" and then the user can be removed from the stolen device group. The user group works first but you'll have to supplement it with some other tool so this drops and another control kicks in.
Q: What happens when a user gets a new device, this would also be blocked if they are part of the AD group?
A: Netskope works off of the user information as far as how you are enrolled, so it depends on what your status is and how quickly you replace the device.
Q: If this real-time policy is created by user group, would it block all internet traffic if a legit user logged in from a non-stolen device?
A: The controls are applied at user level first—then after the controls are moved to a device level, the user may be released from the ‘Stolen devices’ group but until that, any device the user uses or logs in from is going to be disallowed.
Q: If the laptop isn't connected to internet, then the client and steering configurations won't update right at that time—the things won't work as expected. At that time, is there any suggestion?
A: Internet connection is required for any tool, including the Netskope Client, to make changes. The tips for basic security hygiene, featured on the last slide, would help here.
Q: How do we manage exceptions to allow MDM tools (Intune, Jamf, Kandji, ...) to have the device communicating with the service? So that other actions can be sent (remote wipe, ...). Is it manually or taken into account with the policy?
A: As we had discussed in the second or third slide, steering configurations will help. Once you add these exceptions, like Intune, into the steering configuration, this traffic will not be touched by the Netskope Client—even if the Client is programmed to block all traffic. Since this is an exception, "Intune, Jamf, or Kandji" can talk to your devices and issue the remote device wipe as usual so make sure you have these exceptions created in steering configuration to avoid the Client tampering with these tools.
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.