Why OESIS Detects a Product but Only Patches Some of Its Variants

Summary

A product supported by OESIS Framework may exist in multiple variants — different architectures, installer types, distribution channels, or release lines. Each variant is mapped to its own OESIS signature, and only some of those signatures support patching. As a result, OESIS may detect every variant of a product but only be able to patch some of them.

This article explains how OESIS represents product variants, the known categories of variants that cannot be patched and why, how to identify which variant is installed, and how to request patching support for a variant that is not covered by the categories below.

How OESIS represents products and signatures

In the OESIS product database (the analog/server/products.json file shipped with OESIS), a product (for example, Microsoft Teams) is an umbrella for one or more signatures. A signature identifies one specific variant of the product — for example, a specific OS architecture (x86, x64, ARM64), installer technology (EXE, MSI), installation scope (per-machine, per-user), distribution channel (desktop installer vs. Microsoft Store), or major release line (e.g., Java 7 vs. Java 8).

Patching support is defined per signature, not per product (the support_3rd_party_patch attribute in products.json). Two installations of "the same product" can therefore match different signatures — and only one of them may be patchable.

Example — Microsoft Teams on Windows. OESIS supports three signatures for Teams: Microsoft Teams classic, Microsoft Teams work or school, and Microsoft Teams (the new Teams app distributed through the Microsoft Store). The first two support patching; the Microsoft Store variant does not. An installation of the Store variant is detected but not patchable, while an installation of Teams work or school can be patched normally.

Why some signatures cannot be patched

1. Microsoft Store (UWP) applications

OESIS Framework does not support patching UWP applications distributed through the Microsoft Store. These signatures are detection-only. Remediation options:

• Allow the Microsoft Store to update the application, or

• Migrate to the vendor's desktop-installer variant of the same product, which OESIS can patch.

Examples of Microsoft Store / UWP signatures that are detection-only:

The current status of the applications listed above is based on the data available as of July 28, 2026.

2. Variants discontinued by the vendor

Some signatures cover a variant that the vendor no longer ships — a retired architecture, an abandoned installer format, or a discontinued edition. Because no current installer exists for that variant, there is nothing OESIS can patch to: the newest version available for that variant is already the last version that will ever exist.

These signatures remain in the database so that OESIS can still detect the (now outdated) software and report it, which is valuable for vulnerability assessment. Remediation is migration to the vendor's supported variant.

Examples:

The current status of the applications listed above is based on the data available as of July 28, 2026.

3. End-of-life release lines

Many vendors maintain several release lines of a product in parallel and eventually stop servicing the older lines. OESIS tracks major release lines as separate signatures. OESIS can continue to support patching a release line as long as the vendor still maintains installers for it; once the vendor stops maintaining installers for that line, OESIS must stop patching support and the signature becomes detection-only. Moving to a serviced line is an upgrade/migration decision (potentially with licensing, compatibility, or workflow implications), which OESIS does not perform automatically as a patch.

Remediation: plan a migration to a release line that the vendor still services; OESIS can patch the installation from then on.

Examples of end-of-life or superseded lines that are detection-only:

The current status of the applications listed above is based on the data available as of July 28, 2026.

OESIS provides the IsDefunct method to programmatically identify end-of-life (defunct) products, so integrations can detect when an installed release line has reached end of life and plan the migration to a supported line. See the OESIS V4 method documentation for details.

How to identify which variant is installed

There are several ways to identify which variant of a product is installed:

1. Signature ID and name. OESIS detection results (e.g., DetectProducts) include the matched signature ID and name. The signature name usually encodes the variant — for example, Mozilla Firefox UWP vs. Mozilla Firefox x64, or Microsoft Teams vs. Microsoft Teams work or school.

2. Uninstall registry hive. Inspect the product's installation metadata via OESIS product-information methods (e.g., GetProductInfo): an uninstall entry under HKEY_LOCAL_MACHINE indicates a per-machine install, while HKEY_CURRENT_USER indicates a per-user install.

3. Uninstall string. An msiexec-based uninstall string indicates an MSI install; a path to an uninstaller executable indicates an EXE-based install; Microsoft Store apps do not appear under the classic uninstall keys at all.

Variants not covered by the categories above

The categories above cover the structural reasons a variant cannot be patched (Microsoft Store distribution, discontinued variants, and end-of-life release lines). For any other product variant where you need patching, please raise a request with OPSWAT Support. Patching coverage is continuously expanded, and support for additional variants is prioritized based on customer demand — customer requests are the primary driver for adding new patchable signatures.

When raising a request, include the product name, the matched signature ID/name from the detection result, and the OS and architecture; this allows the request to be scoped to the exact variant you need.