If persistence is correct, it would have to be on the NAS side, i.e. it accepted a new connection from a new OS without authentication simply because the source IP matched (presumably). A NAS that did that would not sit well with me. Client-side persistence would not explain this behavior because your main Windows OS and Rescue are completely different operating systems, so there would be no connection state or credential cache sharing between them.
Reflect V6 didn't have Edit Defaults > Network because it used the credentials of the scheduled backup user for NAS authentication (or those of the logged-on user for jobs run interactively). The Network interface was added for V7 because it switched to running the job itself as SYSTEM, initially as the sole option and later just as the default, which created the need for an alternative means of authenticating to network resources, and since you posted this in the V7 section, my answer pertained to V7.
Of course any credentials added to Network after
you built your Rescue Media would not be cached on it, and I don't know if just generating new Rescue Media would be sufficient to update it or if you'd have to go through the entire Rebuild process. But if you're running in "V6 mode", i.e. specifying a scheduled backup user other than SYSTEM under Edit Defaults > User and using those credentials to talk to the NAS, then I don't think my earlier post would apply because I don't think Reflect caches those credentials in Rescue Media. After all, those credentials are for an admin account in the "live" Windows environment and won't necessarily be used for anything else like NAS authentication, so they wouldn't necessarily be useful in Rescue.-- and for people who need NAS authentication, V7 has an alternative that Macrium recommends using instead as a best practice.