Frequently asked questions

Yes. All the communication between the SecTeer VulnDetect Agent or the SecTeer VulnDetect Graphical User Interface and SecTeer is made through port 443, and by using SSL protocol with 256-bit encryption.

Yes. All the communication between the SecTeer VulnDetect Agent or the SecTeer VulnDetect Graphical User Interface and SecTeer is made through port 443, and by using SSL protocol with 256-bit encryption.

Yes, VulnDetect uses BITS (Background Intelligent Transfer Service) from Microsoft and allows system administrators to download packages/updates with little impact on the network traffic and bandwidth.

VulnDetect can support an unlimited number of hosts through the multi-site and single-site structure.

The number of systems that can be scanned by SecTeer VulnDetect is dependent on the license that you have purchased from SecTeer. If you reach your license limit, deleting old systems from SecTeer VulnDetect will release the corresponding number of licenses. If you need additional licenses, please contact your SecTeer Sales Representative.

SecTeer VulnDetect is capable of scanning any Windows system, virtual machine and terminal server.

No. Due to its lightweight design, SecTeer VulnDetect is able to run in the most common Windows systems. For more detailed information, please refer to the system requirements for running the SecTeer VulnDetect Centralised Dashboard.

Using SecTeer VulnDetect, you have access to 2 different scan approaches:

• On-Demand Scanning
  From the VulnDetect GUI, you can easily create scan groups manually. The groups can then scan immediately.
• VulnDetect Agent – Single Mode
  The SecTeer VulnDetect Agent is a standalone executable file that can run as a local service. The agent can be configured to scan the system at regular intervals available under “configuration”.

Yes, all our packages rely on PowerShell 5.1, the default version on Windows 10 and Windows 11 and modern Windows Server releases. Our PowerShell scripts are digitally signed.

The VulnDetect TSPM packages are all PowerShell scripts. 
These scripts are all signed, and we recommend whitelisting/allowing all scripts that are signed by SecTeer VulnDetect.
SecTeer recommend using the built-in AllSigned security policy, as this improves your general security posture, if it is compatible with your other applications and management tools that use PowerShell.
If your 3rd party security solution doesn’t support whitelisting based on digitally signatures, you may be able to whitelist certain locations:
C:\Programs Files (x86)\SecTeer VulnDetect\
C:\ProgramData\SecTeer VulnDetect\
C:\Users\\AppData\Local\SecTeer VulnDetect\
The user path is based on Env:\LOCALAPPDATA, so it may differ from system to system though this is rare.
Note that scripts running in Program Files and ProgramData all run as SYSTEM.
Scripts running in the user’s folder always run with the users’ privileges, as reported by the operating system.
Most tasks are launched via the Windows Task Scheduler; however, some may be initiated directly via the agent.

We support a particular setting, ensuring that updates are distributed over a specific time interval. The default is a 7.5-hour window, during which all agents will conduct scheduled inspections also will run the “approved” update tasks. This window can be slightly expanded but ensures the evenest distribution should be aligned with the most common work hours. 

Actual inspections are randomly distributed over an interval of up to 10 hours, starting at the selected time.
Applicable updates will run shortly after an inspection is completed.

No. SecTeer VulnDetect does not scan removable or network drives such as USB sticks or other types of removable drives.

When an agent is installed on a host, it generates a unique token and saves it in the Windows Registry on that host. 

That unique token identifies that host to SecTeer VulnDetect.

When the agent is upgraded, it preserves the unique token and thus preserves its identity.

Although the login of concurrent sessions is possible, SecTeer VulnDetect is designed to allow only one session per account. If you wish to have several SecTeer VulnDetect accounts, please ask your SecTeer Sales Representative about an additional Admin license.

Yes.
For this to work, the MSI needs to be run with the following options:
msiexec.exe /quiet /i secteerSetup.msi WRAPPED_ARGUMENTS=”/options=group=groupname”
groupname must be replaced with the group’s full name in VulnDetect.

If the group name has spaces, then the options we recommend are the following:
msiexec.exe /quiet /i secteerSetup.msi WRAPPED_ARGUMENTS=”/options=group=””group name with spaces”””

Those are regular double quotes, first 1, then 2, and then 3 at the end.
Also, note that the agent will remain ungrouped if the named group does not exist.

The SecTeer VulnDetect Agent can be downloaded from your Dashboard under “configuration”.

