I doubt that it is a BIOS issue.
Let me describe my setup. I use LUKS encryption, with an encrypted LVM. I do not use “btrfs”. I do have a separate unencrypted “/boot”.
On bootup, I am prompted for the encryption key by the kernel. The kernel itself comes from the unencrypted “/boot”.
The code that produces the login screen is all part of what is encrypted. So it just is not possible to get a login screen without the encryption key.
Now I do have another system, this time running in a KVM virtual machine. For that system, there is no separate unencryted “/boot”. So the boot prompt already requests the encryption key before I see the grub boot menu. Grub2 then loads the kernel and initrd from inside the encrypted LVM. I do have an alternative encryption key stored in the “initrd”, so that I won’t be prompted a second time for the encryption key.
In that second system, if somehow the kernel and “initrd” were copied to some place outside of the encrypted space, then it is conceivable that it could boot without me providing the key. The only place outside the encrypted space is the EFI partition. And if the kernel and initrd were copied there, my security would be compromised (but this is only a virtual machine, so not a big concern for me).
With those as comparison, I try to understand what you are seeing. Here are the two possibilities that I can think of:
(1) your crypto is compromised, and something containing the encryption key is in unencrypted space.
or
(2) only yoiur “/home” is actually encrypted, and you are booting to the login prompt which therefore does not require encryption. But you cannot login to your desktop because your home directory is still in encrypted space.
However, in case of (2), you should be able to login at a command line, but be unable to do anything because your home directory is not accessible.
Maybe something different is happening. I am not at all familiar with the veracrypt setup.