Vulnerability Response integration IRE error for unmatched CI class

[HelloCAD]

Hi,

For Vulnerability response integration, I read that CI are created in Unmatched CI class if the IRE encounters an error while creating an Unclassed Hardware or Incomplete IP Class CIs.

My question is how can we know what was the error that IRE encountered? Where can we see specific logs for this error? How can we handle the unmatched CIs?

Any help would be helpful.

Thank you!

[OmkarR485928563]

Hello @HelloCAD , Check the "Additional Information" field on the discovered item. To handle an unmatched CI, you can manually reclassify it, adjust the CI lookup rules, or use the Identification Simulation for advanced debugging.

Try to refer the KB article - KB0998270

Regards,

----

If this response was helpful, please select "Accept as Solution" and "Helpful." This helps both the community and me.

[BhavaniYamsani]

Hey @HelloCAD ,
To give you complete picture!!

The important distinction is that an Unmatched CI does not always mean that IRE encountered an error. Depending on the Vulnerability Response version and configuration, it can also be the normal fallback when no matching CI is found or when the newer CI classes are not enabled.

When scanner asset information is ingested, the processing generally follows these steps:

1. ServiceNow first checks whether the asset matches an existing Discovered Item or CMDB CI.

The Discovered Items table is sn_sec_cmn_src_ci. Vulnerability Response first attempts to identify the source asset using its source, source instance and vendor asset ID. If that does not match, the configured CI Lookup Rules are evaluated to find an existing CI.

IF NO MATCH IS FOUND

2. The integration attempts to create a CI using the applicable CI creation process.

Starting with Vulnerability Response v12.2, unmatched assets can be sent to IRE for creation in classes such as:

• Unclassed Hardware (cmdb_ci_unclassed_hardware)

• Incomplete IP Identified Device (cmdb_ci_incomplete_ip)

• Cloud Resource, available starting with v18.0

These classes require the CMDB CI Class Models plugin. If the required functionality is not enabled, the legacy Unmatched CI class (sn_sec_cmn_unmatched_ci) may be used instead.

IF IRE ENCOUNTERS AN EXCEPTION THAT PREVENTS CI CREATION

Spoiler

3. Check the Additional Information field on the Discovered Item.

Starting with Vulnerability Response v24.0.6, ServiceNow records details of exceptions that prevent CI creation in the Additional Information field.

Navigate to:

Security Operations → CMDB → Discovered Items

Then:

1. Find the Discovered Item associated with the unmatched asset.

2. Open the record.

3. Inspect the Additional Information field.

4. Review the exception details to identify the reason CI creation failed.

5. Correct the underlying issue and validate the asset ingestion again.

This is the first place I would look when troubleshooting an IRE creation failure on a supported version.

How should we handle Unmatched CIs?

I would approach them as follows:

1. Review the Discovered Item first.

Determine whether the asset is genuinely new, whether it should match an existing CI, or whether CI creation failed. Do not assume that every unmatched record represents an IRE error.

2. Review the CI Lookup Rules.

Navigate to Security Operations → CMDB → CI Lookup Rules.

If the asset should have matched an existing CI, check whether the rules use appropriate identifying attributes and whether the source data is sufficient to identify the CI uniquely.

3. Correct the underlying data or configuration.

Depending on the findings, correct the identifying attributes, lookup rule logic, CMDB CI Class Models configuration or the specific exception reported in Additional Information.

4. Reclassify only when appropriate.

If an unmatched CI genuinely belongs to an existing CMDB class, review the reclassification options for your release. However, ServiceNow documents that the reclassify option on Discovered Items is not supported when IRE is active. In that situation, do not rely on manual reclassification through the Discovered Items interface.

5. Allow subsequent reconciliation to establish the correct relationship.

Once the source data and identification logic are corrected, validate that the asset matches the intended CI and that its Discovered Item is updated accordingly. Avoid manually deleting unmatched records without first understanding their relationships with vulnerability records and remediation tasks.

What if Additional Information does not show the error?

The exception details described above are documented for Vulnerability Response v24.0.6 and later. If you are on an earlier version, do not assume that the same diagnostic information will be available in that field.

Also, if you continue to see records created in the legacy Unmatched CI class, check whether the CMDB CI Class Models plugin and the expected IRE-based CI creation functionality are enabled. The legacy class by itself does not prove that IRE failed.

References:

• Creating CIs for Vulnerability Response using IRE

• Managing unmatched CIs

• CI lookup rules for Vulnerability Response integrations

The key takeaway is to check the Discovered Item's Additional Information field first for IRE creation exceptions, then correct the underlying cause. For unmatched assets without an IRE exception, focus on CI lookup rules, source data quality and the applicable CI class configuration.

If this answer helps, please mark it as helpful.
Thank you
Yamsani Bhavani
ServiceNow Developer - SecOps, GRC, Custom Applications, Now Assist