No, this requires that the old Agent is uninstalled first.
When the agent is successfully installed, a unique auth-token is added to the registry.
This auth-token is associated with the supplied email and used to identify the agent when it communicates with the SecTeer VulnDetect backend servers. The auth-token will remain until the agent is uninstalled.
Upgrading will always preserve the existing auth-token.
In order to get a new auth-token, and associate the agent with a different account, the agent must be manually uninstalled, and then the admin can deploy the MSI, which will create a new auth-token that is associated with the correct account.

The most likely explanation is that an antivirus program uploaded the secteerSetup.msi file and a researcher at that antivirus company installed the program. You can safely hide the agent in the interface. It’s important to note that the MSI file you have received is keyed to your account, so anyone who receives it can run it, and the resulting agent will also be keyed to your account. There is no security issue here because the agent doesn’t receive any significant information from the server.

When an agent is uninstalled, the unique token is deleted from the Windows Registry and cannot be recovered. 

If the agent is installed again on that host, it generates a new unique token and a new identity.

This shows up on the Hosts page as multiple instances of the same host.

All results are counted for all the duplicate hosts while they are present on the Hosts page.

We strive to provide accurate and useful information about the current state of each product, e.g., if it is “OK” or “Insecure” and what type of update we are dealing with, i.e., “Plain/Bugfix Update” or “Security Update”. Unfortunately, not all vendors provide this information, although other parties may have published security information at some point in the past.

Therefore “Untracked” doesn’t mean that we don’t detect the application. It means based on our in-house research, the security and release information from the vendor is not considered reliable.

In general, all beta/alpha/insiders/canary/nightly and other pre-release channels for software is considered *Untracked* as most vendors don’t provide information for this kind of release.

VulnDetect supports updating per-user based applications, including Cisco Webex, Microsoft PowerToys, Microsoft Visual Studio Code, Opera, Vivaldi, WinSCP and many more, however, there are a few, yet significant apps, like Firefox and Chrome, which don’t provide installers that support silent upgrade of user based installations nor do they support converting / upgrading user based installations to system based ones, which typically have better support for centralized management and silent options. 

We recommend that you uninstall the user based installations of Firefox and Chrome, if you wish to manage the upgrade, otherwise you have to rely on the built-in updater or the user to update it.

Yes, that is possible by going to Groups -> Edit Selected Group -> Custom Inspect & Update Schedule

“Work-in-Progress” means that the Approval cannot be automated by the Automate New Approvals setting, it requires a manual confirmation.

Packages are initially marked as WIP to indicate that they are new and may not yet be fully tested in production environments.
Despite the package updating with no issues on our test hosts, we will still mark it WiP and will review the updates after a period of time to check if the patch is working as expected to eventually removing the “Work-in-Progress” flag.
We strongly recommend testing new packages on a few (test) systems before updating a large number of hosts.

There is no fixed timeline for removing the WIP flag.
It is based on customer feedback or lack there off and the success rate we see in our logs. It also depends on the frequency of releases and the install base in general. And, we also take a lot longer for e.g. licensed software and VPN software, than we do for well known software that is freely available and easy to test in an ordinary desktop environment.

The most common reason is that the host is offline or hibernates. 
Other times, the package may be waiting for the Windows Installer database, it will wait for up to two hours, before abandoning the update. The update will not be retried until the next regular or manual inspection.
In rare cases an installer may hang, this can be due to local configuration issues, conflicts or unexpected dialogues (which usually will be invisible to the user).
The package will time out after 59 minutes.
The update will not be retried until the next regular or manual inspection.
Also, only one package task can run, despite the Applying state in Package Activities, the other package tasks will wait for the first package to complete or exit due to one of the above mentioned timeouts.
The order in Package Activity is not indicative of the order in which multiple packages are attempted.

Note: In rare cases the Windows Installer database is locked for a very long time, this may be due to other installers running including Windows Updates. In some cases a restart of the host may be required to free the Windows Installer database again.

In some cases, due to the update requiring a restart, we specify that the app requires an “app restart” under “Patching activity.” 

The applications that have the “App Restart Required” are still vulnerable / running the old version, until the app or system has been restarted.

While we do support host restarts, we don’t support restarting individual applications. Host restarts offer a consistent, reliable way to apply updates across the entire system.

Restarting apps individually would require complex, tailored logic for each application, something that adds risk and more frequent user interaction. To keep things safe and maintainable, we avoid app-specific restarts and rely on full system reboots instead.

