I85PREP
⌘ K
Cisco 300-715 SISE study materials
Cisco 300-715 SISE study resources

Profiling Medical Devices and CoA on Profile Change

Cisco 300-715 SISE · Put your knowledge to work in context.

All case studies

Profiling Medical Devices and CoA on Profile Change

Valley Regional Hospital has 2,400 endpoints across three PSNs. Profiling uses DHCP, CDP/LLDP, HTTP, and NMAP probes. Medical devices sit on VLAN 40, printers on VLAN 50, and personal phones on the guest SSID. A profiling policy named 'Cisco-IP-Phone' is matching 180 infusion pumps because the DHCP fingerprint is similar; a 'Windows10-Workstation' policy is matching 200 personal iPhones due to randomized MAC addresses. Authorization policies use device profile conditions to assign a dACL that limits access to the clinical VLAN. When a device is re-profiled from Unknown to its correct profile, the switch port does not change authorization until the session reauthenticates 8 hours later. Some ports have static SGT assignment, but the SGT is not reflected in the authorization result. NMAP scans run weekly and cause latency on the PSNs.

1. How would you redesign profiling so the infusion pumps are not misclassified as IP phones, and what probe trade-offs matter?

Read the worked answer

The misclassification is a certainty problem: DHCP alone is not enough because many devices share vendor-class patterns. Use independent probes and require multiple conditions before the pump profile wins.

  • Add SNMP to the access switches to read MAC address tables and CDP/LLDP neighbor data; enable LLDP on the medical-device ports.
  • Build a custom pump profile with at least two conditions: the DHCP vendor class string from the pump vendor, the MAC OUI range assigned to that vendor, and the LLDP system description. Set the certainty factor so no single probe can match the profile.
  • Keep the IP-phone policy but add a negative or lower-certainty condition so the pump's OUI cannot satisfy it.

Probe trade-offs:

  • DHCP is cheap and gives hostname/vendor class but is easy to spoof or share.
  • CDP/LLDP is strong for network-attached devices but not all medical devices speak LLDP.
  • HTTP gives User-Agent but many devices never send HTTP.
  • NMAP is active and expensive. Weekly scans of 2,400 endpoints from a PSN cause CPU and latency; restrict NMAP to unknown endpoints or a maintenance window, not a global scan.

2. Why does a profile change not update the switch port authorization, and what controls must be enabled?

Read the worked answer

A profile change does not automatically rewrite an existing authorization result. The authorization policy must reference the profile, and ISE must send a CoA when the profile changes.

Check:

  1. The authorization rule has a condition on EndpointProfile or the logical profile name.
  2. The PSN has CoA on Profile Change enabled.
  3. The switch supports RFC 5176 CoA, the CoA port is correct, and the shared secret matches.
  4. The endpoint session is still active; a stale session cannot be updated.
  5. The 8-hour reauthentication timer explains the delay even if CoA is configured but failing.

A practical design is to set a shorter reauthentication timer for Unknown endpoints, such as 1 hour, and a longer timer for known devices, such as 8-24 hours. Enable CoA on profile change so the correct dACL is applied as soon as the profile is confirmed. Verify with the switch's authentication session output and ISE's CoA live log that the CoA reaches the correct NAD IP.

3. How should the design handle randomized MAC addresses on personal iPhones, and why is MAB unreliable for them?

Read the worked answer

Randomized MAC addresses break MAB and MAC-based profiling because the address changes per SSID and sometimes per session. If each random MAC creates a new endpoint, the endpoint database grows without providing stable identity.

Handle it as an onboarding problem, not a profiling problem:

  • Enable ISE's MAC address randomization detection where supported.
  • For personal phones, use a guest or BYOD flow with device registration, not MAB. The user identity becomes the anchor.
  • For managed devices, use EAP-TLS with a device certificate so identity does not depend on the MAC.
  • If MAB must remain for legacy devices, treat randomized MACs as low certainty and do not let the Windows10 profile match solely on OUI. Add DHCP fingerprint and posture or registration data.
  • Add an authorization rule that sends randomized-MAC endpoints to the BYOD or guest portal instead of the clinical VLAN.

Also check the WLC for MAC filtering or random-MAC handling, because the controller may present a different address than the endpoint expects.

4. What is the likely cause of the static SGT not appearing in the authorization result, and how do you verify it?

Read the worked answer

Static SGT assignment can override or conflict with the SGT returned by ISE. On some Catalyst platforms, an interface-level static SGT or manual TrustSec configuration takes precedence over the dynamic authorization result, so ISE's SGT never appears in the session.

Check the switch configuration for interface-level cts manual, static SGT commands, or a static SGT map for the endpoint IP. If dynamic assignment is intended, remove the static configuration from those ports. Then verify:

  • The authorization profile returns an SGT.
  • The switch supports SGT assignment from CoA.
  • The SGT is not being overwritten by a static mapping on the switch.
  • Use show cts role-based sgt-map and show authentication session to compare the configured and applied SGT.

If the SGT must cross a non-TrustSec hop, verify SXP or inline tagging, because a missing SGT in the path can make the enforcement point see the default SGT instead.