---
sourceDocument: Brazil Security Management
sourceDocumentLink: https://www.servicenow.com/docs/r/security-management

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Security Management

ft:clusterId :

    - security

bundleId :

    - security

workflow :

    - Technology


---

# Managing unclassed hardware

# Managing unclassed hardware {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Managing unclassed hardware

Unclassed hardware refers to assets that cannot be matched to existing configuration items (CIs) in the Configuration Management Database (CMDB) during import, typically because they do not meet the defined lookup rules.
These assets are automatically created under thecmdbciunclassedhardwareclass by the Identification and Reconciliation Engine (IRE) when no matches are found.
Show full answer Show less  

## How Unclassed Hardware Is Created

* During initial import from scanner integrations, Unified Security Exposure Management (USEM) uses host data to attempt to match assets with CIs in the CMDB.
* If no match is found based on lookup rules, IRE applies identification rules on the hardware class and its children.
* IRE creates a new CI under **cmdbciunclassedhardware** for unmatched assets.
* When Discovery finds the same asset later, instead of reclassifying the unclassed hardware, it often creates a new CI under the appropriate classified hardware type.

## Challenges with Reclassification and Duplication

Discovery creating duplicate CIs instead of reclassifying unclassed hardware happens due to:

* **Name Field Discrepancy:** Identification rules rely on the hardware CI's name.
* **Inconsistent Naming:** USEM may use fully qualified domain names (FQDN) or NetBIOS names, whereas Discovery may use just the hostname.
* **Result:** This inconsistency prevents IRE from recognizing the unclassed hardware and newly discovered asset as the same entity, causing duplicate CIs rather than reclassification.

**Important:** When IRE is activated, direct reclassification of items from discovered data is not supported.

## Practical Implications for ServiceNow Customers

* Expect unclassed hardware assets to be created automatically for unmatched devices during import.
* Be aware that duplicate classified CIs may be created when Discovery finds assets already present as unclassed hardware due to naming inconsistencies.
* Reclassification is not automatically handled by IRE; manual intervention or additional processes might be required to reconcile duplicates.
* Understanding the naming conventions used by USEM and Discovery is critical to managing and minimizing duplication.  
An asset is classified as unclassed hardware when it cannot be matched to an existing configuration item (CI) in the Configuration Management Database (CMDB) using defined lookup rules during import.

## How unclassed hardware is created {#sem-unclassed-hardware__section_z4z_45g_jhc}

Unclassed hardware is created during initial import from scanner integrations using the following process:

1. USEM automatically uses host data to search for matches in the CMDB. The lookup rules are used to identify configuration items (CIs) and add them to the finding record to aid in remediation.
2. If no match is found based on the lookup rules, the Identification and Reconciliation engine (IRE) applies its own identification rules defined on the hardware class and all its children.
3. The IRE then creates a new CI under the `cmdb_ci_unclassed_hardware` class.
4. When Discovery finds this asset, instead of reclassifying the existing unclassed hardware, it creates a CI. This is because the identification rule relies on the name of the hardware CI.
{#sem-unclassed-hardware__ol_epr_3bh_jhc}

## The challenge with reclassification and duplication {#sem-unclassed-hardware__section_tcp_hvg_jhc}

When Discovery subsequently finds an asset that already exists as unclassed hardware, it often creates a new, classified CI (e.g., a Windows server CI) instead of reclassifying the existing unclassed hardware CI. This happens because:

* Name Field Discrepancy: The identification rules heavily rely on the name field of the hardware CI.
* Inconsistent Naming: The name used by Unified Security Exposure Management (e.g., FQDN or NetBIOS name) might differ from the name used by Discovery (e.g., just the hostname).
* Result: This discrepancy prevents IRE from recognizing the unclassed hardware and the newly discovered asset as the same entity, leading to the creation of a duplicate CI under a new class rather than reclassifying the original.

{#sem-unclassed-hardware__ul_emg_lvg_jhc}  
Note:  
If the Identification and Reconciliation Engine (IRE) is activated, the option to reclassify items directly from discovered items is not supported.  
The following extracts show the IRE payload for creating CI in Unclassed Hardware via Vulnerability Response and Discovery respectively.

    "className": "cmdb_ci_unclassed_hardware",

    "values": {
            "name": "asset01.company.com",//from NetBios,
            "mac_address": "1a:5e:2c:0e:42:f3",
            "fqdn": "asset01.company.com",
            "ip_address": "133.10.3.123"
        }

    "settings": {
            "updateWithoutSwitch": true
        }

    "className": "cmdb_ci_cmdb_ci_win_server"

    "values": {
            "name": "asset01",
            "mac_address": "1a:5e:2c:0e:42:f3",
            "fqdn": "asset01.company.com",
            "ip_address": "133.10.3.123",
            "os_domain": "company"
        }

    "settings": {
            "updateWithoutSwitch": false
        }

In this scenario, the existing Unclassed Hardware CI is not reclassified as a Windows Server. Instead, a new CI is created under Windows Server. This is because the identification rule depends on the Hardware CI's name. As
you can see from the payloads, the name received from Unified Security Exposure Management matches the FQDN/NETBIOS, whereas the Discovery payload provides only the host name.
**Related tasks**   

* [Reclassify unclassed hardware](https://www.servicenow.com/docs/46100vkd48xM1Q~FBa7ioQ "Reclassify unclassed hardware by updating the lookup rules.")

