I noticed a new folder in File Explorer last week called Secure Boot and I almost deleted it. It appeared after a routine cumulative update (a single patch that bundles security fixes, driver updates, and small improvements into one install) on Windows 11 25H2, sitting quietly in C:\Windows\System32. The icon looked like a system folder, the size was small, and there was no documentation anywhere on the official Microsoft site explaining why it was suddenly there. That combination is exactly the kind of thing that makes people nervous, and exactly the kind of thing that is safe to leave alone.
The short version: Secure Boot (a firmware-level feature, controlled by your motherboard’s UEFI, that refuses to load any boot-time software that is not signed by a trusted certificate) has had a certificate-management problem for years. The certificates that sign your bootloaders (small programs that run before the operating system loads) expire, and when they do, your machine can fail to boot or fail to apply future updates. Microsoft built a folder of PowerShell scripts so IT administrators can identify and fix expired certificates without booting into recovery mode. The folder is part of Windows, not malware.
What the folder actually contains
Open C:\Windows\System32\SecureBoot and you will see four PowerShell scripts and a README. The README is the part most people miss, because it has no flashy icon and the default Windows install does not surface it anywhere obvious. The scripts are:
SecureBoot-UEFI-CA-Management.ps1: the main certificate-management tool. It reads your current Secure Boot configuration and tells you which certificate is about to expire.SecureBoot-UEFI-Update.ps1: updates the Secure Boot certificates on the machine. Run this only after reading the README.SecureBoot-UEFI-Reset.ps1: resets the Secure Boot database to factory defaults. Use this if your Secure Boot state is corrupted.SecureBoot-UEFI-Boot-Manager.ps1: manages the boot entries. Most users will never need this one.
Each script is signed by Microsoft and runs only with administrator privileges. If you open one in a text editor, you will see normal PowerShell: no obfuscation (deliberately scrambled code meant to hide what a script does), no network calls back to a remote server, no registry modifications beyond the documented Secure Boot keys. The scripts are tools, not payloads.
Why certificates expire at all
Secure Boot works because every bootloader, every UEFI shim, and every early-boot driver is signed by a certificate that your motherboard’s firmware trusts. The trust chain looks like this: your motherboard has a small set of root certificates burned into the firmware at manufacture. Those roots delegate to platform keys (PK), which delegate to key exchange keys (KEK), which delegate to authorized signatures database (db) entries. When your machine boots, every piece of boot-time code must be signed by something in the db.
The certificates in the db expire on a schedule set by the certificate authority (the organization that issued the certificate and vouches for the holder’s identity). Microsoft’s certificates were issued in 2011 and 2012 with 10-year lifetimes. The first batch started expiring in 2026, which is why the folder and the scripts appeared. The update mechanism was already built into Windows; the folder is just a way for administrators to invoke it.
The thing that makes certificate expiration dangerous is that an expired certificate does not invalidate the signatures that were issued while it was valid. Your machine keeps booting fine. But new updates cannot be signed by an expired certificate, and an attacker who controls a certificate that has not expired yet can still sign malicious code that the firmware trusts. Microsoft handles the rotation (the process of retiring an old certificate and installing a new one), but the rotation has to happen on the machine, in the firmware, with administrative intent.
When you would actually run the scripts
For most home users, you never run these scripts. Windows handles certificate rotation through Windows Update, and you do not see it happen. The folder appears because the rotation logic exists, not because you need to invoke it.
There are three situations where you would open the folder and run something by hand.
First, if you dual-boot Linux (install two operating systems on one machine and choose which one to start at boot) and your Linux distribution requires custom Secure Boot keys (called MOK, or Machine Owner Keys, which let you sign your own boot components), you may need to use the certificate management script to add or revoke MOK entries.
Second, if you are an IT administrator managing a fleet of machines with custom UEFI configurations, you would script the certificate update across all of them using Invoke-Command (a PowerShell command that runs a script block on one or more remote computers at once) over WinRM (Windows Remote Management, the protocol that lets administrators run commands on remote Windows machines). The SecureBoot-UEFI-Update.ps1 script accepts the new certificate as a parameter.
Third, if your machine has a corrupted Secure Boot database (this usually happens after a failed BIOS update or an interrupted firmware flash), the SecureBoot-UEFI-Reset.ps1 script can rebuild the database from the factory defaults.
For everything else, the scripts are documentation as much as they are tools. Reading them tells you what the update process is supposed to look like, which helps you debug problems that Microsoft support will not help you with.
Why the folder is hidden
The folder is not technically hidden in the File Explorer sense. It is a normal folder under System32. What makes it feel hidden is that nothing in the Windows UI points to it. There is no “Open Secure Boot folder” button in Settings. There is no Control Panel entry. There is no entry in the Start Menu.
The reason is the same reason most of System32 is not surfaced: the folder is for administrators, not for end users. Microsoft assumes that the people who need this folder know it exists, and that the people who do not know it exists will never have a reason to look. The README inside the folder is the documentation. The lack of a Settings link is a feature.
If you are curious, the safest way to confirm the folder is legitimate is to right-click the README, open Properties, and check the digital signature tab. It will say “Microsoft Windows” and the signing certificate will be issued by “Microsoft Code Signing PCA 2011” or a similar Microsoft code-signing certificate authority. That is the same signature that ships on every Microsoft executable. If the signature is missing or shows a different issuer, you have a real problem and should run a full antivirus scan.
Trade-offs
The folder is a usability trade-off that Microsoft has chosen to make. Hiding admin-only tools reduces the surface area for accidental damage, which is good for the 99 percent of users who would never need to invoke a Secure Boot script. The cost is that the 1 percent who do need it cannot find it through normal Windows navigation and may not know it exists until something breaks. The MITRE trade-off (weighing the risk of accidental damage against the cost of being unable to find a tool when you need it) is the same one every operating system vendor makes about every administrative tool, and the folder is the right call for the audience Microsoft is optimizing for.
The other trade-off is that the folder is small and easy to mistake for malware. A technically inclined user who finds an unfamiliar System32 folder has three options: leave it alone, research it, or delete it. Deleting the folder breaks Windows Update’s certificate-rotation logic until the next cumulative update reinstalls the scripts, which is recoverable but annoying. Leaving it alone is what the README recommends and what Microsoft intends. Researching it (which is what this article is for) is the middle path.
If you are a home user with a stock Windows 11 install, the folder is harmless. If you dual-boot, manage a fleet, or build custom firmware, the folder is a tool you should know exists. If you have no idea why you opened this article, close the folder, close File Explorer, and run Windows Update.
Bottom line
The Secure Boot folder is a real, Microsoft-built, digitally signed collection of PowerShell scripts that manage the certificates your machine uses to verify boot-time software. It is not malware. It is not permanent (a cumulative update can add or remove scripts from it). It is not something you need to run unless you have a specific reason. The reason it appeared in 2026 is that the original Secure Boot certificate batch is hitting its expiration window, and Microsoft has automated the rotation. Leave the folder alone, run Windows Update, and you will never think about it again.
If you have a specific problem: a Linux distribution that needs MOK entries, a fleet of machines with custom firmware, or a corrupted Secure Boot database, the scripts are the documented solution. Read the README, run the right script with administrator privileges, and the problem is fixable in a few minutes. For everyone else, this folder is a quiet reminder that the boot process is more complicated than it looks, and that Microsoft maintains more plumbing under the hood than any single user will ever need.