One of my customers (bank) and I decided not to profile for the same reason as you described - old Windows version, and locked down. So we agreed to make an Endpoint Identity Group and put all the MAC addresses of all the ATMs there. They don't have thousands of ATMs, and adding these addresses (based on the low rate of install of ATMs) does not cause them operational overhead. The ISE AuthZ Profile for ATMs should be as restrictive as you can make it - that is probably the best thing you can do. Upstream firewalls should of course also limit the scope of the ATM traffic.
Profiling does not add any security to the MAB process, because a bad actor can spoof anything. Profiling is just a very nice convenience feature.
One mechanism is to use ISE dynamic VLAN assignment for such endpoints. By forcing the VLAN through ISE, it will limit the abuse of MAC spoofing, depending on how you do AuthZ generally. e.g. if you simply return an Access-Accept for MAB, and not perform VLAN Assignment, then it means whoever steals a MAC address (e.g. of a camera), can clone that on their device and plug their device into a port used by Corporate PCs. ISE will think you pugged in a camera, return Access-Accept, and the bad actor is on a switchport with a static VLAN for Corp Data. That's bad news. However, one mitigation is to set the VLAN to the one used by cameras. Now the bad actor is on the camera VLAN, instead of the Corp Data VLAN. Some reduction in risk.
Dynamic VLAN assignment can cause a lot of troubles with DHCP (VLAN switching after DHCP for non-WIndows supplicant) - if that is an issue, then you can also configure your switches to send you the configured access VLAN during Authentication - you can then make an AuthZ decision about what to do - e.g. if the VLAN is a Corp Data VLAN and the MAB should return a Camera AuthZ profile, then you can send back an Access-Reject because something smells fishy.
