In general you don't need to bake drivers into the Rescue Media. An exception exists if the driver is necessary to even get Windows PE to boot on the hardware, but that's relatively rare. If you just want them for ReDeploy, then just having them on a storage device somewhere is fine. Not sure what the BSOD relates to, but for what it's worth I do remember seeing threads users have reported problems getting storage to be usable on a newer AMD-based system. If memory serves, AMD's implementation requires 3 separate drivers to be loaded, and they have to be loaded in a specific order. Macrium replied to that thread indicating that Reflect currently didn't have a way to accommodate that, but that they would work on it. This thread
is one example, and it includes a post from a user that quoted a response they received from Macrium Support. I don't remember seeing any updates there or in Reflect release notes since then, but they would of course know best. And to be fair, that specific case involved a RAID setup, so that may not even come into play in your case. I only mention it to make you aware that even if your Rescue Media boots, you may also encounter trouble making your storage visible in Rescue.
Also note that ReDeploy is not meant to be used to install all drivers for the new system. It only focuses on making the necessary changes and importing the necessary drivers to get Windows to start on the new system. The expectation is that you would then install any additional drivers within Windows just as you would if you had performed a clean install.
And this won't create a problem for restoring, but fyi unless your original disk included partitions that were in a format that Reflect does not natively support, there's no benefit to using the exact copy method. That's meant for unsupported file systems, encrypted partitions that are locked at the time of cloning/backup, and/or forensic data analysis scenarios.