ISE APIs in Practice: Better Endpoint Profiling

Introduction

Imagine you have hundreds of IoT devices connecting to your network every day, and your profiling system classifies half of them as "Unknown." You know they are smart TVs, IP phones, medical sensors, and industrial controllers, but your infrastructure simply cannot see deep enough into the traffic to tell them apart. Worse, many of these devices now use randomized MAC addresses, stripping away the one identifier you used to rely on. This is where the ISE API changes the game. By combining programmatic access to Identity Services Engine with intelligent packet capture and analysis, you can feed rich endpoint context back into ISE, dramatically improving profiling accuracy and enabling meaningful zero trust segmentation.

In this article, we walk through the full architecture: why profiling matters, how ISE gathers endpoint data today, where the gaps are, and how you can bridge those gaps using ISE APIs, SPAN or ERSPAN traffic collectors, and Python-based packet analyzers. Every configuration example and capability discussed here is grounded in real-world deployment patterns so you can take these techniques straight into your own lab or production environment.

Why Endpoint Profiling Matters for Zero Trust

Zero trust is no longer an aspirational framework; it is a practical necessity. The core principle is simple: you cannot protect what you cannot see. Before you can apply least-privilege access policies, you need to know exactly what is connecting to your network, what type of device it is, what operating system it runs, and what it is supposed to do.

The stakes are enormous. Ransomware alone is projected to cost organizations $250 billion annually by 2031. Cyber attacks are expensive and relentless, and one of the most common entry points is an unmanaged or poorly classified endpoint that slips through a permissive policy.

Meanwhile, the IoT explosion is making the problem worse. There are roughly 15 billion IoT devices connected to networks today, and that number is expected to double by 2030. Each of these devices needs to be identified, categorized, and placed into an appropriate policy group. Manual classification at this scale is impossible. Automated, API-driven profiling is the only viable path forward.

The Randomized MAC Problem

Modern operating systems on both Apple and Samsung devices (along with many other vendors) now use randomized MAC addresses by default. This means the traditional approach of looking up the OUI (Organizationally Unique Identifier) from a MAC address to determine the device vendor is becoming unreliable.

When a device uses a randomized MAC, your network sees a fabricated hardware address that reveals nothing about the manufacturer, model, or device type. Without additional data points, ISE has no way to differentiate a MacBook Pro from a Samsung Smart TV from an IoT sensor. The solution is to gather richer data from other protocols and feed that context into ISE through its APIs, combining your network data with your profiling data for better results.

How ISE Profiling Works: The Two Components

ISE endpoint profiling relies on two fundamental components working together: the switch-side configuration that collects data, and the ISE-side probes that process it.

Component 1: Switch Configuration

The network access device (typically a Catalyst switch) is responsible for gathering raw endpoint data and forwarding it to ISE. This involves several configuration elements:

• RADIUS configuration for authentication and accounting
• SNMP credentials so ISE can query the switch
• DHCP IP helper addresses to forward DHCP requests
• Device-Sensor configuration to collect protocol data

The Device Sensor feature is particularly important. It consolidates data from multiple protocols, including CDP, LLDP, and DHCP, and transmits that data to ISE via RADIUS accounting messages. This means the switch acts as a collection point, gathering Layer 2 and Layer 3 protocol information and packaging it into RADIUS messages that ISE can parse.

Pro Tip: When using Device Sensor, avoid configuring DHCP IP helper addresses to forward DHCP data directly to ISE as well. This creates duplicate DHCP data being sent to ISE, which can cause profiling inconsistencies. Let Device Sensor handle the DHCP data delivery through RADIUS accounting.

Device Sensor requires specific hardware and software support. It is available on the following Catalyst platforms:

• Catalyst 3000 series (C3K)
• Catalyst 4000 series (C4K)
• Catalyst 9000 series (C9K)
• Catalyst 9300-M
• Meraki MS-390 switches

One important prerequisite: Device Sensor requires DHCP Snooping to be enabled on the switch. Without DHCP Snooping, the switch cannot inspect DHCP transactions to extract endpoint attributes.

Component 2: ISE Probes

On the ISE side, profiling probes are configured per Policy Services Node (PSN). These probes determine what data sources ISE listens to and processes. Available probes include:

