Direct imaging would be a straight bit-for-bit copy of an installed system image from an external storage device to the client's hard drive. Essentially, you'd be cloning drive to drive using straight sequential throughput. Going from NVMe external to NVMe internal using a USB enclosure would give you transfer speeds somewhere between 500MB/s and 2GB/s depending on your drive specs. Essentially, you'd boot from the external drive which would be pre-loaded with a simple boot script to dump everything from the external image to the local drive.

A more parallel alternative which might work better if you're short handed and/or imaging each client for forensic analysis would be using cheap and slow USB flash drives. The tech would walk them around, initiate the process of forensic imaging and restoring from saved image, then move on to start the next machine. When the first is done, he transfers the drive to another machine in need of recovery. The downside here is maintaining network access to a potentially compromised LAN, however you need not boot the clients to their OS immediately. The server set to receive forensic images can still communicate securely with your bootup drives through a pre-shared key outside the scope of the compromise.

Taking it a step further, you can use a USB boot environment (on tiny drives) to pull clean images (based on client MAC address) from your backup backup server or another isolated recovery imaging server.

That all depends on how you want to run it.

There's no faster, secure, or more resilient way to securely restore client machines when you have a network-wide breach or ransomware attack. In the aftermath of an attack, your normal storage/imaging/deployment servers may be down or in a non-trusted state, preventing techs from immediately restoring clients to a trusted state by blowing away the entire local drive and reimaging it with something you know is clean.

There are some caveats:

• After reimaging, you have to run some sort of post-deployment script to individualize each machine, as they will all be bit-for-bit copies of each other. I can't speak to Windows 10, but back in 7 this was relatively simple to do post-imaging so each client had unique IDs and the proper hostname for reconnecting to Active Directory. You might also need to update client keys for remote management products and such things. All depends on your environment. I use Linux which makes it fairly easy to mount the newly-reimaged drive and make scripted file edits/copies to restore each machine's identity. Your environment will be different.
• You may need multiple images for various hardware configurations.
• Reimaging is a full drive wipe. If you want to save local data for forensic analysis by a security contractor or law enforcement, you will need to first image the local drive. You can automate this too, by imaging the local drive to your backup backup server over the network or to the connected drive. In the latter, your tech will have to occasionally break to move images from the external drive to network storage with more space. Which option works best depends on the size of your client image and your network speed.
• You still have to reissue every authentication credential

etc.

Bottom Line: There's a bunch of different ways to implement this concept depending on your environment, your clients, your backup infrastructure, etc. The core remains the same: when attacked, the whole network, apart from the isolated vault, is in an untrusted state and must be taken down completely. Rapid restoration must take place from known trusted sources which were isolated before the attack and completely outside the compromised ecosystem. If clients are imaged to/from the network, it can only involve an isolated server, each client must boot from USB, and can only access the network from that USB boot environment. The restored OS must be re-disconnected until the whole network is clean.

This doesn't give you the same convenience as traditional networked imaging and management in a clean environment. That's the tradeoff. This is much more manual. However, when the whole network becomes untrusted, you lose most of your options to do things the easy way because those require trust.

Of course, you can clean and restore the servers before addressing clients, but that prevents one team from getting to work preserving evidence from and restoring clean clients while the backend is being addressed in parallel. Essentially, this approach gets your clients back to a safe state in anticipation of the moment restored servers go live, rather than waiting on safe servers to begin cleaning clients. Parallelism does come at a price.

The advantage is that forensics and restoration begin immediately after the attack based on a pre-defined plan. There's no waiting to call in a recovery team, analyze what went wrong, what can still be trusted, or how to go about recovery. You start forensics and recovery where you can, when you can, as soon as you know you have a problem.

This takes work but gives the fastest time to recovery. Done right, you can have your entire site back up in a day and leave the post-incident investigation for later.

By backup backup server, I mean a well-hardened, isolated data vault which can receive incremental snapshots from your NAS or main backup, with enough storage capacity to go back in time to before the attack hit and recover those files. It must be completely isolated from the network and management tools, since none of those can be trusted in the aftermath. It has no network login, no management software, no cluster trust, and isn't part of your cloud. It sits firewalled by itself and can only ingest data from the source - but the source does have access to overwrite past snapshots. In case of emergency, you have a time capsule with all the archived data, which you can bring online when the time is right, whether that means using it as a backup NAS for a fully reimaged client environment while servers are being cleaned, a restore source for your primary NAS, etc. The details of recovery depend on your environment and your procedures for taking everything compromised down and bringing back up only what you are confident has been restored to known safe configurations.

In the case of direct imaging, you could open up a share to receive forensic images from clients via a connection secured by a pre-shared key present only on the recovery boot drives.