Profiling Deep Dive: How ISE Knows a Camera Is a Camera

By Taylor Thomas · 2026-08-30

A network access policy is only as good as its knowledge of what is connecting. Users authenticate, but many of the cameras, printers, badge readers, and sensors that now outnumber them on access layers either cannot support an acceptable authentication method or were never provisioned with one, so they arrive on MAC Authentication Bypass instead. ISE profiling exists to answer the question those devices cannot: what is this endpoint? The answer is built the way a detective builds a case — by accumulating evidence until confidence crosses a threshold.

Probes: Where the Evidence Comes From

The profiler’s raw material is endpoint attributes, and probes are its collectors. The RADIUS probe mines authentication and accounting traffic ISE already receives. The DHCP probe reads option fingerprints — the option sets and parameter request lists that differ tellingly across operating systems. The HTTP probe captures user-agent strings where web traffic reaches ISE, such as portal flows. DNS resolves the endpoint’s name for clues; the SNMP query probe interrogates network devices about what they see on their ports, while the SNMP trap probe passively receives link and MAC-change notifications that prompt those queries; NetFlow contributes traffic behavior; the Active Directory probe enriches Windows endpoints with domain data. The NMAP probe is the bluntest instrument of the set: rather than collecting what infrastructure already observes, it actively scans the endpoint itself to elicit open ports and OS hints.

The elegant supplement is Device Sensor. Rather than hauling raw traffic to ISE, a supported Cisco access switch — once the feature and RADIUS accounting are configured — collects CDP, LLDP, and DHCP attributes right at the port and delivers them inside RADIUS accounting messages. The profiler gets edge-quality evidence with no SPAN sessions and no separate collection infrastructure — on a Cisco access layer that supports it, this is the design to prefer.

Certainty: How Evidence Becomes a Verdict

Attributes alone classify nothing. Profiling policies turn them into verdicts through a weighted scoring model: each rule a policy defines — matching this OUI, that DHCP class identifier, this CDP platform string — carries a certainty value, contributed when the rule matches, and the policy qualifies only if the accumulated certainty meets its minimum certainty factor.

Policies are organized in a hierarchy, but the scoring is what decides the outcome: when more than one policy qualifies, ISE selects the one with the highest accumulated certainty. Cisco’s built-in child profiles rest on additional, more specific evidence than their parents, so they generally outscore them — which is why an endpoint whose attributes satisfy Cisco-Device generally and Cisco-IP-Phone specifically ends up profiled as the phone. Hierarchy expresses the taxonomy; certainty, not depth, wins the contest — worth remembering when writing custom profiles. Endpoints that never accumulate enough certainty for any profile remain Unknown, which is itself usable policy input: an access layer where Unknown maps to a quarantine-grade authorization result fails safely. Cisco also ships and updates the library of prebuilt profiling policies through the ISE Feed Service, so the common device population does not have to be described by hand.

From Profile to Policy

Classification pays off at the authorization step. Authorization rules match on the endpoint’s assigned profile or on endpoint identity groups tied to profiles — the camera profile leads to the camera authorization result, with the VLAN, ACL, or Security Group Tag that access design assigns to cameras. This is how MAB-class endpoints get differentiated access instead of one flat bypass network.

Profiles also change. A port that authorized an endpoint as Unknown may learn, minutes later, that it is a printer; a device that looked like a phone may start behaving like something else. When profiler CoA is configured and the network device supports it, an eligible profile transition on an active session triggers a Change of Authorization — a reauthentication or the configured CoA action — so the session is re-evaluated against the new classification without waiting for the next reauthentication timer. Classification stays live, and so does the policy built on it.

What a Profile Is Not

Profiling deserves one hard boundary: it is classification, not authentication. Its evidence is non-cryptographic, and the inputs an endpoint controls — MAC address, DHCP fingerprint, protocol chatter — can be imitated by an attacker who owns the device. Multi-attribute policies raise the imitation cost, but the principled defense is scoping: profile-derived access should be narrow and purpose-shaped, a printer VLAN that reaches print queues and nothing else. Sensitive access should normally require the far stronger identity assurance of certificate-based authentication — EAP-TLS. And where endpoint capability and risk policy justify it, posture asks a different question than profiling does: not what a device is, but what state it is in.

On the certification path, profiling carries its own domain: the SISE 300-715 blueprint dedicates Domain 4 to the Profiler — implementing profiler services and implementing probes (objectives 4.1 and 4.2). The exam-ready understanding is the one built here: name the evidence sources, explain how certainty turns evidence into classification, and say precisely what that classification should and should not be allowed to unlock.

Frequently Asked Questions

What is the certainty factor in ISE profiling?

A weight-based scoring system. Each rule in a profiling policy carries a certainty value, contributed when that rule's conditions match the endpoint's collected attributes, and a policy qualifies only when the accumulated total meets its minimum certainty factor. When multiple policies qualify, ISE selects the one with the highest accumulated certainty — and because Cisco's built-in child profiles rest on additional, more specific evidence that outscores their parents, a device that qualifies as a Cisco device generally and an IP phone specifically ends up profiled as the phone.

Do I need SPAN sessions to feed the ISE profiler?

Usually not on a supported Cisco access layer. Device Sensor on the switch, once configured with RADIUS accounting, collects CDP, LLDP, and DHCP attributes right at the port and ships them to ISE inside accounting messages — high-value attributes that for many deployments reduce or eliminate the need for a SPAN-based collection path, with sufficiency depending on the endpoint population and the other probes the profiling policies require. DHCP helper-based collection and SPAN both remain options where Device Sensor is unavailable, but SPAN duplicates traffic toward ISE and scales poorly, so treat it as the fallback rather than the design.

Can an attacker defeat profiling by spoofing a printer's MAC address?

Spoofing a MAC is trivial, which is exactly why profiling is classification rather than authentication. Good profiling policies rest on multiple attribute sources, so a bare MAC clone with the wrong DHCP fingerprint and protocol behavior accumulates less certainty — but a determined attacker can imitate more attributes. The defense is scoping: profile-derived access should be narrow (a printer VLAN that reaches print queues, not the data center), while sensitive access should normally require strong cryptographic authentication such as EAP-TLS.