• RADIUS probe (best for profiling, handles AuthC, AuthZ, and Device Sensor data)
• DHCP probe
• Active Directory probe
• pxGrid probe (used for integrations with platforms like Catalyst Center and third-party systems)

The RADIUS probe is the most critical for profiling because it receives authentication, authorization, and Device Sensor data all in one stream. When the pxGrid persona and pxGrid probe are enabled on a PSN, additional IoTAsset attribute fields become available for endpoints, providing richer context for IoT device classification.

Probe configuration is managed under Administration > Deployment > [Node Name] in the ISE GUI. A common operational pitfall is inconsistency in probe configurations across PSNs. If one PSN has the RADIUS and DHCP probes enabled but another only has RADIUS, endpoints authenticating against different PSNs will have different profiling data available, leading to inconsistent classification results.

Pro Tip: Audit your probe configuration across all PSNs regularly. Every PSN that handles endpoint authentication should have identical probe settings to ensure consistent profiling behavior across your deployment.

What Are the ISE API Types for Endpoint Profiling?

ISE provides two distinct API types, each serving a different purpose in the profiling ecosystem. Understanding when to use each one is essential for building an effective automation solution.

OpenAPI (and ERS API)

The OpenAPI (available from ISE 3.1 and later) operates on a traditional request-response model. Each interaction is an individual connection between the client and the server. The client sends a request, ISE processes it, and returns a response. The supported HTTP methods are:

• GET to retrieve endpoint or attribute data
• POST to create new records or custom attributes
• PUT to update existing records
• DELETE to remove records

All OpenAPI URLs begin with https://. This is the API type you will use most often for pushing profiling data into ISE from external collectors.

To enable OpenAPIs, navigate to Administration > System Settings > API Settings in the ISE GUI.

WebSocket API (pxGrid Publisher/Subscriber)

The pxGrid API uses a fundamentally different communication model. Instead of individual request-response cycles, it establishes a persistent WebSocket connection between the client and server. The URL scheme uses wss:// instead of https://.

This persistent connection allows you to:

• Monitor live activity on ISE in real time
• Share context between ISE and third-party platforms
• Subscribe to endpoint change notifications

The pxGrid API uses a publisher/subscriber model. After the initial TCP connection and WebSocket handshake, the server accepts the connection and begins streaming updates to the subscriber. This is ideal for integrations that need continuous, real-time awareness of what ISE is seeing.

Feature	OpenAPI / ERS API	pxGrid WebSocket API
Connection Model	Individual request-response	Persistent publisher/subscriber
URL Scheme	https://	wss://
Best For	Pushing/pulling endpoint data	Real-time monitoring and context sharing
Operations	GET, POST, PUT, DELETE	Subscribe, publish
Use Case	Updating endpoint attributes from collectors	Live integration with third-party systems

How Do ISE API Custom Attributes Enhance Profiling?

One of the most powerful features of the ISE API for profiling is the ability to create and populate Endpoint Custom Attributes. These are user-defined fields that extend the default ISE endpoint record with whatever context your environment needs.

Custom Attributes can be defined in two ways:

1. Through the ISE GUI at Administration > Identity Management > Settings > Endpoint Custom Attributes
2. Through the OpenAPI programmatically

The API-driven approach is far more practical at scale. You can build custom attributes on the fly as your collector discovers new data types, and you can validate which custom attributes already exist before creating duplicates.

Custom Attributes store third-party endpoint context, similar to the IoTAsset attributes that are automatically added when the pxGrid probe is enabled. However, Custom Attributes offer several advantages:

• More flexibility in customization since you define exactly what fields exist
• Same performance capabilities as IoTAsset attributes
• No conflicts with existing integrations since they occupy their own unique attribute namespace
• No dependency on pxGrid services being enabled

This last point is critical. The older pxGrid-based approach required enabling the pxGrid service and pxGrid probe, which could create conflicts with other pxGrid integrations already running in your environment. Custom Attributes through the OpenAPI avoid this entirely.

The Profiling Gap: Why Standard Probes Are Not Enough

To understand why APIs and external collectors are necessary, you need to understand the fundamental limitation of standard ISE profiling.

Device Sensor consolidates protocols like CDP, LLDP, and DHCP into RADIUS messages and sends them to ISE. This works well for protocols that the switch can see. However, endpoints communicate across many other protocols that can help with profiling but have Layer 2 or Layer 3 boundaries that prevent them from being directly visible to ISE.

Consider a network with PCs, IP phones, and smart TVs. Device Sensor captures MAC addresses, DHCP attributes, and any CDP or LLDP data these devices emit. But what about:

• SIP signaling from IP phones that reveals the phone model and firmware
• UPnP/SSDP announcements from smart TVs that advertise their make and model
• mDNS broadcasts from Apple devices that identify exact device types
• HTTP User-Agent strings that reveal operating system and browser versions
• SMB traffic that can identify Windows workstation details

These protocols carry rich profiling data, but most of this traffic never reaches ISE through standard probes. It stays local to the VLAN or gets filtered before it crosses Layer 3 boundaries.

This is the profiling gap, and it is where the combination of packet capture collectors and ISE APIs becomes transformative.

Building the Collector Architecture with SPAN and ERSPAN

The solution to the profiling gap is to deploy collectors that capture interesting traffic from the network and analyze it for endpoint attributes, then push those attributes into ISE via the API.

Traffic Collection with SPAN and ERSPAN

To feed traffic to a collector, you use port mirroring:

• SPAN (Switched Port Analyzer): Mirrors traffic from source ports or VLANs to a local destination port on the same switch. The collector connects directly to the SPAN destination port.
• ERSPAN (Encapsulated Remote SPAN): Encapsulates mirrored traffic in GRE and sends it across the Layer 3 network to a remote collector. This allows you to centralize collection without requiring a physical presence at every switch.

The collector can be a dedicated VM or a physical PC. Its job is to:

1. Receive the mirrored traffic from SPAN or ERSPAN
2. Analyze the packets to extract endpoint attributes
3. Send API updates to ISE with the discovered attributes

This architecture scales well. You can deploy collectors strategically across your network, each covering a different segment or building, all feeding data back to ISE through the API.

Pro Tip: Use ACLs to limit the traffic sent via ERSPAN. Mirroring all traffic from a busy VLAN can overwhelm both the network and the collector. Focus on the protocols that provide the most profiling value: DHCP, mDNS, SSDP, SIP, HTTP, and SMB.

Here is an example ERSPAN configuration with an ACL to limit traffic:

monitor session 1 type erspan-source
 source interface GigabitEthernet1/0/1 - 48
 filter access-group 100
 destination
  erspan-id 1
  ip address 10.1.1.100
  origin ip address 10.1.1.1
!
access-list 100 permit udp any any eq 5353
access-list 100 permit udp any any eq 1900
access-list 100 permit tcp any any eq 5060
access-list 100 permit udp any any eq 5060
access-list 100 permit tcp any any eq 80
access-list 100 permit udp any any eq 67
access-list 100 permit udp any any eq 68

Using Pyshark for Packet Analysis in ISE API Workflows

With traffic flowing to your collector, the next step is analyzing it. Wireshark is the most widely used tool for packet inspection, and most engineers are familiar with its graphical interface. However, for automated profiling workflows, you need something scriptable. That is where tshark (the CLI version of Wireshark) and pyshark (a Python wrapper for tshark) come in.

Why Pyshark?

Pyshark is a Python library that wraps tshark, making it easy to parse packets programmatically. Installation is straightforward:

pip install pyshark

There are several Python packet analysis libraries available, each with different trade-offs:

Library	Performance	Usability	Notes
dpkt	Highest	Most complex	Best raw performance
scapy	Medium	Medium	Versatile but slower than dpkt
pyshark	Lowest	Easiest	Best for rapid development and readability

The general consensus is that performance ranks as dpkt > scapy > pyshark, while usability ranks as pyshark > scapy > dpkt. For profiling use cases where you need to extract specific fields from specific protocols, pyshark's ease of use makes it the best choice for most teams.

Pyshark Basics: Loading and Inspecting Packets

Working with pyshark follows a simple pattern. You import the library, load a packet capture file (or start a live capture), and then drill into the packet layers to extract the fields you need.

To load a saved pcap file:

import pyshark

cap = pyshark.FileCapture('/path/to/capture.pcap')
for packet in cap:
    print(packet)

