Driver submission fails Scanning with 4001 BlockingDetectionFound only when the firmware payload is encrypted

We ship firmware for a USB-attached camera through a SoftwareComponent driver package. The package carries a small executable and a firmware image; Device Setup Manager launches the executable, which streams the image to the camera over USB. The firmware image is the camera's own firmware, not Windows code, and the executable is the only Windows PE binary in the package.

We have had several packages of this exact design certified. The one package whose firmware image is encrypted is also the only one that fails: the component submission is blocked at Scanning with

Scanning Notes
{"code":"4001","details":{"errorInfo":"BlockingDetectionFound"},"innerError":null}

Repeated submissions produced byte-identical reports, so the verdict is deterministic.

Controlled test (attestation CABs)

In the variant, the executable, the INF and every other payload file are byte-identical to the baseline. Only the firmware entries changed, from plain gzip to encrypted; the catalog was regenerated solely because the payload hash changed. The CAB sizes differ by 0.1%, so size is not a factor.

We also scanned the packages and their extracted contents with Microsoft Defender (current signatures at the time, PUA protection on) and got no detection at all. We understand a local scanner is not the same thing as the submission scanning service, and that it cannot look inside the encrypted entries either; we mention it only to explain that we have no local signal to work from.

We ruled out the obvious alternatives as well. A companion submission from the same account, signed with the same certificate and submitted the same day, carries no firmware payload and passes every stage. Another package of this design with an unencrypted payload, re-uploaded the same day, passed Scanning again. And the encrypted payload submitted through a second route produced a byte-identical report, so the verdict does not depend on the submission route.

So: the same payload passes in the clear and fails once encrypted.

Questions

1. Is a payload the scanner cannot decrypt an expected, by-design block?
2. If the payload must be inspectable, which is the supported pattern for a software component that delivers device firmware: (a) ship the firmware unencrypted and rely on the device's own signature verification, (b) keep it encrypted but use a different container, or (c) do not ship the firmware in the package at all and have the component download it at runtime?
3. Has anyone else hit this, and did you find a packaging pattern that passes?

We have an open support request with the submission IDs; happy to share those privately with anyone from the hardware team who can look them up.

Encrypting the firmware comes from our product security requirements, so we would rather re-package it in an acceptable form than simply drop the encryption, if a supported form exists.