Make sure you never modify or write to a backup dataset. This can disrupt future incremental replications.
There’s a legacy reason for it and I never knew why TrueNAS kept it like this. There’s nothing to prevent unloading a key (“locking”) if the encrypted dataset is using a keystring instead of a passphrase.
You can lock a dataset using the command-line. Not sure how the middleware might handle it. Make sure you’re not using the filesystem and stop any shares.
zfs unload-key mypool/mydataset
This is because after unlocking it the first time, TrueNAS stores the keystring (in an encrypted form) in the database file on the boot-pool. It uses this to automatically unlock the dataset at every reboot.
If the thief knows what TrueNAS is, they can access the data if they’re able to reset the root user password. If they know some things about Linux and ZFS, they can extract the keystring from the database file.
This is unlikely. A thief might just wipe or sell your drives.
If you want to prevent access to your data and not take a chance with tech-smart thieves, then a passphrase will prevent the datasets from being automatically unlocked at every reboot. (This only applies to TrueNAS. ZFS has no auto-unlock mechanism.)
Changing the user encryption key does not change the master encryption key. You will be able to continue incremental replications like normal.
I would recommend you remember to save the new passphrase in a password manager. It doesn’t hurt to make a checkpoint on both pools (source and backup servers) before you do any of this. The checkpoints can be discarded after a day or so.