Each packet object contains layers that you can inspect individually. The Ethernet layer provides MAC addresses, the IP layer provides source and destination IPs, and upper-layer protocols provide the rich profiling data you are looking for.

Extracting Profiling Data from Packets

The real value comes from drilling into upper-layer protocol fields. Here are examples of the kind of data you can extract:

• Endpoint MAC address from the Ethernet layer source address
• HTTP User-Agent strings that identify operating system and device type
• UPnP URI values from SSDP announcements that reveal device models
• mDNS records that identify Apple devices, Chromecast devices, and other mDNS-aware endpoints

Values extracted from packets can be stored as variables and then pushed to ISE via the API as Custom Attribute updates.

Live Capture vs. PCAP File Analysis

Pyshark supports both modes:

• PCAP file analysis: Load an existing capture file and process it offline. This is ideal for testing your logic against known captures before deploying to production.
• Live capture: Capture packets directly on an interface for a specified duration (for example, 10 seconds). This is what your collector runs continuously in production.

Pro Tip: Always test your pyshark scripts against existing PCAP files first. This lets you validate your field extraction logic without needing live network traffic, and it is far easier to debug.

Handling Encapsulated Traffic

When working with wireless networks, endpoint traffic is often encapsulated in CAPWAP tunnels between access points and wireless controllers. Similarly, ERSPAN traffic arrives wrapped in GRE encapsulation. Pyshark can parse through these encapsulation layers to reach the inner packet where the endpoint's true source address and protocol data live. Look for the inner Ethernet frame's source address to identify the wireless endpoint.

The Complete ISE API Profiling Workflow

Now let us put all the pieces together into a complete, end-to-end workflow.

Step 1: Deploy the Collector

Set up a VM or dedicated machine running Linux with pyshark installed. Connect it to a SPAN port or configure ERSPAN to deliver mirrored traffic to its IP address.

Step 2: Capture and Analyze Traffic

The collector runs a continuous pyshark live capture on the SPAN or ERSPAN interface. For each packet, it extracts relevant profiling fields based on the protocol:

• mDNS packets: Extract device model and service type
• SSDP/UPnP packets: Extract device description URI and model name
• HTTP packets: Extract User-Agent string for OS and browser identification
• SIP packets: Extract phone model and firmware from SIP headers
• SMB packets: Extract Windows workstation name and OS version
• DHCP packets: Extract hostname, vendor class identifier, and requested options

Step 3: Push Data to ISE via the OpenAPI

Using the ISE OpenAPI (available on ISE 3.1 and later), the collector sends updates to ISE. The workflow is:

1. Check if Custom Attributes exist using a GET call. If not, create them with a POST call.
2. Look up the endpoint by MAC address using a GET call.
3. Update the endpoint record with the new Custom Attribute values using a PUT call.

All API calls use standard HTTPS on TCP port 443. The collector needs network reachability to ISE on this port.

Step 4: Build Custom Profiler Policies (Optional)

Once ISE has richer endpoint data in Custom Attributes, you can optionally create new profiler policies that use this data for classification:

1. Observe the data flowing into ISE Custom Attributes to understand patterns
2. Build a new profiler policy that matches on the Custom Attribute values (for example, if the UPnP model name contains "Samsung TV," classify as Samsung-Smart-TV)
3. Apply the endpoint policy to assign the correct profile to matching endpoints

This creates a closed loop: traffic is captured, analyzed, pushed to ISE, and then used to automatically classify endpoints and apply appropriate authorization policies.

Comparing the Old and New ISE API Profiling Tools

The approach to API-driven profiling has evolved significantly. The older tool used the pxGrid WebSocket API, while the newer tool uses the OpenAPI with Custom Attributes. Here is a detailed comparison:

Feature	pxGrid-based (Old)	OpenAPI-based (New)
ISE Version	ISE 3.1+	ISE 3.1+
ISE Requirements	Enable pxGrid Service and pxGrid probe	Enable Endpoint API
Network Requirements	SPAN/ERSPAN, TCP 443 and 8910, pxGrid Certificates	SPAN/ERSPAN, TCP 443
Supported Protocols	HTTP, XML, mDNS, SSDP, SIP, SMB	HTTP, XML, mDNS, SSDP, SIP, SMB
Randomized MAC Detection	Yes	Yes
Device Model/OS Lookup	~600 unique entries	1,300+ unique entries
PCAP File Analysis	Yes	Yes
Endpoint Validation	No endpoint validation to ISE	Dynamic Endpoint Attribute Verification
Caching	None mentioned	Redis cache for optimized lookups
Data Storage	Sqlite3 DB	Not specified
Deployment	Standard installation	Docker container (can run on Catalyst 9K)
Scale	150+ collectors, 500+ updates per API call	150+ collectors, 500+ updates per API call
Attribute Storage	Built-in IoTAsset fields	Unique Custom Attribute fields
Integration Risk	Possible conflicts with other pxGrid integrations	No conflicts with existing integrations
Support	Not TAC supported	Not TAC supported

The newer OpenAPI-based approach offers several clear advantages:

• More than double the device signatures (1,300+ vs. ~600)
• Simpler network requirements (only TCP 443, no pxGrid certificates needed)
• No risk of conflicting with existing pxGrid integrations
• Redis caching for optimized API lookups at scale
• Docker container support, including the ability to run directly on a Catalyst 9K switch
• Dynamic endpoint attribute verification to confirm data accuracy

Both approaches support the same set of analyzed protocols (HTTP, XML, mDNS, SSDP, SIP, SMB) and can detect randomized MAC addresses. Both scale to support over 150 collectors pushing up to 500+ updates per API call.

Practical ISE API Use Cases for Endpoint Profiling

The ISE API-driven profiling approach addresses several real-world challenges that traditional profiling cannot solve.

Wireless Networks with Minimal Visibility

Wireless networks present unique profiling challenges. Traffic from wireless clients is encapsulated in CAPWAP tunnels between access points and wireless controllers, making it harder for ISE to see the raw protocol data. By placing a collector on a SPAN port that mirrors the wireless VLAN traffic (after CAPWAP decapsulation at the controller), you can capture and analyze the full range of endpoint protocols.

Rapid IoT Growth and Randomized MACs

As the number of IoT devices on your network grows and more devices adopt randomized MAC addresses, traditional OUI-based profiling becomes increasingly unreliable. The API-driven approach shifts profiling from relying on MAC address vendor lookups to analyzing actual protocol behavior, giving you accurate identification regardless of whether the MAC is real or randomized.

Environments Where Active Scanning Is Not Authorized

Some environments, particularly in healthcare, critical infrastructure, and financial services, do not permit active scanning of endpoints. Vulnerability scanners, NMAP probes, and WMI queries are forbidden due to the risk of disrupting sensitive devices. The collector-based approach is entirely passive. It only analyzes mirrored copies of traffic that endpoints are already generating. No packets are sent to the endpoints themselves.

Better OS Visibility on Workstations

Standard DHCP-based profiling can often tell you that a device is a Windows workstation, but it may not reveal the specific Windows version or build. HTTP User-Agent analysis and SMB traffic inspection can provide far more granular OS identification, which is valuable for applying version-specific security policies.

ISE API Deployment Recommendations

Based on the patterns covered above, here are the key recommendations for deploying ISE API-driven profiling in your environment.

Use Device Sensor as Your Foundation

Before deploying collectors and API integrations, make sure your Device Sensor configuration is solid. Device Sensor should be collecting CDP, LLDP, and DHCP data and forwarding it to ISE via RADIUS accounting. This provides your baseline profiling data. The API-driven collector approach builds on top of this foundation, filling the gaps that Device Sensor cannot cover.

Start with Existing PCAPs

Before deploying collectors in production, test your analysis scripts against existing packet captures. If you have PCAP files from previous troubleshooting sessions or routine captures, run them through your pyshark scripts to validate that you are extracting the right fields and generating accurate endpoint profiles.

Limit ERSPAN Traffic with ACLs

ERSPAN can generate significant bandwidth if configured without filters. Always apply ACLs to your ERSPAN session to limit mirrored traffic to only the protocols you care about for profiling purposes. This reduces the load on both the network and the collector.

Scale Thoughtfully

The architecture supports over 150 collectors feeding data to ISE, with each API call capable of updating 500+ endpoints. However, start with one or two collectors covering your highest-priority segments (guest wireless, IoT VLANs, building management systems) and expand from there as you validate the results.

Use the Newer OpenAPI Approach

Unless you have a specific requirement for pxGrid integration, use the OpenAPI-based approach with Custom Attributes. It has simpler requirements (just TCP 443), avoids potential conflicts with existing pxGrid integrations, offers more device signatures, and can be deployed as a Docker container for operational simplicity.

Frequently Asked Questions

What Version of ISE Do I Need for API-Driven Profiling?

You need ISE 3.1 or later to use the OpenAPI for endpoint profiling. The OpenAPI must be enabled under Administration > System Settings > API Settings. The older pxGrid-based approach also requires ISE 3.1+ but has additional requirements including the pxGrid service, pxGrid probe, pxGrid certificates, and TCP ports 443 and 8910.

Can ISE API Profiling Detect Randomized MAC Addresses?

Yes. Both the older pxGrid-based tool and the newer OpenAPI-based tool include randomized MAC detection. Instead of relying on OUI lookups, the system analyzes actual protocol behavior (mDNS, SSDP, SIP, HTTP User-Agent, SMB) to determine the device type, model, and operating system regardless of whether the MAC address is real or randomized.

What Protocols Does the Collector Analyze for Profiling?

The collector analyzes traffic from the following protocols: HTTP, XML, mDNS, SSDP, SIP, and SMB. Each of these protocols carries device identification data that is not typically available through standard ISE profiling probes. The newer OpenAPI-based tool supports dynamic model and OS lookup across 1,300+ unique device signatures.

Do I Need to Use ERSPAN, or Can I Use Local SPAN?

You can use either SPAN or ERSPAN. Local SPAN works when the collector is physically connected to the same switch as the endpoints being profiled. ERSPAN is necessary when the collector is in a different location, as it encapsulates the mirrored traffic in GRE and routes it across the Layer 3 network. For larger deployments, ERSPAN provides more flexibility in collector placement.

Is This Solution Supported by TAC?

No. Both the older pxGrid-based tool and the newer OpenAPI-based tool are not TAC supported. They are community-driven solutions that leverage supported ISE APIs. The APIs themselves (OpenAPI and pxGrid) are fully supported features of ISE, but the collector tools and scripts that use them are maintained by the community.

How Does This Differ from Endpoint Custom Attributes in the GUI?

Endpoint Custom Attributes can be created and managed through both the ISE GUI and the API. The difference is scale and automation. Through the GUI (Administration > Identity Management > Settings > Endpoint Custom Attributes), you manually define attribute fields. Through the API, you can programmatically create attributes, validate existing ones, and update thousands of endpoint records automatically. The API approach is essential when you have collectors generating profiling data for hundreds or thousands of endpoints continuously.

Conclusion

Endpoint profiling is the foundation of zero trust network access, and the standard ISE probes, while valuable, leave significant gaps in visibility. Protocols like mDNS, SSDP, SIP, and HTTP carry rich device identification data that never reaches ISE through traditional RADIUS-based profiling. By deploying packet capture collectors on SPAN or ERSPAN interfaces and using the ISE API to push discovered attributes back into ISE as Custom Attributes, you can dramatically improve your profiling accuracy.

The key takeaways from this guide are:

1. Device Sensor is your foundation for collecting CDP, LLDP, and DHCP data through RADIUS accounting
2. ISE provides two API types: OpenAPI for request-response operations and pxGrid WebSocket API for persistent, real-time connections
3. Custom Attributes via the OpenAPI offer the most flexible and conflict-free way to enrich endpoint records
4. Pyshark provides an accessible Python interface for extracting profiling data from captured traffic
5. The newer OpenAPI-based approach is simpler to deploy, supports 1,300+ device signatures, and can run as a Docker container on Catalyst 9K switches
6. Always use ACLs to limit ERSPAN traffic and test with existing PCAPs before deploying to production

As IoT continues to grow and randomized MAC addresses become the norm, API-driven profiling is no longer optional. It is a critical capability for any organization serious about network security and zero trust. Start building your collector infrastructure today, and transform your ISE deployment from a basic authenticator into an intelligent endpoint classification engine.

Visit NHPREP to explore hands-on courses covering ISE deployment, network automation, and security infrastructure that will help you master these techniques in a lab environment.