Software Inventory Message and Attributes (SWIMA)

SWIMA is a protocol specification, not software you install on its own. It defines the request and response messages that an assessment system (the party that wants to know what is installed) and an endpoint (the machine being inventoried) exchange during a posture assessment session. The specification fixes the message structure and the attributes each software record must carry. Any conforming client and any conforming server can therefore interoperate, whoever built each side.

The goal is to remove guesswork from software inventory collection. Instead of a monitoring tool parsing whatever proprietary format an agent emits, SWIMA gives both sides one shared, versioned message schema to code against. Finding the software is still the job of IT asset discovery; SWIMA standardizes how the result is reported.

SWIMA runs as a message type inside the IF-M (Interface for Message) protocol of the TNC architecture. That protocol is carried over the broader Network Endpoint Assessment (NEA) framework, which is used for network access control and posture checks.

In practice, the exchange follows a request-response pattern, with an optional subscription:

1. 1

   Request

   The assessment system asks for all software, a subset, or changes only.

2. 2

   Response

   The endpoint returns matching records with the standard attributes.

3. 3

   Subscription

   Optionally, the endpoint sends messages when installs, updates, or removals happen.

SWIMA is built to work with software identification (SWID) tags. A SWID tag is the companion standard that gives each installed software product a structured identity record: name, version, publisher, and a unique tag ID, usually embedded by the software's own installer. A SWID tag labels one piece of software. SWIMA is the transport that lets an endpoint hand a collection of those labels, or evidence derived from them, to whoever asks. The two specifications are meant to be used together: SWID defines what a software record looks like, and SWIMA defines how it is reported.

An endpoint without SWID tags for a given application can still be asked to report other collected evidence, such as software identified through the SWIMA record's own attribute set. The strongest and most interoperable results, however, come from SWID-tagged software combined with SWIMA transport.

The two standards cover different parts of the same job. The table shows which part each one handles:

SWIMA is a formal, interoperable specification, not a de facto industry standard. Most commercial IT asset inventory and endpoint management tools collect installed-software data with their own proprietary agent protocols and attribute sets, such as System Center Configuration Manager (SCCM). Some optionally map that data to SWID or SWIMA-style fields to exchange it with government or standards-driven toolchains.

SWIMA sits inside the broader Security Automation and Continuous Monitoring (SACM) effort. SACM standardizes how organizations verify the security posture of their endpoints continuously, instead of relying on periodic manual audits. Typical consumers of SWIMA data include:

Most confusion about SWIMA starts with the question of what it is. Three mistakes come up often in software asset management projects:

• Looking for SWIMA as an installable tool, when it only defines the message format.
• Assuming every application has a SWID tag. Software without one can still be reported through other evidence, but the strongest results need tagged software.
• Expecting SWIMA to replace the inventory agent. Most products keep their own agent protocols and map data to SWIMA only when an integration needs it.

Start with the question the inventory must answer: which software runs on which endpoint, and how quickly that answer must change. If a monthly list is enough, a standard message format adds little. If other tools must react to every install or removal, SWIMA-style reporting earns its place. On the product side, Anexet's software inventory reads installed programs through its own agents on workstations, and the data stays in the customer's infrastructure.

In practice, SWIMA matters most where organizations must show interoperable, standardized continuous monitoring, for example, to meet federal automation guidance. It is rarely the everyday collection mechanism inside a typical commercial inventory product.