How does Nexthink ensure the security and reliability of its Collector updates?

This documentation provides a detailed overview of the security features and update strategies of Nexthink Collector, highlighting our commitment to providing a secure and reliable product for our customers.

Monolithic update approach

Nexthink Collector stands out in its approach to updates. Unlike some security solutions, which frequently release updates for different parts of their agents, Nexthink Collector uses a monolithic update process. This means that all the components of Collector are bundled together and shipped as a single installer. This cohesive update approach has several advantages:

• Comprehensive testing: By updating all components together, Nexthink ensures that all components are compatible with one another. This reduces the risk of issues arising from mismatches between different parts of the software. Collector is tested in its entirety as a final product, which is what Nexthink administrators later deploy. This method allows Nexthink to maintain high reliability and stability across the platform.

• Predictable validation: Monolithic updates allow Nexthink to predictably validate agent updates between multiple popular versions of Collector, instead of only the two most recent versions. This broader validation ensures that our updates maintain compatibility and performance across a wider range of environments.

While Nexthink Collector is updated monolithically, the browser extension is not included in the installer. However, since the browser extension does not communicate with kernel components, it cannot cause critical system failures, such as blue screens.

Infinity Collector automatic updates

Nexthink takes a structured approach to updates, balancing the need for security and stability with operational flexibility. Unlike solutions such as CrowdStrike, which may release updates frequently, Nexthink Collector updates are aligned with major releases, typically every six weeks.

Nexthink users have the following options for managing these updates:

• Disable automatic updates: Nexthink administrators can choose to disable automatic updates entirely and manage the update process independently through their software distribution systems.

• Pilot group testing: Administrators can define a pilot group that will receive updates first. If no specific group is defined, Nexthink randomly selects 10% of endpoints to receive updates. This pilot group starts receiving updates two days after a new major Collector version is released, with the remaining endpoints receiving updates 16 days after.

These options provide Nexthink administrators with flexibility and control. Additionally, Nexthink administrators can pause the automated update process for up to four weeks to accommodate periods when updates are not desired, such as during frozen zones. For more details on managing Collector updates, refer to the Collector management documentation.

Collector Crash Guard

To further safeguard the systems of Nexthink customers, Nexthink Collector includes a feature known as Crash Guard which determines whether a Windows system crashed after a Collector update. If a system experiences three crashes in a row, Collector automatically disables itself. This proactive measure helps prevent devices from entering a blue screen loop, a scenario problematic for some other solutions, like CrowdStrike.

For additional information on Crash Guard, refer to the Collector Overview documentation.

V6 on-premises setups

Nexthink V6 on-premises setups also include an auto-update mechanism similar to the Infinity platform. Customers can define pilot groups to test updates first, ensuring a controlled rollout process. For more information on updating Collector in V6 setups, refer to the Nexthink V6 documentation.

Quality and security assurance

Nexthink is committed to maintaining the highest standards of quality and security. Every major change to Nexthink Collector undergoes rigorous penetration testing by an independent company, using both black-box and white-box methods. These tests focus on common vectors for privilege escalation, including weak permissions for files, folders and named pipes, unquoted service paths, DLL hijacking, and more.