Armis ID instability causing CI hijacking in CMDB — Armis issue or ServiceNow issue?

Palle
Tera Contributor

‎11-20-2025 01:39 AM

I’m using the Armis Service Graph Connector on Yokohama Patch 7, and running into a serious CMDB issue related to unstable Armis IDs.

Armis sends its internal device ID into sys_object_source.source_native_key.
However, in my environment, the same Armis ID is later reused for a completely different device (different serial, MAC, etc.).

When this happens:

  • IRE finds the old sys_object_source entry for that Armis ID

  • IRE updates the previous CI instead of creating a new one

  • This causes CI hijacking, where Device A gets overwritten with Device B’s data

Example:

  • Armis ID 121 → Device A today

  • Later Armis ID 121 → Device B

  • IRE updates Device A with Device B’s attributes

My identification rules (serial + MAC) are correct, but IRE still follows the existing sys_object_source link.

My questions to the community:

  1. Is unstable/recycled Armis IDs a known issue on the Armis side?

  2. Has anyone else seen this behavior?

  3. Is there a ServiceNow-side configuration (IRE behavior/prevention rules) that can stop IRE from updating a CI when the Armis ID’s identity changes?

  4. Can we stop using the sys_object_source data for Identification and let the system use the Identifiers defined at class level?

  5. Or should this only be fixed on the Armis side by ensuring stable IDs?

Any guidance or best practices would be really appreciated.

0 Helpfuls
  • 383 Views
1 REPLY 1

Matthew_13
Kilo Sage

3 weeks ago

Hi!

What you’re seeing happens because Armis is reusing IDs, and IRE assumes source_native_key is stable. This causes CI hijacking when the same ID points to a different device.

Options:

  1. Best fix: Ask Armis to provide stable, unique IDs.

  2. ServiceNow-side:

    • Update IRE rules to require matching serial + MAC before updating a CI.

    • Configure IRE to ignore source_native_key for identification and rely on class-level identifiers instead.

  3. Monitor collisions to catch mismatched devices early.

Bottom line: IRE can be adjusted to reduce risk, but stable Armis IDs are the clean solution.

 

@Palle - Please mark Solution Accepted and give Thumbs up if you find helpful

0 Helpfuls