But yeah, also rather obviously it's inherently a bit leak-prone. Though it seems probably pretty simple to test, just hibernate and scan all stored data. They could probably even do it on shutdown, as a hash of the key data would be sufficient to detect the key.
(You don't mean BitLocker, right?)
But I would never trust it a second, being proprietary and known for issues. You likely know that, but for the benefit of others:
38C3 - Windows BitLocker: Screwed without a Screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou... https://www.youtube.com/watch?v=5eNtT2p12cM
https://learn.microsoft.com/en-us/windows/security/hardware-...
> For systems with TPM 2.0, the TPM is configured by Windows to lock after 32 authorization failures and to forget one authorization failure every 10 minutes. This means that a user could quickly attempt to use a key with the wrong authorization value 32 times. For each of the 32 attempts, the TPM records if the authorization value was correct or not. This inadvertently causes the TPM to enter a locked state after 32 failed attempts.
> Attempts to use a key with an authorization value for the next 10 minutes wouldn't return success or failure. Instead, the response indicates that the TPM is locked. After 10 minutes, one authorization failure is forgotten and the number of authorization failures remembered by the TPM drops to 31. The TPM leaves the locked state and returns to normal operation. With the correct authorization value, keys could be used normally if no authorization failures occur during the next 10 minutes. If a period of 320 minutes elapses with no authorization failures, the TPM doesn't remember any authorization failures, and 32 failed attempts could occur again.
Depending on how serious you are you also don't consider MacOS.
And then you kinda have a couple of things to chose from but ultimately you need to build your own security depending on your attack/threat model
But also, threat models and the best way to mitigate them aren't really a linear scale of being <unserious> to <serious>, but a complex consideration of a particular situation.
BitLocker with a password (the equivalent of the LUKS configuration in question) does not share these issues.
It is annoying that they hate password for system drive _so_ much; the reason is actually pretty obvious when you think about how their "happy path" AD-driven enterprise deployment with stupid password rotation requirements works (and FileVault is a nightmare in this scenario), but I wish they'd make it easier for individual power users.
I can understand the default being TPM-only + online key backup, huge amounts of the population forget their login passwords (which can be involuntary, e.g. head injury) and huge amounts of them still want some backup way to access their data rather than losing it forever.
But for anyone who cares just a little more, or would prefer to lose data in those situations, it's such an abnormal and hidden path that it's clearly blocking tons of people from choosing it.
https://www.forbes.com/sites/thomasbrewster/2026/01/22/micro...
So take countermeasures if you print something out criticizing any groups that abuse political or law-enforcement powers.
Unfortunately Microsoft keeps working to destroy that option and force consumers to make a remote account. [0][1] Their consistent moves towards wanting to co-own my computer were one of the many last-straws that made me migrate everything to Linux this year.
> Local-only commands removal: We are removing known mechanisms for creating a local account in the Windows Setup experience (OOBE). While these mechanisms were often used to bypass Microsoft account setup, they also inadvertently skip critical setup screens, potentially causing users to exit OOBE with a device that is not fully configured for use. Users will need to complete OOBE with internet and a Microsoft account, to ensure device is setup correctly.
[0] https://blogs.windows.com/windows-insider/2025/10/06/announc...
[1] https://www.windowslatest.com/2025/10/07/microsoft-confirms-...
'Happily' is also a stretch, as they really don't have a choice if served a valid court order.
If you want encryption that is safe from the US government, keys need to be stored in your head. Anything physical is subject to court orders.
It's still brittle, awkward and puzzlingly awful UX despite being the literal standard for the platform.
Compare it to any of the actively maintained alternatives, Filevault for MacOS (which is wonderful and never sends your key to be kept somewhere else) or LUKS on Linux.. heck, even Veracrypt is actually easier to understand and more robust.
no, i mean great.
managing a fleet of 100+ laptops with bitlocker is a breeze. its so seemless that the users don't even realize its enabled (i.e. no UX issues, at all).
on the other hand, i am not managing 100+ laptops that use veracrypt. sounds absolutely awful. i've never managed an apple fleet, so i can't speak to that, and will take your word on it.
for personal use, i do not recommend bitlocker (or windows, really), but for already-windows enterprises? absolutely
Brittle is what happens when you haven't logged on to the machine in 60 days, trust with AD is broken, TPM has a glitch and wipes the in device key and forces you into recovery... or god forbid you service the laptop and now you have to enter recovery mode.
Then you're in a nightmare, trying to give someone a super long passphrase over the phone is a not-too-uncommon occurance.
That's assuming you have a good policy for storing the recovery keys. Too loose and they're handed out to everyone, sort of defeating the purpose: too strict and you need the IT department (or specific members), and its still predicated on the notion that you have a policy for it... Given that Admins are a dying breed... I don't think this is workable.
If you compare with Filevault on MacOS: which tracks the credentials of the logged in user; there's no "issue" if the device loses trust because ultimately you always use the real unlock key: not something cached in a "secure storage".
I think both approaches are valid trade-offs and I think that the default Secure Boot BitLocker configuration, for all its architectural tradeoffs, can probably be credited for an enormous amount of data loss mitigation originating from used hard drives alone.
If I as an admin give you your key: it is “leaked” effectively.
hoping users don’t forget their password is a very weak policy.
specifically, the policy and admin points you brought up above, how does veracrypt solve them?
What is brittle or awkward?
Where is it?
A) Uploaded to microsoft
B) Somewhere in EntraID?
C) Somewhere in our onprem AD?
D) Written down on a scrap of paper when I set up the laptop
the fact that they never ask for the passphrase is a weakness of the system. Because now you have an extremely difficult situation as soon as you're off the happy path.
It's also like 64 characters alphanumeric with no capability to copy/paste.
Compare it to Vera/Filevault where the access key is the users passphrase. In MacOS it's literally your account password, which follows along with your in-OS account credentials.
Did you read the documentation?
https://support.apple.com/guide/mac-help/protect-data-on-you...
"iCloud account: Click “Allow my iCloud account to unlock my disk” if you already use iCloud. Click “Set up my iCloud account to reset my password” if you don’t already use iCloud."
https://developer.apple.com/documentation/devicemanagement/f...
"FileVault Full Disk Encryption (FDE) recovery keys are, by default, sent to Apple if the user requests them. Only one payload of this type is allowed per system."
If you click "Allow my iCloud account to unlock my disk", your recovery key is escrowed to Apple, tied to your Apple Account.
If you don't select that option it never does.
I should have said "without your explicit permission", but I assumed we were all adults and understood that.
The main point is that it's using your account password to unlock, the recovery key is for if you forget your account password.