NetBox Labs + Elisity: Network Source of Truth Driven Microsegmentation

Network teams keep NetBox current. Every device carries a site, a location, a rack, a device role, a device type, a manufacturer, a platform, a serial number, and an asset tag. That record governs provisioning, capacity planning, and change management, and the people who maintain it treat it as authoritative. It almost never reaches the security policy engine. Segmentation policies get written from a different set of inputs: subnet ranges, VLAN IDs, and a spreadsheet an analyst assembled by walking the floor. Two inventories of the same network now exist, maintained by two teams, and they disagree within weeks. The security team is the one working from the stale copy. A device that moved from the Cleveland plant to the Columbus lab is correct in NetBox and wrong in the policy that governs it. When an auditor asks which record is authoritative, there is no good answer.

Elisity pulls your NetBox records into IdentityGraph through an API connection and keeps them current, so the record your network operations team trusts becomes the record your security policy runs on. The connector imports device name, site, location, device role, device type, manufacturer, operating system platform, serial number, asset tag, and any custom tags your team has defined. Those attributes land on the asset in IdentityGraph next to everything Elisity already knows about it: observed traffic behavior, user identity, and context from your other connected sources such as EDR, CMDB, and OT visibility platforms. One asset record, many contributing systems, no manual reconciliation. NetBox stays the authority on how your infrastructure is documented. Elisity becomes the place that documentation is enforced. Nothing changes about how the network team works, and nothing has to be re-entered by the security team.

Building a segmentation policy starts with knowing what each device is, where it sits, and who owns it. Most security teams gather that by hand: exporting ARP and MAC tables, correlating against DHCP leases, chasing owners by email, and reconciling all of it in a spreadsheet that is stale the day it is finished. The work runs for weeks and restarts every time the environment changes. It also produces errors that surface later as production incidents: an infusion pump grouped with guest wireless, a badge reader classified as a workstation, a lab instrument that loses reach to its collection server overnight because someone typed the wrong role. Meanwhile the correct answer already exists, documented by the network team the day the device was racked. Classification is rarely a knowledge problem. It is a plumbing problem between the system that holds the truth and the system that enforces it. See how automated asset discovery closes that gap.

Elisity cross-references every discovered device against your NetBox source of truth by MAC address and IP address, and assets that match receive a “Known in NetBox Labs” attribute in IdentityGraph. That single attribute turns a documentation process into an access control. A device that appears in NetBox is documented, owned, and accounted for, so it can be granted the access its role calls for. A device on the same subnet that does not appear in NetBox arrived without passing through change management, and you can restrict it, quarantine it, or send it to a review queue before you know anything else about it. Security teams have wanted that control for years and have usually had to approximate it with certificates or 802.1X enrollment. Here it comes from a record your network team already maintains, and it stays accurate because they keep maintaining it.

Infrastructure moves. A device is relocated to another site during a consolidation. A rack of servers changes device role when the application it hosted is retired. New equipment arrives every quarter, and the network team records all of it in NetBox as it happens. Segmentation policies written against IP ranges and VLAN assignments follow none of that. They hold whatever state they were given on the day they were written, so the gap between documented reality and enforced policy widens every week. Security teams try to close it with change tickets: a manual policy update for every infrastructure change, filed after the fact, queued behind whatever else is burning. Some of those tickets are never filed at all. What auditors find in a segmentation review is the predictable result: policies that were correct at deployment and have not been correct since.

In the Elisity Cloud Control Center, any NetBox attribute can serve as match criteria for a policy group: site, location, device role, device type, manufacturer, or a custom tag your team defined. You write the intent once. Devices whose NetBox role is PLC, at any site tagged for manufacturing, may reach the historian and nothing else. When the network team moves that device to a new site in NetBox, or changes its role, the attribute changes on the next sync and the device moves into the policy group its new state matches. No ticket, no policy edit, no drift. Enforcement runs through the network infrastructure you already own, so a device that changes role does not have to be re-cabled, renumbered, or moved to a different VLAN to land under a different policy. Your source of truth becomes the control plane for segmentation, and it stays current because your network team was already keeping it current.