Flat factory networks hid device identity; Cisco Identity Services Engine (ISE) enforced device?class microsegmentation

Overview

A factory’s operational technology sat on flat networks, so Internet of Things (IoT) and industrial devices could talk to anything on the same segment. Incidents crossed lines between production cells, asset ownership was unclear, and vendor maintenance often required broad firewall changes. Intelligex built an inventory from passive discovery and DHCP logs, classified devices by type and owner, and enforced microsegmentation through Cisco Identity Services Engine (ISE) with reusable access control list (ACL) templates. Exceptions flowed through an approval workflow tied to maintenance windows. Cross?segment incidents diminished, asset tracking became dependable, and maintenance activities ran with less blast radius—while switches, controllers, and plant systems remained in place.

Client Profile

• Industry: Discrete manufacturing with multiple production facilities
• Company size (range): Enterprise network across plants, warehouses, and corporate sites
• Stage: Flat Layer?2 segments on the factory floor; PLCs and HMIs alongside IP cameras, badge readers, and test benches; Windows DHCP; Cisco campus switching; limited visibility outside of ticketed changes
• Department owner: IT & Infrastructure (Network Engineering and Platform)
• Other stakeholders: Operations Technology (OT)/Controls, Security, Plant IT, Vendor Management, Service Desk, Compliance, Internal Audit, EHS

The Challenge

Production and support devices shared broad broadcast domains. A camera or engineering workstation could reach OT endpoints without passing through a clear control point. When something misbehaved—malware on a laptop, a noisy device, or a misconfigured tool—effects spilled into neighboring cells. Restoring service meant pulling cables, moving devices, or applying one?off switch rules in the middle of a shift.

Asset visibility was patchy. DHCP logs and plant spreadsheets overlapped but did not align. Switch tables showed MACs without context, and device names were inconsistent. Vendor teams requested access in emails, and firewall rules lingered beyond the maintenance window. Without a dependable inventory and segmentation policy, the team balanced uptime against risk with blunt tools.

Active scanning was off the table. Many devices were sensitive to probes, and production windows were tight. Policies existed in documents, but switches enforced local variations that drifted over time. Exceptions were everywhere, approvals were informal, and audits required fishing through change tickets, emails, and configuration backups.

Why It Was Happening

Root causes were a flat network design and a lack of identity for devices at enforcement time. Factories had grown organically; each new line added more devices to existing VLANs for convenience. Without a canonical inventory, DHCP fingerprints, or profiling, policy could not be tied to what a device actually was. Enforcement relied on coarse subnet controls rather than on device class and owner.

Ownership and timing were split. Network owned switches, OT owned PLCs and HMIs, Security set policy, and vendor teams worked from tickets. There was no coordinated pipeline to discover devices passively, keep an accurate inventory, enforce microsegmentation, and route exceptions through change control. As production needs shifted, so did ad hoc rules, leaving little confidence that protections matched reality.

The Solution

Intelligex implemented a passive discovery and segmentation program anchored on Cisco ISE. Device identity was derived from DHCP logs, MAC OUIs, switch telemetry, and passive traffic fingerprints; an inventory mapped devices to owners, locations, and functions; and microsegmentation policies were enforced via ISE using Security Group Tags (SGT) and ACL templates applied at the switch edge. Exceptions for vendor access or maintenance windows flowed through the ITSM with time?bound approvals. The approach aligned to industrial security guidance in NIST SP 800?82 and used Cisco’s policy and segmentation capabilities (Cisco ISE, Cisco TrustSec).

• Integrations: Windows DHCP logs; switch telemetry (LLDP/CDP, MAC tables); SPAN feeds for passive discovery where safe; NetFlow/IPFIX; Cisco ISE for profiling and policy; campus switches and distribution firewalls for enforcement; ITSM (for example, ServiceNow) for exceptions and approvals; SIEM for centralized logging.
• Canonical inventory: Device record with MAC/IP, hostname, vendor OUI, switch/port, site/line, owner, device class (PLC, HMI, camera, badge reader, workstation, tool), and lifecycle state; relationships to services and maintenance groups.
• Profiling and classification: DHCP options, LLDP/CDP attributes, and passive fingerprints to assign device class and SGT; confidence scores and review queues for ambiguous cases.
• Policy templates: Reusable ACLs and Security Group ACLs (SGACLs) for common OT patterns (controller?to?I/O, HMI?to?controller, historian?to?cell, printer/camera isolation, workstation egress); default?deny outside allowed flows.
• Enforcement: Switch?edge controls via ISE authorization and downloadable ACLs; dynamic segmentation with SGT where supported; distribution firewall guardrails for inter?site flows; change?of?authorization (CoA) for policy updates without reboots.
• Monitoring and health: Dashboards for new devices, policy hits/denies, denied flows by device class, and noisy endpoints; alerts for policy mismatch and unexpected lateral traffic.
• Exception workflow: Time?bound access packages for vendor maintenance with approver matrices; reason codes, compensating controls, and auto?revert at window close; evidence attached to the change.
• Security and privacy: Role?based access to inventory and policy consoles; minimal packet data retained; plant?specific views for OT teams; immutable logs of policy changes and enforcement results.

Implementation

