"fdesetup add" removes secure token

Hello,

I've noticed some unexpected behavior when updating a user's FileVault password.

The set up:

• All actions are performed in virtualized macOS 14 and 15.5 guests on a 15.5 Apple Silicon host.
• FileVault is enabled.
• sjsp is a standard user with a Secure Token.
• The Mac is bound to AD, and the domain is reachable.

Reproduction:

1. systemctl -secureTokenStatus sjsp shows it's ENABLED.
2. fdesetup remove -user sjsp
3. fdesetup add -usertoadd sjsp
4. systemctl -secureTokenStatus sjsp shows it's DISABLED.
5. Surprisingly, sjsp is still able to unlock FileVault.

Looking at unified logs for opendirectoryd and fdesetup, I see that a password change is being attempted in response to fdesetup add, which is unexpected.

default	13:34:41.320883+0100	opendirectoryd	Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784)
info	13:34:41.321317+0100	opendirectoryd	No unlock record exists for E5CC46D7-0C1F-4009-8421-9AA8217CB784
info	13:34:41.321331+0100	opendirectoryd	<private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) is not a SecureToken user: no unlock record
default	13:34:41.321341+0100	opendirectoryd	Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784): user <private> SecureToken, only new password provided, credential <private>
default	13:34:41.321454+0100	opendirectoryd	Changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) with no existing unlock record
info	13:34:41.321857+0100	opendirectoryd	No unlock record exists for E5CC46D7-0C1F-4009-8421-9AA8217CB784
default	13:34:41.321873+0100	opendirectoryd	Record <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784) is eligible for SecureToken
default	13:34:41.322637+0100	fdesetup	DMAPFS cryptoUserForMacOSUserForVolume DMErr=-69594 retErr=-69594 outAPFSCryptoUser=(null)
default	13:34:41.322699+0100	opendirectoryd	While changing password for <private> (E5CC46D7-0C1F-4009-8421-9AA8217CB784): Not adding SecureToken; other unlock records exist, but no existing unlock record provided

If I disconnect the network and follow the reproduction steps then the Secure Token is retained. Reconnecting and waiting a while doesn't cause the Secure Token to be lost. There are no log entries about attempting to change the password.

Any help or explanation would be appreciated, thanks in advance.