Alas, not everyone has hardware that is newer than when UEFI took off. UEFI 2.1 was introduced in 2007 but it takes a few years before mass adoption by the motherboard manufacturers. My PC's mobo build date is back to 2009, so it uses MBR. Plus, anyone wanting to multi-boot will have to disable the secure boot function. I don't see that secure boot is going to prevent a program configured to start with Windows boot. For example, Reflect can add itself as a boot menu choice. Programs can add themselves to run on Windows startup which is before Windows loads the non-critical kernel drivers. The digitally signed OS is loading specified by secure boot but how does that stop a program within Windows configuring Windows to start a program when Window starts (before loading non-critical drivers and before the normal startup programs locations, like Startup folder, registry Run keys, Logon events, logon scripts, etc).
I also don't have another host to use as a networked host for saving files to a shared volume over there. That might happen when I get around to building a new PC. However, anything that I can see then malware can see, too, like mapped drives. It is unclear in the article to which you linked if the shared volume is a mapped drive or a shared volume accessible using UNC syntax. Mapped drives are easy to find since they have a drive letter assignment and appear as local drives. UNC is a bit more difficult to ferret out unless the malware goes looking in the registry for mount points. Since the shared volume is always accessible, I don't see it offers any more protection than copying the backup files to a USB-attached drive.
I was hoping Macrium Reflect supported saving backups to an FTP server but it doesn't. The best that I can figure out is to use a post-command in the backup job to copy the backup file to an FTP server; however, that means divulging the login credentials in the command line. If Reflect did FTP itself then it could save the login credentials but use the crypto API in Windows to encrypt them in the registry or in a key file. To use an sFTP but secrete the login credentials, I'd have to use a 3rd party FTP client that can store the encrypted login credentials and also has a CLI (command line interface) to let me have Reflect run the FTP job as a post-command to a backup job but without having to specify the login credentials in the command line.
Adding an integrated sFTP client into Reflect is a long-time user request. I know Easeus ToDo Backup has a built-in FTP client; however, I am unsure if they encrypt the configuration to prevent malware from digging out the login credentials to connect to the FTP server.
I don't have another host to use for shared volumes or to run an FTP server, so those scenarios are not applicable to my home setup. UEFI might add another hurdle to malware but that isn't an option until I build my next new PC. It dawned on me that MIG is only an in-session (or after-boot) protection method which doesn't protect against boot-time ransomware.
Thanks for your reply. I'll still have to research how to protect the backup files from boot-time malware.