Thanks Kevin, that's helpful, and it matches what we're seeing. Filed as FB24887479. On your three points: Detecting it at creation. Understood, and that matches our result. We tried every property on both streams and found nothing that separates a session that will receive from one that won't, so we're not holding out hope there. The fault being in the lower level system. Agreed, and one thing supports it that we hadn't mentioned. When we release an affected session and open a new one on the same accessory, EAAccessory.connectionID does not change, yet the new session receives normally. Nothing about the physical connection or the accessory changed, so whatever is wrong is state that belongs to the session, below where we can see it. Recreating sessions. You said you wouldn't expect it to help, so this may be worth knowing: in our testing it does, consistently. The replacement session answers the same command in about 2 ms right after the previous one couldn't receive it at all, and in one batch it fired 9 times and recovered 9 times. That's what makes us doubt the recovery is coincidental. On unplugging being the only reliable option, that's the part we can't take. This is smart card middleware used for authentication, so asking the user to pull and reinsert the key mid operation isn't something we can ship. So the question that decides it for us: does opening a new EASession actually rebuild the per session state on the system side, or are we winning a race that could stop working in a future release?