On Monday, October 19, a certificate expired that almost nobody in your fleet knows exists. No machine failed to power on. No ticket was opened.
That silence is the point. The certificate protects the earliest stage of startup, before Windows, the antivirus or any agent has started running.
The question for IT is not “what broke?” It is “which of our workstations still depend on the old certificate, and who fixes each one?”
What expired, and what keeps working
Secure Boot checks that the code loading before the operating system was signed by a trusted authority. Microsoft says the certificates issued in 2011 begin expiring in June 2026 and are being replaced by a 2023 set. Source: Microsoft Support, 2026.
The last of them, Windows Production PCA 2011, which signs the Windows boot manager, expired on October 19, 2026. Its replacement is Windows UEFI CA 2023. Source: Windows Latest, Oct 17, 2026.
According to Microsoft, a PC with the expired certificate still starts and still installs standard Windows updates. What it stops receiving are new early-boot protections: updates to the boot manager, the Secure Boot databases and the revocation lists.
So the machine works, and it is frozen in time in exactly the layer nobody looks at. Microsoft itself says Secure Boot should not be disabled to work around the expiry: that lowers protection instead of fixing anything.
What 500,000 devices teach
Microsoft described how it ran the switch on its own fleet of around 500,000 Windows devices. A pilot of about 35,000 had a 95% success rate. After 70 days, compliance reached 86%. It now stands at 97%, with failures under 1%. Source: Microsoft Inside Track, Aug 13, 2026.
What was left, according to the article, were edge cases, including meeting rooms and virtual machines.
Read the number carefully. This is the maker of the certificate, with its own telemetry and a dedicated team, and a tail remained anyway. In a bank, factory or hospital network, with branches and equipment nobody calls a PC, the tail is likely the hard part.
Why Windows Update alone does not close the gap
The new certificates roll out in batches, and Microsoft says that for most PCs receiving them through Windows Update, in many cases no action is needed. That “in many cases” is where IT works. Three groups tend to be left out:
- Machines waiting on manufacturer firmware. Some models need a BIOS update before they accept the new certificate.
- Windows 10 PCs without ESU. According to Microsoft, they only get the new certificates with ESU enrollment.
- Equipment nobody treats as a PC. Service kiosks, lab machines, meeting-room workstations, virtual machines.
On the Windows 10 decision, see what we wrote about deciding on ESU machine by machine. The certificate expiry is one more reason for that list to exist per workstation, not on average.
The part that belongs to the internal network
Once the at-risk group is known, you still have to reach the machines. On a large, segmented network, the question becomes logistics: when, over which link, and in what order.
A branch with a narrow link cannot take distribution during business hours. A service desk machine cannot restart mid-shift. A critical server goes after the test ones.
That is why order matters. Starting with the low-risk group, checking, and only then moving to the critical one is what Microsoft itself describes in its pilot. What IT needs to keep is a record of each stage: who received it, who failed, who was postponed.
And all of it should happen without your fleet data leaving the network to be planned somewhere else.
How Trauma Zer0 handles this
Two modules come into play. Tz0 Inventory uses an agent on each workstation to collect hardware, installed software, the operating system and BIOS date, and sends it all to the Tz0 server, installed in the customer’s own infrastructure. Machines that are powered off or off the network join the picture when they return.
That way the list of who may be stuck on the old certificate comes from the real fleet: hardware, system and BIOS age, instead of an asset spreadsheet.
Tz0 Deploy covers the path to the machine: it installs and updates without user interaction, with a window per target, bandwidth limits, automatic resume if the link drops, and a check of who installed, who failed and what was rescheduled. All of it runs on the company network, through the web console.
One limit should be clear. The pages of both modules do not say that Trauma Zer0 reads the Secure Boot certificate state, or that it applies the certificate or firmware update. What the modules offer is the list of machines by hardware and BIOS, and the pipeline to distribute the packages your team approves. The update itself comes from Microsoft and the manufacturer.
A list you should be able to print
Before the next audit asks, it pays to answer with a document rather than an estimate:
- which workstations have an old BIOS and depend on manufacturer firmware;
- which PCs are still on Windows 10 and whether they have ESU;
- which non-PC devices are in the same inventory;
- who owns each exception and until when.
An expired certificate does not page anyone. Only the list does.
If your answer today is “we would have to check”, the problem is not the certificate. It is visibility into the fleet. To see Tz0 Inventory working on your network, request an evaluation.