Software Identification (SWID) Tag

A SWID tag is not the software itself. It is a companion metadata file. The publisher's installer usually places it in a fixed location at install time. An inventory tool can read it without running the software or fully parsing it.

Each tag records the publisher, the product identity (name, version, edition, and target architecture or platform), a unique tag ID that is separate from the product name, and the tag type. The tag type shows whether the file belongs to a primary install, a patch, a supplemental component, or a pre-install corpus. The sample below shows the shape of a tag in the ISO/IEC 19770-2 schema, with placeholder values:

<SoftwareIdentity xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd" name="Example Editor" version="5.2.1" versionScheme="multipartnumeric" tagId="example-editor-5-2-1">
  <Entity name="Example Corp" regid="example.com" role="softwareCreator"/>
</SoftwareIdentity>

Before SWID, each IT asset management tool used its own heuristics to recognize installed software. It matched executable names, registry keys, or folder structures. These vary by release and by vendor, so the method is fragile. One product can appear under several names across an estate. A small rename or repackaging can make a tool miscount licenses or miss a vulnerable version.

ISO/IEC 19770-2 gives the industry a common source of truth. The publisher states what was installed, in a standard format that every tool reads the same way. Inventory and license reconciliation then stop depending on guesswork.

A tag travels from the publisher's installer to the inventory record in four steps:

1. 1

   Publish

   The publisher's installer writes the tag next to the product at install time.

2. 2

   Read

   An inventory tool reads the XML file without running the software.

3. 3

   Match

   The product, edition, and version are compared with purchased rights and with known-vulnerable releases.

4. 4

   Record

   The result is stored as a structured record, so every machine reports the same way.

Tags support four common tasks. Each one also has a limit that follows from how far the tags reach:

The standard depends on adoption. A SWID tag exists only if the publisher's installer creates one, so a tool that relies only on tags will have blind spots.

Most software inventory is therefore still built through automated discovery, from what an agent or scanner sees on the endpoint. SWID tags are a supplementary, higher-confidence signal where they exist. They are not the single source of truth. The main evidence comes from:

• installed-program lists, as the operating system registers them
• file and registry evidence left by an installation
• package-manager records

Keep the standard and the goal apart. Software inventory is the broader aim: a current, accurate record of every application installed across an organization's machines. A SWID tag is one standardized way to identify a single installed product precisely.

An organization can have reliable inventory built from agent-based discovery and never use a SWID tag. The reverse also happens. A machine can carry SWID tags for some products while its overall inventory covers the rest by other means. The wider practice is described in software asset management.

Anexet builds its software list from the attributes the agent reads on each workstation: name, company, version, and path. In Anexet Inventory, each workstation card lists installed programs, so software nobody requested stands out in the list.

Start with the products that carry the most license cost or security risk, and check whether their publishers create tags. Where they do, the tag confirms the exact product. Where they do not, the endpoint record remains the source, and the inventory process keeps it current.