What The NCSC Has Been Telling You About BitLocker For Years
Hello, Mauven here.
Four days after a researcher published working code for a Windows zero-day called YellowKey, the most useful thing I can tell you about it is something the National Cyber Security Centre has been quietly saying for years.
The NCSC’s Windows device security guidance, the public version anyone can read, has long included this line. “Configuration of BitLocker encryption settings to prevent data extraction using physical attacks. Using a TPM with PIN and Full Disk Encryption is recommended.”
Recommended. Not optional. Not “consider it.” Recommended, as a control against physical attacks, on the website of the United Kingdom’s national technical authority for information assurance.
Most UK organisations did not bother.
I want to talk about that gap. Because the technical detail of YellowKey, which my colleague Noel has already covered with his usual restraint and good cheer, matters less than the slow embarrassing fact that this scenario was already addressed by guidance most companies have ignored for the better part of a decade.
The Advice Was Public. The Deployment Was Not.
There is a particular kind of professional discomfort that comes from reading a vendor advisory or a researcher disclosure and recognising that the published mitigation is something your sector has spent years collectively pretending was optional.
YellowKey is that experience for anyone responsible for Windows endpoint policy in a UK organisation.
The NCSC’s guidance is sitting where it has sat for years. The same page advises Direct Memory Access protections, external interface controls, and biometric or modern authentication standards alongside TPM with PIN. Microsoft’s own BitLocker countermeasures documentation on Microsoft Learn says preboot authentication “provides extra protection for BitLocker” and that BitLocker accesses encryption keys “only after preboot authentication is completed.”
None of that language is new. None of it was uncovered by clever investigation. It is the default state of public, free, government-issued technical guidance.
The thing that has changed in the last week is the cost of having ignored it.
The “Appropriate Technical Measures” Test
This is where it stops being a procurement debate and starts being a legal one.
Under UK GDPR Article 32, a controller must implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk.” Under Article 34, the duty to notify individual data subjects of a breach does not apply where “the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption.”
That is the bit organisations like to wave at the regulator when a laptop disappears. The data was encrypted. Article 34 protection. No individual notification required. Move on.
The Information Commissioner’s Office is consistent on the underlying principle. Encryption is “especially effective in protecting the information from unauthorised access if the device you use to store the encrypted data is lost or stolen.” So far, so familiar.
But the legal question is not whether encryption was on. The legal question is whether the technical measures were appropriate, and that word is doing serious work. “Appropriate” is contextual. It is judged against the state of the art, the cost of implementation, and the nature of the risk. It is also judged against published guidance, including, although the regulator is not bound to cite it, the guidance from the national cyber security authority.
In May 2026, with a publicly available, independently reproduced bypass against the TPM-only configuration, defending the appropriateness of a TPM-only deployment is materially harder than it was a fortnight ago. The fact that the alternative was specifically named in NCSC guidance for years makes the argument harder still.
That is the regulatory shift. Not a new offence. A higher evidential bar for the same defence.
The Cyber Essentials Gap
A second uncomfortable fact, because I am evidently in that sort of mood today.
Cyber Essentials, the UK government’s baseline certification scheme, requires that devices be securely configured and that data be encrypted at rest where appropriate. Like many UK organisations, you may hold the certificate. You may have done so for years. The scheme is genuinely useful as a baseline, and I am not going to be the one to argue against it.
What the scheme does not require, in the publicly available self-assessment workbook as of this writing, is BitLocker configured with TPM plus PIN specifically. So you can hold a Cyber Essentials Plus certificate, deploy your fleet on TPM-only BitLocker, and be exposed to a public bypass that defeats your data-at-rest control for stolen Windows 11 laptops.
That is not a scheme failure. Baseline certifications are floors, not ceilings, and they have always been described that way by the people who run them honestly. It is the gap between certification and current threat that matters, and that gap widens every time a new researcher decides to spend their Tuesday afternoon disclosing something inconvenient.
The right response is not to deride the certificate. The right response is to stop treating it as a complete answer.
What The Silence Probably Means
A note on the official UK silence on YellowKey, because I have been asked about it more than once this week.
As of writing, the NCSC has not issued a YellowKey-specific advisory. There is no UK government public statement naming the vulnerability, recommending action, or coordinating disclosure. The official channels are quiet.
This is not unusual and it is not, in my reading, a sign of anything sinister. The NCSC’s standing remit on vulnerability advisories is broadly to publish when there is a coordinated vendor response, when there is critical national infrastructure exposure that needs urgent action, or when the existing public guidance does not cover the scenario. YellowKey, awkwardly, fails all three tests at once. Microsoft has not yet issued a patch. The exploit requires physical access, which constrains the scope. And the existing NCSC guidance already addresses the mitigation in detail.
So expect the official UK response to look like one of three things. A future joint statement when Microsoft ships a fix. A pointer back to existing guidance, possibly with refreshed emphasis. Or nothing in particular, because the people writing the advisories will judge that the published guidance already does the job, and that adding another short note risks implying that the previous guidance was less serious.
If you are looking to UK officialdom to tell you whether YellowKey is your problem, you are looking in the wrong direction. The guidance has been there for years. You are now expected to have applied it.
How To Turn This Into A Competitive Advantage
There is a real opportunity here for any UK business that takes the next fortnight seriously.
Evidenced compliance. Most of your competitors will read the headlines, decide it is too technical, and do nothing. The first business in your sector that can document a TPM plus PIN deployment, a firmware lockdown audit, an Entra ID recovery key escrow verification, and a tested lost-device playbook is in a defensible position the others are not. That is increasingly the kind of evidence procurement teams and insurers are asking for. The compliance schemes do not require it. The thoughtful clients are starting to.
A better answer to the next supplier audit. “We follow NCSC published guidance on BitLocker configuration” is a far more credible position than “we use BitLocker.” If you are a supplier to a regulated buyer, that answer is worth real money in the renewal conversation.
Visible governance maturity. Boards are increasingly asked what they are doing about specific named vulnerabilities. Being able to answer with a one-page playbook that ties the technical change to the regulatory framework, costed, scoped and dated, is the kind of artefact that turns a security team from a cost centre into a governance asset.
How To Sell This To Your Board
For the board conversation, three arguments tend to land harder than the technical detail.
Notification risk. The Article 34 protection for encrypted devices depends on the appropriateness of the measures. A publicly reproduced bypass against the default configuration weakens that argument materially. The board should understand that “we were encrypted” no longer ends the conversation with the regulator.
Insurance posture. Cyber insurers are tightening their underwriting around demonstrable hygiene. “Default encryption” against a known public bypass is the kind of detail that ends up in a claim denial letter, particularly where the alternative was specifically recommended by national authority guidance.
Sector positioning. In regulated sectors, the supplier that can evidence current-state alignment with NCSC guidance is increasingly the supplier that wins the next contract. The cost of getting there is measured in helpdesk hours. The cost of not getting there is measured in lost tenders.
What This Means For Your Business
A short list, in approximate order.
- Audit your BitLocker protector configuration. Use
manage-bde -statusor your endpoint management reporting. Know what you actually have, not what the dashboard summary claims. - Match deployment to published NCSC guidance. Move high-risk devices to TPM plus PIN. Lock firmware. Restrict boot from removable media. Document the change.
- Update your breach response playbook. The first sixty minutes after a device goes missing should produce evidence of protector state, recovery key escrow, and a documented Article 34 risk assessment. Not a panic, a process.
- Brief the board. Once, briefly, in writing, with a costed action plan. They do not need to understand WinRE. They do need to understand the regulatory shift and what you are doing about it.
- Wait for Microsoft and watch for an NCSC pointer. When the official channels do speak, the wording will matter. Read it carefully.
YellowKey did not invent this problem. It exposed it.
The published guidance is where it has always been. The question is now whether your organisation can evidence that it followed it.
Related reading:
- Your Green Tick Is Not A Security Strategy
- Cyber Insurance Claims Are Being Denied And It’s Your Fault
- You’ve Got a Flood Plan, But No Cyber Plan?