Whether you want to search for solutions or ask a question, dip into spaces designed for those who are new to our products or watch videos to help you learn the basics. You'll find a lot of content and our experts are here every day. Netskope is ready for anything!
Latest Expert Videos
Connect With
Netskope
Our team is making a lot of improvements. Most of these improvements won't happen overnight, but we are making progress and would benefit greatly from your feedback. Whether or not you asked a question in the Community, please take a few minutes to reach out to the Community team by direct message to @Rohit or send an email to community@netskope.com
Netskope Global Technical Success (GTS)Netskope NPA Partner Tenant Access Configuration Netskope Cloud Version - 133 ObjectiveThis document provides a clear walkthrough of Netskope Partner Tenant Access and explains how users can connect to private apps in partner tenants without unenrolling from their primary tenant. It also covers the purpose of the feature, the supported platforms, and how this capability simplifies access for customers working across multiple partner environments. DefinitionsPrimary tenant: This is the customer’s main Netskope tenant where the user is enrolled. All SWG and other core security policies for that user are managed here.Partner tenant: This is the Netskope tenant owned by a partner organization. This tenant hosts the private applications the user needs to access and also holds the relevant access policies for those apps.Partner access: This is the feature that allows a user enrolled in their primary tenant to access private apps hosted in a partner tenant without switching enrollment. Prerequisite:Windows from Client R125 onward and macOS from Client R127 onward Partner tenant must have Forward SAML Proxy configured for primary tenant users (Security Cloud Platform > Forward Proxy > SAML - Forward Proxy) Partner tenant must have the primary tenant users synced (Security Cloud Platform > Netskope Client> Users) ConfigurationFor easy understanding we will use two Netskope tenants in this example.primary.goskope.com as the primary tenantpartner.goskope.com as the partner tenant In the primary tenant primary.goskope.com I have a user installed Netskope client and the requirement is to let this user access an NPA application that is hosted in the partner tenant partner.goskope.com. So in short below is what we need to configure. Primary.goskope.com Partner.goskope.com Open a support ticket and request Netskope to activate the NPA Partner Access feature Configure SAML Forward Proxy so the user from the primary tenant can authenticate with partner tenant. After the flag activation configure the Partner Tenant Access option under Client configuration in the UI Sync the user into the partner tenant so the user identity is available for NPA policy configuration. Configure a real time policy for the user to access the private applications. Login to primary.goskope.comNavigate to Security Cloud Platform > Netskope Client > Client Configuration and select the client configuration. Under the Private App segment option enable Partner Tenant Access and enter the partner name and tenant URL. Login to partner.goskope.comSync the user ( eg: primary@M365x38097171.onmicrosoft.com) to the partner tenant. The user should appear under Security Cloud Platform > Netskope Client > Users. Configure SAML Forward Proxy in the partner tenant to authenticate the user from the primary tenant (Security Cloud Platform > Forward Proxy > SAML Forward Proxy) Use the guides below for referencehttps://docs.netskope.com/en/saml-setings-for-authenticationhttps://docs.netskope.com/en/saml-authentication-with-entra-id Note: If a SAML Forward Proxy configuration already exists in the partner tenant there is no need to create a new setup. Add the user to the required application in Azure or Okta to enable access. Configure a real time protection policy for the user so they can access the private application. User Experience :Partner Access Tenant becomes visible to the user from the primary tenant. The user can pick the partner tenant they want to connect their NPA tunnel to. Once the user selects the partner tenant the client prompts them to authenticate using the identity method configured on that partner tenant. After the authentication completes successfully ,the partner tenant access is established and the NPA connection comes up. The client configuration shows the connection status along with the tenant name and the user email. Terms and ConditionsAll documented information undergoes testing and verification to ensure accuracy. In the future, it is possible that the application's functionality may be altered by the vendor. If any such changes are brought to our attention, we will promptly update the documentation to reflect them. NotesThis article is authored by Netskope Global Technical Success (GTS). For any further inquiries related to this article, please contact Netskope GTS by submitting a support case with 'Case Type – How To Questions'.
As 2025 is coming to an end, it’s a good time to reflect on your security landscape with our latest 2025 Netskope Recap Dashboard!The dashboard helps you perform an end-of-year reflection on your organization’s security posture. Topics covered include:Threat Protection Cloud App Usage Monitoring Policy Effectiveness Assessment Data Movement Investigation 2026 Call to ActionUse this dashboard to recognize your achievements and areas for improvement, ensuring you’re better prepared for the evolving security challenges in 2026! Please note that the 13-month data retention is required to view the full results in this dashboard. If you’re interested in extending your retention period, please reach out to your Netskope account representative.
Many of our clients have been in contact with Netskope with regards to the news of the latest Salesforce breaches involving Gainsight 3rd party plugin, what should be the main takeaways to our users regarding this breach in particular and how to protect against similar attacks. For the latest and most accurate news on this, the most trustworthy and relevant news sources should be Gainsight incident advisory on their community site and the related Salesforce security advisory. Whilst the news are still very fresh and the investigation is ongoing at the time of writing this, we have a few interesting intelligence pieces available which are worth of note at this point:This hack is related to the earlier Salesloft drift attackThe tactics used by the attackers are similar to what was witnessed during the Salesloft Drift breach in the summer of 2025. According to bleepingcomputer.com, the same threat actor behind the Drift hacks has claimed responsibility for the hack. Netskope’s analysis and advice from those events remain relevant.Gainsight and Salesforce are taking responsibility and handling the response to this hack. They have been in contact with parties who they have identified as compromised. The impact of the attack seems to be more limited than the last time. This suggests Salesforce has put more proactive controls in place such as anomaly detection to defend against this type of breaches since.Customers should vet and harden the 3rd party integrations they rely onWith regards to supply chain security in general and 3rd party app monitoring, our advice is in line with the Mandiant researchers currently investigating this breach. Vet through your 3rd party integrations regularly, harden controls where you can. It should not be reasonable to expect a major vendor integration with a good reputation such as Gainsight to cause most users concern in their integration vetting process. Gainsight and Salesforce are major companies with extensive security resources to protect their deployments and customer trust. With such high profile apps, it’s fair to assume the vendors have the primary responsibility for protecting your trust and ensuring their integrations are built to fail safely. Ensuring even the best-protected apps are configured and used safely still remains your company’s responsibility. You can double-check your integrations are configured according to vendor guidelines. Document any discrepancies you find. Lean towards stricter restrictions than the baseline in your deployment when possible. E.g. disable a permission from a service account if it’s asked by an integration feature you are not using. Keep your vendors accountable for the privileges and trust you entitle them for, ensure they explain and document reasons for every permission they require and support integration hardening options available within the platforms. Rather than worrying about headline-breaking breaches of major platforms such as Gainsight or Salesloft, it’s a good idea for the platform user to focus their 3rd party app vetting process on less-known and -monitored integrations, such as unknown or custom plugins only deployed in your environment. Salesforce incident monitoring will be able to catch misuse of large scale such as the Salesloft or Gainsight supply chain breaches. But a custom plugin deployed by an intern of your company 3 years ago which leaked its access credentials will stay under their radar. You need to maintain the security hygiene of those integrations yourself. Restricting 3rd party integration access with IP address allowlisting remains an effective defenseSince the attackers were using VPN’s for exfiltration, restricting IP Addresses used by the integrations has proven to be an effective countermeasure against these attacks just like they were during the Salesloft attacks. The IP Address restrictions for Salesforce integrations are done on the profile level. You can use the “Login IP Ranges” -setting for the Salesforce Profile which is attached to the user who has onboarded the 3rd party application to ensure the integration can only be used from trusted IP addresses. Netskope SSPM has visibility to the profile objects and can alert you for any profiles capable of using API’s without IP Address range restrictions set up. For example, you can use the following NGL in the Inventory Search to hunt for user-created API-capable user profiles without IP Login Restrictions configured to them:Salesforce Profile should-have Permissions with-any-element [ ( PermissionName = "PermissionsApiEnabled" and isEnabled = true ) ] and loginIpRanges not-exists and custom = trueAs always, you can customize and refine the queries to your own needs. For another example for vetting the login IP Ranges, check out the Salesforce Rule template called ‘[Template] Privileged profiles login access lack IP range restrictions’ - where we show an example on implementing a blocklist for profiles where IP Range restrictions should be put in place. Netskope SSPM has over 800 similar built-in detections and allows you to build more workflows for this and other types of vetting and anomaly alerting. And we are constantly expanding. Netskope SSPM with its flexibility and underlying graph-model is well suited to help you audit for this type of weaknesses in your configurations.
The best method for communicating a support request with Netskope is via the Netskope Support Portal which is available to Netskope customers.
If you or a member of your team does not have access, please email support@netskope.com and we?ll get you set up.
You can always reach out to our support team via email at support@netskope.com. To best handle your request, please provide the following information:
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK