I'm calling MTU on this problem too.
I had a similar issue where a couple of our WAN sites would not receive the accept response, and would appear as a Radius timeout error in the dashboard logs, but the request was being received by the radius server.
We use SDWan where the WAN traffic is encrypted, add this to using EAP/TLS client certificate authentication, and the packets were too big for the MTU packet size at these sites, hence were being fragmented.
You can try pinging the sites (using the -f and -l and mtu size (1180 in this example) switches e.g
ping 10.8.6.1 -f -l 1180
and check if the packet size needs to be lower at your affected sites before fragmentation (change the value (1180) up and down until you get a reply that is not fragmented), compared to your working sites
You made be able to change the MTU on your routers/switches etc at the remote site, or change the MTU size in the ISE radius config for these sites (radius connection/auth policies)
You could also try sending the requests via the Meraki cloud radius and then into your on-prem radius (put the affected AP's into a different network and change the radius destination to the Meraki cloud radius), these requests will then go out/back in unencrypted (lower packet size), which may prove if it is MTU related or not.
You can also try setting up a different authentication method, say MSCHAP, and try authenticating with client username/password only (no EAP/TLS certs), if this works then it's also most likely MTU/defragmentation
good luck