Microsoft 365 Apps (Office) are updated differently from most other applications. They are not installed or patched as traditional packages. Instead, updates are handled by Microsoft’s built-in Office Click-to-Run service.

When an update is triggered, we instruct Click-to-Run to check with Microsoft for available updates and apply them if they exist. In most cases, Click-to-Run will download and prepare the updates promptly. However, the final application of those updates is fully controlled by Microsoft.

Because Office applications – most notably Outlook – are often running continuously, updates cannot always be applied completely while the system is in use. This can leave a device in a temporary or partially updated state until the system is restarted. A reboot resolves this in most cases, though not all.

For this reason, we strongly recommend that customers implement a reboot policy to reboot Windows devices a few days after each monthly Patch Tuesday. This ensures that pending updates for Windows, Microsoft 365 Apps, and third-party software can be fully applied.

Microsoft Copilot is marked as “Untracked” because Microsoft does not publish sufficiently detailed and reliable release information identifying which vulnerabilities are fixed in each Copilot release, including vulnerabilities affecting the underlying Microsoft Edge components used to render Copilot content.

Previously, Copilot releases closely followed the Microsoft Edge release cadence, allowing the Edge version to serve as a useful indicator of Copilot’s security state. Since late July 2026, the Copilot and Edge release cycles no longer appear to be closely synchronized. Consequently, the installed Copilot version cannot be reliably mapped to a particular Edge security release or its resolved vulnerabilities.

Without an authoritative mapping or suitable release notes from Microsoft, VulnDetect cannot reliably determine the security state of Copilot. The product therefore remains marked as “Untracked”.

VulnDetect offers the option ‘Automatically group new hosts based on their Active Directory groups.’ which will mirror the pre-configured groups present on customers AD. 
The option is only available to System Administrators. To group existing hosts you will have to make a request to support@secteer.com

The integration of Azure Active Directory (AAD) with SecTeer VulnDetect enables automatic grouping of hosts based on their Active Directory (AD) groups. This feature mirrors the pre-configured groups in the customer’s AD, ensuring that hosts in VulnDetect are organized according to the existing directory structure. The integration syncs every 3 hours, keeping group assignments up to date as changes occur in Active Directory, with the option to trigger a manual sync when needed.

The difference between Hidden and Dormant hosts, is that Hidden hosts are based on an admin action, whereas Dormant is 100% automated.
This also means that a Dormant host that becomes active, will be revived automatically, whereas a Hidden host requires an active admin action. 
Whenever possible, rely on Dormant hosts, it‘s much easier.
All hosts will stop counting license wise after 45 days, if they are inactive. Hidden hosts will stop counting license wise within 24 hours.

Note: Per policy we accept temporarily exceeding the license count without additional charges when e.g. replacing a large number of devices, despite the old devices remaining Dormant for 45 days.

Yes, in most cases this will not be an issue. However, you should ensure that the applicability rules for packages applied via other means accept newer versions of the applications, so the applications aren’t downgraded by your deployment tool.

There are two different ways of hiding results.
Using the Ignore Rules feature located in the Configuration page here: 
https://corporate.vulndetect.com/#/configuration

Or by deploying a customizable registry file using Custom Software:
https://vulndetect.org/topic/2388/registry-files-and-the-custom-software-feature

The ignore feature in the UI and the one in the registry are fundamentally different as the purpose of ignoring things using the registry, is to adhere to local privacy regulations, ignore backup drives, and let developers compile apps that may be detected by the agent.

This means that the registry ignore feature completely hides the underlying data from SecTeer VulnDetect, whereas the feature in the UI just hides data we already have stored.

1) Set a string value in the registry, under HKLM\Software\WOW6432Node\SecTeer\Agent
2) The value name is overrideGroup, the value itself is the name of the group that the agent should be in
3) The agent service must be restarted for the agent to read the value and submit it to the backend
4) The backend looks up the group by name, case-insensitive, and if found, it moves the agent to that group
If no group is found with the given name, then the setting has no effect
If multiple groups are found that match the name, then one will be chosen. Which group is chosen is arbitrary, but consistent (it is the first one, ordered by their uuid)
5) The overrideGroup setting persists in the registry, so if the agent is later manually moved to a different group, then it will revert back to the overrideGroup the next time the agent service starts, unless the registry setting is cleared. This will be altered in a future agent release, so that the agent itself will clear the setting, after sending it to the backend.

Do let us know if you have further questions or experience issues. Bear in mind, that this is a new feature, currently only used by one other customer.