o/ Some extra input since Mike pinged me:
how do you manage passphrases in that scenario without user simply overwriting your recovery passphrase?
If you mean “how do you add more than one passphrase to a drive”, LUKS supports this natively as Mike mentioned. There are multiple “key slots” on a LUKS-encrypted drive. Each slot corresponds to one passphrase. You can program your master admin passphrase into one slot and the user’s personal passphrase into a second slot, and be good to go. You can install the same master admin passphrase on all machines. Each user has to remember their own passphrase (or have a hardware security device like a Yubikey that is properly bound to the disk), but the admin needs to only know the master passphrase. About the only time I can see this not working is if IT needs to gain remote access to an encrypted machine without the user having to explicitly decrypt the drive. Even then though there are solutions like Intel AMT that may allow working around that limitation.
If you mean “can the user be prevented from deleting the admin key”, well, not really. The passphrase data is stored on the disk, if the user overwrites it then the passphrase won’t work. Really any mechanism for FDE that stores key info on the disk will have this issue though, and even if you avoid that, a malicious user who wanted to hide their activity could always just wipe the disk. So I don’t think this is really an attack scenario you can defend against with technical means. Instead you’d want rules like “anyone who locks IT out of their machine is suspended for a week and will be fired if they do it twice.” (Or something like that - obviously in practice you may want to be even more strict but you get what I mean.)
Personally just from a security standpoint, I don’t think TPM-based disk encryption is probably a good idea in general. The reason is because it makes your encryption security only as good as the security of the lock screen. What I mean by that is, if you use TPM-based encryption, the system will automatically decrypt itself on startup, and then present the user with the lock screen. At that point, there’s no need for an attacker to break the encryption. All they have to do is figure out an exploit in the lock screen and boom, they’re in. For a developer machine that may be running SSH or other server software, this risk grows exponentially since now there are other potential points of entry a malicious user can attack. They just have to steal the laptop, attach it to their network, power it on, and then find an RCE in whatever exposed servers there are. If they’re smart and block the ability for the machine to get automatic software updates (via a firewall), they can just wait for a new RCE exploit to be found in whatever server software the machine happens to be running, and then break in that way. The encryption prevents trivial ways of getting in like booting from a USB stick or placing the drive in another computer, but it doesn’t prevent exploiting the target system’s software stack.
Compare this to passphrase-based encryption. You no longer are depending on the security of the software to keep the data safe, you’re depending on the security of a cryptographic algorithm. Traditionally, cryptographic algorithms have had WAY less holes in them than modern-day software, and the holes that do exist are of no practical value to an attacker. No matter what kind of arcane tricks an attacker may use to run arbitrary code on the machine or whatever, they can’t get in without knowing the encryption key, and the encryption key isn’t anywhere on the machine. Your data is safe.
LUKS is, to my awareness, filesystem-agnostic, so whether you use ext4, BTRFS, XFS, etc., it should all work the same. I run BTRFS+LUKS at my workplace on a Kubuntu 24.04 machine, and it works great.
Hope this is helpful!