• Discovery: Enabled DHCP logging and centralized parsing; harvested switch CDP/LLDP tables and MAC address tables; configured SPAN in read?only mode for selected segments; inventoried device types with OT; reviewed vendor access patterns, maintenance windows, and audit findings.
• Design: Defined the device classes and SGT taxonomy; authored policy templates for allowed flows by class; mapped enforcement points (switch edge, distribution firewalls); specified exception categories and approval tiers; planned dashboards, alerting, and evidence exports; documented safety rules for passive collection.
• Build: Stood up the inventory and classification pipeline; integrated DHCP, switch telemetry, and SPAN feeds; configured Cisco ISE profiling and authorization policies; created downloadable ACLs and SGACLs; wired ITSM change workflows for exceptions; enabled log forwarding to the SIEM and built dashboards.
• Testing/QA: Ran in monitor?only mode: tagged devices, simulated policy hits, and recorded denies without enforcing; validated classifications with OT owners; piloted enforcement on isolated cells; verified CoA behavior and rollback; tuned policy templates based on observed flows.
• Rollout: Enforced segmentation by site and line in waves; started with non?critical segments, then moved to production cells; applied exception workflow for vendor maintenance; tightened policies after stable cycles; kept legacy VLAN controls as a controlled fallback early on.
• Training/hand?off: Delivered sessions for Network, OT, and Helpdesk on reading inventory and policy hits, requesting exceptions, and using maintenance windows; published runbooks for vendor access and emergency disables; updated SOPs for device onboarding and port turn?up; transferred policy ownership and dashboards to Network and OT under change control.
• Human?in?the?loop review: Established recurring reviews for ambiguous classifications, denied flow investigations, aging exceptions, and policy drift; decisions recorded with rationale and effective dates; improvements fed into templates and profiling.

Results

Device identity became actionable. The team could see what was on each segment, who owned it, and which flows it needed. Policies at the switch edge allowed only the expected communications for each device class, and changes landed through ISE without disruptive restarts. When a vendor required access, an access package with a defined window and approvals applied the temporary policy and then reverted automatically.

Operations steadied. Lateral movement risks dropped as microsegmentation took effect, incident scope shrank to the affected cell, and plant teams worked maintenance windows without broad firewall changes. Inventory and policy lived together, so audits pulled evidence showing how devices were discovered, how they were classified, and how policies were enforced. Switches, controllers, and applications stayed the same; the addition was a discovery?to?policy layer with governance and safe exceptions.

What Changed for the Team

• Before: Flat VLANs exposed entire floors. After: Device?class policies limited flows at the switch edge.
• Before: Asset lists were inconsistent. After: Passive discovery and DHCP logs fed a governed inventory with owners.
• Before: Vendor work opened broad firewall rules. After: Time?bound access packages applied narrow, approved paths that reverted automatically.
• Before: Changes required reconfiguring multiple devices. After: Cisco ISE pushed authorization and ACL updates with change?of?authorization.
• Before: Incidents spilled across cells. After: Microsegmentation contained issues to defined segments with clearer blast radius.
• Before: Audits reconstructed intent from configs. After: Evidence tied discovery, classification, policy, and exceptions in one trail.

Key Takeaways

• Discover passively; build your inventory from DHCP, switch telemetry, and safe traffic fingerprints before enforcing policy.
• Segment by device class; express allowed flows as templates and apply them at the edge.
• Automate enforcement; use Cisco ISE and downloadable ACLs or SGACLs to keep policy consistent and auditable.
• Govern exceptions; time?bound vendor access with approvals and auto?revert reduces drift.
• Roll out in monitor mode first; validate classifications and flows before turning on enforcement.
• Integrate, don’t replace; keep switches, controllers, and firewalls—add a discovery and policy layer with change control.

FAQ

What tools did this integrate with? DHCP servers provided lease logs, campus switches supplied LLDP/CDP and MAC table data, and SPAN and flow exports supported passive discovery. Policy and enforcement used Cisco Identity Services Engine with downloadable ACLs and Security Group Tags (see Cisco TrustSec). Exceptions and approvals ran through the existing ITSM (for example, ServiceNow), and logs flowed to the SIEM. Segmentation design aligned with NIST SP 800?82.

How did you handle quality control and governance? Device classes and policy templates lived under change control with owners and rationale. New devices entered a review queue when classification was ambiguous. Enforcement began in monitor?only mode, and changes required approvals with evidence of observed flows. Vendor access used time?bound packages with compensating controls. All discovery events, classifications, policy updates, and exceptions were immutably logged.

How did you roll this out without disruption? The team tagged devices and recorded policy hits without blocking traffic at first. After validating classifications with OT owners, enforcement was enabled on low?risk segments, then on production cells in defined windows. Legacy VLAN controls remained as a fallback early on, and change?of?authorization allowed policy updates without device reboots.

How did you discover devices without active scanning? The pipeline combined DHCP logs, LLDP/CDP from switches, MAC OUIs, and passive observation from SPAN and flow data. These signals identified vendor, device type, and communication patterns without sending probes. Where passive data was insufficient, owners validated details during onboarding.

How did you handle legacy protocols and vendor access? Policy templates included common OT protocols and constrained them to specific peers and ports. Vendor access used exception packages tied to maintenance windows, with just?enough reach to required hosts. At window close, policies reverted automatically, and results were attached to the change record.

What about sites with older switches or limited TrustSec support? Where SGTs were not available, the solution used downloadable ACLs or interface?level ACLs applied via ISE authorization. Distribution firewalls enforced guardrails between lines and sites. The same device classes and policy templates applied regardless of enforcement mechanism.