Ask someone what the Armis–ServiceNow integration does, and there is a good chance the answer will be, “populates the CMDB,” meaning they’re discussing the Service Graph Connector for Armis. Now, this is certainly part of the story, but it is only one of five Armis applications available in the ServiceNow Store.
CoreX built all five of those applications and has worked alongside Armis since 2020 and the ServiceNow OT business unit since 2021. We continue to support and enhance the apps today, which gives us a slightly different perspective on how they fit together, where they overlap, and what customers should know before deciding what they need.
So, rather than walking through the product descriptions, let’s look at what each integration does in practice.
The Service Graph Connector is the foundation for most Armis and ServiceNow implementations.
It brings devices and sites Armis discovers into the ServiceNow CMDB, classifies them by Armis category and type, and maps them to the appropriate CI classes. From there, ServiceNow's Identification and Reconciliation Engine helps resolve identity and relationships so the incoming information reconciles with the customer's existing CMDB rather than another disconnected asset inventory.
The value of the other integrations increases considerably once ServiceNow understands what the device is.
There are also current limitations worth understanding before positioning the connector. Software data is imported for Operating Systems but not Installed Applications. Version 2.2.0 writes Operating System information into the ServiceNow software tables, using either the legacy SAM tables or the modern Software Install table used by SAM-F and SAM Pro.
Full software inventory through the Armis /device-applications API is possible and may end up in a future release, but should not be positioned as a capability available today.
That direction could be useful when discussing where the integration is heading, but it should not be treated as current functionality or included as a scope commitment.
Once the devices are in ServiceNow, you can start to operationalize the data. The Armis platform allows you to configure Policies which trigger alerts when devices violate them.
The Armis Alert Integration allows you to import Armis alerts into ServiceNow as Incidents or Event Management events. This is essentially the ITSM and ITOM path. Device behavior, policy violations, and other alerts can enter the operational queues teams already use, with the alert connected to the CI established through the Service Graph Connector.
The integration also has some mapping frameworks that allow you to map severity or criticality values between Armis and the target ServiceNow Incident or em_event table for seamless integration into your existing processes.
Instead of an Armis alert arriving as an isolated piece of security or device information, the operations team can work it in the context of a known configuration item and the processes ServiceNow already uses to manage it.
Armis SIR addresses a similar requirement for a different audience. The Armis SIR extends the Armis Alert Integration, allowing the same Armis alerts to become Security Incidents within ServiceNow Security Incident Response, putting them into the workflows used by the SOC rather than those used by the service desk.
Underneath, Alert Integration and SIR are more closely related than their separate store listings might suggest. SIR is technically an extension of the Alert Integration rather than an entirely separate pipeline. Both query the same Armis Search API for Alert, while Armis Security Incident Integration adds the transform map and configuration settings required to populate the appropriate SIR tables and criticality values.
For customers, the simpler way to think about it is as a destination decision. The Armis signal is the same. Where it needs to go depends on who is responsible for acting on it and whether the customer is running ServiceNow SecOps.
So far, most of the information has been moving from Armis into ServiceNow. Application Service Mapping is where the conversation begins moving in the other direction.
The integration pushes service mapping relationships from ServiceNow back into Armis, allowing information maintained in ServiceNow to add business and operational context to what Armis knows about a device.
It is not the only way to send information back. The Service Graph Connector can also map CMDB attributes to Armis Custom Properties. In either case, the goal is similar: give the Armis platform useful ServiceNow context, such as assignment groups, CI ownership, or the business service an asset supports.
This creates a more useful exchange between the platforms. Armis contributes detailed visibility into the devices it discovers, while ServiceNow can contribute the organizational context surrounding those devices.
Discovery tells you what is there. Vulnerability information tells you what needs attention.
The Armis Vulnerability Response Integration allows Armis to serve as a vulnerability detection source for ServiceNow Vulnerability Response and OT Vulnerability Response. Findings identified by Armis can therefore become prioritized, and remediation work can be operationalized within ServiceNow rather than remaining findings in a report that someone still has to translate into action.
This is a distinct Store application from the Service Graph Connector, and worth remembering when planning an implementation. The SGC establishes and maintains the asset foundation. The VR integration uses Armis vulnerability information to drive the remediation process.
Looking at the five applications individually is useful, but the sequence between them tells the more interesting story.
Armis discovers devices and provides information about their identity, exposure, and behavior. ServiceNow connects that intelligence with configuration data, business services, ownership, and operational priority. From there, ServiceNow workflows can route the work, track remediation, and maintain a record of who is responsible for what happens next.
The Service Graph Connector establishes that common asset foundation. Alert Integration or SIR carries an Armis signal into the appropriate operational or security process. Vulnerability Response turns findings into remediation work. Application Service Mapping, along with the SGC's Custom Properties capability, lets useful ServiceNow context flow back to Armis.
In most implementations, that makes the CMDB integration the logical place to begin, with vulnerability response frequently following behind it. Armis can function as both a discovery source and a vulnerability detection source, and customers generally get more value when those capabilities are considered as parts of the same architecture rather than separate integrations.
Experience with these integrations has also shown us that a few decisions have an outsized effect on scope. Getting them on the table during discovery makes the rest of the conversation much easier.
Which Armis categories and device types are involved?
The connector can populate more than 80 CMDB classes, covering everything from industrial sensors and EWS computers to handheld medical devices, networked IoT equipment, wearables, displays, and media players.
That variety is precisely why the device mix matters so much. “Everything in Armis” may sound like a scope, but before anyone estimates the work, it needs to become a much more specific list of what is in the customer's environment and what needs to enter ServiceNow.
Where should alerts go, and is Vulnerability Response part of phase one?
Customers also need to decide whether Armis alerts belong in the ITSM/ITOM workflow through Alert Integration or in the SOC through SIR, along with whether Vulnerability Response should be included in the initial implementation.
There can be genuine overlap between Armis's vulnerability capabilities and ServiceNow Vulnerability Response. We prefer to work through that overlap during discovery and determine what role each platform should play for that customer rather than assume there is one answer that applies everywhere, but we generally recommend ServiceNow as the workflow engine for managing vulnerabilities.
Does ServiceNow need to send anything back to Armis?
Not every implementation needs bidirectional information flow. When it does make sense, the SGC can map ServiceNow columns into Armis Custom Properties, while Application Service Mapping can send service relationships back to Armis.
Those capabilities can make the Armis data more meaningful by adding business context, but both should be deliberate implementation decisions rather than assumptions built into the baseline scope.
Discovering more devices has value. Identifying vulnerabilities has value. Detecting unusual behavior has value. The larger opportunity comes from connecting that information to the systems customers already use to understand their environment, assign ownership, prioritize work, manage incidents, remediate vulnerabilities, and measure what happened afterward.
That is ultimately what these five integrations are designed to accomplish. Armis provides a remarkably detailed view of what is happening across the asset environment. ServiceNow provides the operational context and workflows needed to do something with that information.
The five CoreX-built Store applications create the connections between them, so discovery and security intelligence can become part of the way the organization operates rather than another source of data someone must watch.