Hi Kevin, We're hitting the exact same malformed encoding on our team (MZR5GHAQX4 / Lumasoft LLC) and would appreciate the same kind of manual fix. The DriverKit UserClient Access capability was granted on case CC3TUTNMR7 on 2026-05-05. The malformed array reproduces today (2026-05-10) on freshly regenerated provisioning profiles — single 77-character string with an embedded \n at offset 38: 'co.lumasoft.lumabooth.dnpprinterdriver\nco.lumasoft.lumashare.dnpprinterdriver' array.count == 1, type == str. Affected App IDs (the host-side ones — the DEXTs use allow-any-userclient-access and don't need this list): co.lumasoft.lumabooth co.lumasoft.dnpdriverhost co.lumasoft.lumashare The intended values (separate array entries): co.lumasoft.lumabooth.dnpprinterdriver co.lumasoft.lumashare.dnpprinterdriver Runtime consequence: IOServiceOpen() from the host returns kIOReturnNotPermitted (-536870174) because no valid bundle ID can match the malformed entry. The DEXT itself matches IOUSBHostInterface, opens it, and copies bulk pipes correctly — failure is strictly at the kernel-side host entitlement check. Confirmed not bypassable by running as root. Tier-1 support case 102887359854 was deflected to the forums, so following that direction here. Would you be able to re-enter the array on the affected App IDs the same way you did for the OP? Happy to provide our decoded profile or security cms -D -i output by DM / radar if helpful. Also filed Feedback Assistant feedback for the portal-side encoding so a permanent fix can land downstream. Thanks