In a hospital refresh, the EHR servers sit behind a firewall that supports SXP, while the server-closet access switches support neither inline SGT tagging nor TrustSec classification and enforcement; a replacement is out of budget this year. ISE learns the authenticated endpoints' IP-to-SGT bindings through RADIUS accounting. The firewall must be able to apply policy using those bindings. Which SGT propagation design should the engineer choose?

Configure SXP between ISE and the firewall. ISE already learns authenticated endpoints’ IP-to-SGT bindings from RADIUS accounting, and SXP can convey those bindings to the firewall without requiring inline SGT tags on traffic. That fits the available equipment: the firewall supports SXP, while the closet switches need not classify, enforce, or tag packets. Populating firewall address groups from ISE accounting records and using IP-based rules is a familiar way to control traffic, but it does not make policy decisions using the learned SGT bindings. Placing the EHR servers in a dedicated VLAN and applying zone rules can protect the server subnet, but substitutes subnet membership for the endpoint-specific IP-to-SGT context the firewall must use. Periodically refreshing firewall IP address objects from accounting exports can approximate policy by endpoint address, but it still does not propagate or apply SGT bindings, and updates can leave address-based policy stale between refreshes. Exam caveat: SXP transports IP-to-SGT mappings as control-plane information; it does not add SGT tags to packets or provide enforcement by itself. Practical check: verify that ISE and the firewall establish the SXP connection and that the firewall’s learned IP-to-SGT table updates when an endpoint authenticates, changes address, or disconnects.