Secure Boot Certificate Expiry in 2026: What It Means and What to Do Before October 19

What is actually happening with Secure Boot certificates in 2026

Microsoft is replacing the 2011 generation of the certificates that Secure Boot uses to decide what is allowed to start on your computer. Several of the old certificates reach their expiry date between June and October 2026, and the newer 2023 certificates take over. The important part is what this means for ordinary people: your PC does not suddenly stop working, but a PC that never receives the new certificates falls behind on boot-level security protection.

Today is October 1, 2026. Two of the three expiry dates (June 24 and June 27) have already passed, and the last one, the Windows Production PCA 2011, expires on October 19, 2026. That is why searches for this topic are climbing, and why you may have seen a reminder in Windows or a message from your IT provider. This guide is written for home users, small offices and anyone who looks after a few computers, and it sticks to what Microsoft has published. Where Microsoft has not said something, we say so rather than guess.

There is a lot of noise on this subject. Some websites claim that computers will "fail to boot" or "stop receiving updates" on a specific day. Microsoft's own wording is calmer and more precise, and we quote it below. The real risk is a slow one: devices that do not get the new certificates cannot receive future fixes for the boot process itself, and that matters most for businesses, laptops that travel, and computers that hold sensitive data.

What Secure Boot certificates are, in plain language

Secure Boot is a feature of modern UEFI firmware that only lets software start if it carries a valid digital signature from a trusted source. Certificates stored in your computer's firmware are the list of trusted sources. When the PC powers on, the firmware checks the signature on the boot loader before it hands control over. If the signature is not trusted, or is on a blocked list, the boot loader does not run.

Microsoft's documentation for hardware makers describes the pieces. The platform key (PK) is installed by the manufacturer and establishes trust between the platform owner and the firmware. The key exchange key (KEK) protects access to the two databases. The authorized database (db) holds the public keys and certificates that represent trusted firmware components and operating system loaders. The forbidden signature database (dbx) holds hashes of malicious and vulnerable components, and of compromised keys and certificates, so that they are blocked from running.

A helpful way to picture it: the db is the guest list at the door, the dbx is the list of people who are banned, and the KEK is the right to edit those lists. If the certificate that lets Microsoft edit the lists expires, Microsoft can no longer add new bans in a way your firmware accepts. If the certificate that vouches for the Windows boot loader expires, new boot loaders signed after that point can no longer be trusted by firmware that does not know the replacement.

That is exactly the situation Microsoft describes. In its guidance for hardware makers, Microsoft says the Microsoft Corporation KEK CA 2011 is set to expire in 2026 and that manufacturers must create, sign and submit updates for the new Microsoft Corporation KEK CA 2023, so that Microsoft can update devices already in the market and allow systems to keep receiving db and dbx updates after 2026.

The exact dates and the replacement certificates

Microsoft lists four expiring items: the Microsoft Corporation KEK CA 2011 (June 24, 2026), the Microsoft UEFI CA 2011 (June 27, 2026, which has two replacements), and the Microsoft Windows Production PCA 2011 (October 19, 2026). Each has a 2023 successor. The table below is taken from Microsoft's support article on Secure Boot certificate expiration, which we opened on October 1, 2026.

Notice that the dates are not all the same. The KEK and the third-party UEFI certificate come first, in late June. The Windows Production PCA, which is the certificate behind the Windows Boot Manager signature, comes last, in October. Many articles blur these into one "Secure Boot expires" date, which is why the advice you read online often seems contradictory.

The UEFI CA is also the one that matters beyond Windows. It is the certificate that third-party software, including some Linux boot loaders and hardware option ROMs (the firmware on graphics cards and storage controllers), has historically been signed under. That is the reason the replacement shows up twice in the table: one successor for the boot software and one for option ROMs.

Who is affected: Windows, Linux dual boot, virtual machines and firmware

Microsoft lists Windows 10 (all versions, including IoT Enterprise LTSC), Windows 11 (Home, Pro, Enterprise, Education, Multi-Session, IoT Enterprise and SE) and Windows Server 2012 through 2025 as affected. In practice that means almost any computer with UEFI Secure Boot that runs Windows today, whether it is a family laptop, an office desktop or a server.

The question we hear most is whether age matters, for example whether only computers built before 2024 are at risk. Microsoft's overview page does not draw that line, so we will not either. What it does say is that some devices may need a firmware update to apply the new certificates, and firmware is exactly where age matters: older models are less likely to still receive manufacturer updates. A better rule than age is manufacturer support. If your computer's maker still publishes BIOS or UEFI updates for your model, you are in good shape. If it does not, you are the case to plan for.

Windows 10 and Windows 11 home users

For a typical home PC, the work is mostly done for you. Microsoft says it will manage the update process on a significant portion of Windows devices. Your job is to keep Windows Update running, install the optional firmware update from your manufacturer if one exists, and make sure your BitLocker or device encryption recovery key is saved somewhere other than the same computer. If you are still on Windows 10, also read our guide to Windows 10 end of life and moving to Windows 11, because your update options differ.

Small offices and Windows Server

Servers and managed office PCs are covered by the same certificates, so they are on the list too. Offices are the group that can get hurt most by surprises, because a firmware update applied on a Friday afternoon across ten computers, each with BitLocker on, can create ten recovery prompts on Monday morning. We cover a safe rollout in a later section.

Linux and dual boot

Linux systems that boot with Secure Boot generally depend on a first-stage loader signed under the Microsoft UEFI CA, which is one of the certificates in the table. That is the logic behind the concern for dual boot machines. We did not verify distribution-specific behavior on a Microsoft page, so we treat it as a "check your distribution" item rather than a statement of fact. Section on Linux below explains how to check safely.

Virtual machines

Microsoft keeps dedicated pages for Azure Virtual Desktop, Windows 365 and Linux on Azure virtual machines, which tells us virtual machines are in scope. A virtual machine has virtual firmware with its own key databases, so the steps depend on the hypervisor. If you run Hyper-V, VMware or cloud desktops, look for the platform-specific page instead of copying a physical PC procedure.

What happens if you do nothing

Microsoft says devices that have not received the newer 2023 certificates will continue to start and operate normally, and standard Windows updates will continue to install. What they lose is the ability to receive new security protections for the early boot process. That includes updates to the Windows Boot Manager, to the Secure Boot databases, to revocation lists, and mitigations for newly discovered boot-level vulnerabilities.

It is worth sitting with how that differs from the scary headlines. There is no cliff on October 19 where the screen goes black. Your Monday morning does not change. What changes is the long-term protection of the one layer that runs before Windows, before your antivirus and before BitLocker. Attacks on that layer (bootkits, for example) are rare but severe, because they run below the tools you normally rely on to detect problems.

A realistic way to think about it is as a slow drift. Over the next year, Microsoft will publish fixes and revocations that assume a device knows the new certificates. A PC that never got them cannot take those fixes. For a family PC that is a modest risk. For a laptop holding client files, a point-of-sale machine or a clinic workstation, it is a compliance question: you are knowingly running with a gap that the vendor has told you about. In Quebec, Law 25 expects reasonable security measures for personal information, and "we were told and did nothing" is a weak position to explain after an incident.

How to check your Secure Boot status

There are four quick checks: the PowerShell command Confirm-SecureBootUEFI, the System Information (msinfo32) Secure Boot State line, the Windows Security Device security page, and the System event log entries 1808 and 1801. Do them in that order. The first three tell you whether Secure Boot is on. Only the event log tells you whether the new certificates have been applied.

Check 1: PowerShell and Confirm-SecureBootUEFI

Right-click the Start button, choose Terminal (Admin) or Windows PowerShell (Admin), and run the command below. Microsoft documents that it returns True when Secure Boot is enabled.

Confirm-SecureBootUEFI

• True: Secure Boot is enabled and active.
• False: Secure Boot is supported but turned off in firmware settings.
• "Cmdlet not supported on this platform": the computer starts in legacy BIOS mode (CSM) or the firmware does not support Secure Boot at all, so the certificate story does not apply in the same way. Do not switch boot modes to "fix" it without help, because converting from legacy to UEFI can make Windows unbootable if the disk layout is not prepared.

Check 2: System Information (msinfo32)

Press Windows + R, type msinfo32, and press Enter. In the right pane, find the lines "BIOS Mode" and "Secure Boot State". You want to see "UEFI" and "On". This is general Windows behavior that we did not re-verify on the Microsoft pages we opened for this article, but it is a long-standing and widely documented place to look.

Check 3: Windows Security, Device security

Open Windows Security, select Device security, and look for a Secure boot entry. If your hardware supports it, the page says Secure boot is enabled. If the section is missing, the device may not meet the requirements for the standard hardware security view, which is common on older or custom-built PCs. Again, this tells you about the Secure Boot setting, not about which certificates are installed.

Check 4: the event log, the one that answers the real question

Open Event Viewer (Windows + R, type eventvwr.msc), expand Windows Logs, select System, and use Filter Current Log to search for event IDs 1801 and 1808. Microsoft describes them like this:

• Event ID 1808 is an informational event that indicates the device has the required new Secure Boot certificates applied. This is the one you want to see.
• Event ID 1801 is an error event that indicates the updated certificates have not been applied to the device. Seeing it does not mean damage. It means "not done yet".

Microsoft also mentions the event IDs 1795, 1796, 1800, 1802 and 1803 in its guidance for IT professionals, which relate to the progress and problems of the update process. We did not retrieve the exact meaning of each of those, so if you see one of them, copy the full event text and search that exact text on Microsoft's page rather than relying on a summary from a blog.

For administrators: registry locations

Microsoft's guidance for IT professionals points to two places in the registry. The AvailableUpdates value lives under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot, and the UEFICA2023Status value lives under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. These are the places that fleet tools read to report progress. We deliberately do not list which numbers to write into AvailableUpdates here, because we did not read those values on the page and a wrong value on a production machine is not a risk worth taking. Use Microsoft's own page for those.

If you only have one computer, those six lines are most of the job. If you look after several, put the results in a simple spreadsheet with one row per machine. It turns an anxious guess into a short to-do list.

How the update is delivered: Windows Update, Microsoft rollout and manufacturer firmware

Microsoft says it will manage the update process for these new certificates on a significant portion of Windows devices, and it describes two automated paths: high-confidence device groups included in monthly updates, and an opt-in Controlled Feature Rollout. A firmware update from the manufacturer may also be needed on some devices.

The first path is high-confidence buckets. Microsoft may automatically include high-confidence device groups in monthly updates, based on diagnostic data. In plain terms, if Microsoft has seen enough devices of your type apply the certificates without trouble, it can switch on the update for the whole group through the normal monthly cumulative update. This is why it matters to keep Windows Update on and to let optional diagnostic data flow if your organization allows it.

The second path is the Controlled Feature Rollout, or CFR. Microsoft describes it as a way to opt devices in for Microsoft-managed deployment when diagnostic data is enabled. It is aimed at organizations that want Microsoft to handle the sequencing while they still choose to participate.

The third path is not a Microsoft one at all. Microsoft states that in some cases a firmware update might be required to successfully update the Secure Boot certificates. Dell, HP, Lenovo, ASUS, Acer, Microsoft Surface and other makers publish BIOS or UEFI updates per model. If your model is on the list, install that update. If the manufacturer says nothing, do not assume you are covered or unprotected: check their support page for "Secure Boot", "KEK" or "2023 certificate".

Step-by-step: how to prepare and update a single PC safely

The safe order is: save your BitLocker recovery key, install Windows updates, install the manufacturer's BIOS or UEFI update, restart, wait for the certificate update to finish, and confirm with Event ID 1808. Do not reverse the order, and do not do this on battery power or in a hurry before a meeting.

Delivery routes compared: which one applies to you

Home PCs mostly depend on Microsoft's monthly updates plus an optional manufacturer firmware update, while managed business PCs depend on the administrator's choice of Controlled Feature Rollout or manual deployment. The table summarizes who controls what, based on the routes described in Microsoft's guidance.

Notice that "do nothing" is only a good plan on the first row, and only if you also watch the event log. Updates that arrive automatically still need a check, because an update that silently failed looks exactly like an update that was never offered.

The BitLocker recovery key risk

BitLocker protects your drive by tying the unlock to a trusted state of the computer, including firmware and boot components, so changes to those components can make BitLocker ask for the 48-digit recovery key once. That is the practical risk of any firmware or boot-chain update, including the Secure Boot certificate update. Microsoft's overview page mentions BitLocker hardening as something that may be affected, without further detail on that page, so we treat a recovery prompt as possible but not guaranteed.

Why this matters more than it sounds: since Windows 11 24H2, many new computers turn on device encryption automatically when you sign in with a Microsoft account, and plenty of owners do not know it is on. The first time they find out is a blue screen asking for a key they have never seen. If the key is in your Microsoft account you recover in two minutes from a phone. If you signed in locally, or the key was never saved, the encrypted data is effectively gone.

Should you suspend BitLocker before the update?

Suspending BitLocker for one restart is a common practice for BIOS updates, because it lets the firmware change without tripping protection. In Windows you can do this from the BitLocker control panel (Suspend protection), or from an administrator prompt with manage-bde -protectors -disable C:, and it resumes automatically after the next restart in most cases. Many manufacturer tools do this for you. Treat suspension as an extra convenience, not a replacement for saving the key. Suspension leaves the drive unprotected for that window, so do it only on a computer you control, in a place you trust, and for as short a time as possible.

What to do if you are already looking at the recovery screen

Read the key ID shown on the screen, find the matching key (the first few characters must match), type all 48 digits, and press Enter. If the screen says the key ID does not appear in your account, you are looking at a different computer's key list or the key was never uploaded. Our dedicated article on BitLocker recovery after a Windows update walks through each location and the realistic options when a key is missing. If the PC will not start at all and shows a boot error rather than a BitLocker screen, see the 0xc0430001 boot failure fix and our guide for PCs that will not boot after an update.

What to do for a small office

For a small office, treat the Secure Boot certificate update as a small change-management project: inventory every device by manufacturer, model and firmware version, test on a representative sample, make sure every BitLocker recovery key is stored centrally, then roll out in waves. Microsoft's own advice for organizations is to build a small, representative sample of devices based on manufacturer, model number and firmware version, and to test before broad deployment.

The reason for the sample is that firmware is the unpredictable part. Two laptops that look identical can run different BIOS versions and behave differently. A sample of one machine per model (and per firmware version if you know it) gives you a realistic preview of what the rest of the fleet will do, and it finds the one odd computer before it finds you.

A practical six-week plan for 5 to 25 computers

• Week 1, inventory. List every computer: user, manufacturer, model, BIOS version, Windows version, BitLocker status, and whether the manufacturer still publishes firmware. A shared spreadsheet is enough.
• Week 1, keys. Confirm that each BitLocker recovery key is stored in Microsoft Entra ID, Active Directory or your documented secure location. Test retrieving one.
• Week 2, pilot. Update one machine per model, including firmware, with a technician present. Record the Event ID 1808 result and any recovery prompt.
• Weeks 3 and 4, waves. Update the rest in groups of three to five, never everyone on the same day. Keep one spare working computer available for each wave.
• Week 5, stragglers. Handle machines that did not show Event ID 1808, laptops that were away, and computers without available firmware.
• Week 6, document. Save the results, and write a short note for your cyber insurance or compliance file: what you checked, when, and what you decided about unsupported devices.

If this reads like more than your office wants to take on, that is normal. A managed IT provider does exactly this kind of work, and our overview of what managed IT services include explains what to ask for. Because the work is mostly remote, it does not require shutting the office down.

Linux and dual-boot systems

Linux systems that start with Secure Boot enabled usually use a first-stage boot loader signed under the Microsoft UEFI CA, which is one of the certificates in the 2026 table, so Linux and dual-boot machines are worth checking. Whether a particular distribution is affected depends on how its loader is signed and on what your firmware accepts. We did not verify distribution-specific behavior on a primary page, so treat this section as a safe procedure rather than a prediction.

Before you change anything on a dual-boot computer, do these things in this order. First, confirm the Linux side boots today with Secure Boot on (the command mokutil --sb-state reports the state on most distributions). Second, read your distribution's own Secure Boot or release announcements, because projects such as the major desktop distributions publish notes when signing changes. Third, let Windows apply its certificate update and the firmware update, then boot Linux once to confirm it still starts. Fourth, if Linux does not start, do not disable Secure Boot as a first reaction. Boot from the distribution's installer USB, check for an updated boot loader package, and install it.

If you replaced Windows with Linux to extend the life of an older machine, our article on Linux as a free alternative for small business covers the choices. A Linux-only machine still carries a firmware with these certificates, so the same general rule applies: install your manufacturer's firmware updates when they are offered.

A note on gaming and anti-cheat software

Some competitive online games check that Secure Boot is on. We did not find a verified statement from Microsoft or a game publisher about how the certificate change affects those checks, so we are not making a claim either way. The safe advice is simple: keep Secure Boot enabled, keep Windows and firmware updated, and check the publisher's support page if a game reports a Secure Boot problem after an update.

Virtual machines and cloud desktops

Microsoft publishes separate guidance for Azure Virtual Desktop, Windows 365 and Linux on Azure virtual machines, so virtual machines are in scope, but the procedure depends on the platform. A virtual machine uses virtual firmware with its own key databases, which means the physical computer's BIOS update does not fix it.

If you run Hyper-V generation 2 virtual machines, VMware, Proxmox or a hosted desktop service, open your platform's documentation and search for "Secure Boot" and "2023". Treat each template and each long-lived virtual machine as a device to inventory. A common mistake is to remember the physical hosts and forget the golden image that gets cloned into twenty new machines. If the image is stale, all twenty start out behind.

Troubleshooting: when it does not go as planned

The most common problems are an Event ID 1801 that never changes to 1808, a firmware update that is not available, Secure Boot showing as off, and a recovery prompt nobody can answer. Each has a calm response.

One important warning: do not reset the Secure Boot keys to "factory defaults" or clear them in firmware setup unless a technician or the manufacturer tells you to. Key management is the part of the system Microsoft describes as the root of trust, and clearing it incorrectly can leave a computer that will not start Windows or that has lost its ability to receive the new certificates.

Beware of scams that use this news

Whenever a technical deadline makes headlines, scammers use it. A pop-up claiming your "Secure Boot certificate has expired" with a phone number, a cold call from "Microsoft support", or an email with a "certificate renewal tool" are all fraudulent. The real update arrives through Windows Update or through your computer maker's official firmware tool. Legitimate support will never ask for your password or your bank details. If you gave remote access to a stranger, disconnect the internet and see our guide on what to do after a compromise or call us.

Three realistic scenarios

The same certificate update plays out very differently for a home user, a small office and a company with unsupported hardware, so it helps to see what "normal" looks like in each case. These are illustrative examples based on common situations, not specific clients.

What it costs in Canadian dollars

For most people the update is free, because it arrives through Windows Update and the manufacturer's free firmware download, and the cost is your time: about 15 minutes for one computer and a few hours for a small office. Costs appear when a firmware update goes wrong, when recovery keys are missing, or when a device has to be replaced. The figures below are IT Cares planning estimates for Quebec, not quotes, and your situation may differ.

The comparison to keep in mind is simple: the cost of saving a recovery key is zero, and the cost of not having one can be everything on the drive. When you weigh paying for help, weigh it against that risk, not against the 15 minutes the update takes on a good day. Business owners should also remember that GST and QST apply to professional services in Quebec, so ask whether quotes are before or after taxes.

A simple calendar from now to the end of October

With the Windows Production PCA 2011 expiring on October 19, 2026, the most useful plan is to finish the checks and the key backup this week, install updates next week, and verify immediately after October 19. Nothing in Microsoft's description says that October 19 is a cliff, so use the date as a deadline for your own preparation, not as a source of fear.

Myths and mistakes to avoid

The biggest mistakes are disabling Secure Boot to avoid the problem, assuming the date is a cliff, installing firmware from random websites, and skipping the recovery key. Here are the ones we see most.

• "My PC will not turn on after the date." Microsoft says devices without the new certificates continue to start and operate normally.
• "I should turn off Secure Boot." That removes a protection and can trigger BitLocker recovery. It is not a fix.
• "Only old computers are affected." Microsoft lists all supported Windows versions. Age matters mainly for whether firmware updates exist.
• "Windows Update will handle everything." It handles a lot, but some devices may need firmware, and you should still verify with the event log.
• "I will deal with BitLocker if it comes up." A recovery prompt without a saved key cannot be fixed afterward. Save the key first.
• "A website sells a certificate fix tool." There is no tool you need to buy. Use Windows Update and your manufacturer.
• "Clearing the Secure Boot keys resets the problem." Clearing keys can break booting or block future updates. Leave key management to the update process.

Another common mistake is waiting for a perfect source of information. Microsoft's pages and your manufacturer's support page are the two you should trust. Forum posts are useful for ideas but frequently describe one specific model on one specific firmware version, and what worked for them can hurt you.

Glossary: the terms you will see in Microsoft's pages

Most of the confusion around this topic comes from vocabulary, so the short definitions below match how Microsoft's documentation uses each term. Keep this list handy when you read the official pages.

• UEFI: the modern firmware that starts your computer before Windows, replacing legacy BIOS on most PCs.
• Secure Boot: a UEFI feature that only runs boot software with a trusted digital signature.
• PK (Platform Key): the key the manufacturer installs to establish trust between the platform owner and the firmware.
• KEK (Key Exchange Key): the key that controls updates to the db and dbx. The Microsoft Corporation KEK CA 2011 expires June 24, 2026.
• db (authorized database): the list of trusted certificates and keys for firmware components and operating system loaders.
• dbx (forbidden database): the list of blocked hashes, keys and certificates for malicious or vulnerable components.
• Option ROM: firmware on add-in hardware such as graphics cards, loaded during start-up and covered by the Option ROM UEFI CA 2023.
• Event ID 1808: Microsoft's signal that the required new certificates are applied. Event ID 1801: they have not been applied yet.
• CFR (Controlled Feature Rollout): the opt-in route for Microsoft-managed deployment when diagnostic data is enabled.
• BitLocker recovery key: the 48-digit number that unlocks an encrypted drive when the normal unlock fails.

Official resources to bookmark

The two pages that matter are Microsoft's support article on Secure Boot certificate expiration and its guidance for IT professionals, plus your computer manufacturer's support page for your exact model. Everything in this article about dates, event IDs, registry locations and delivery routes comes from those pages and from the Microsoft Learn guidance for hardware makers, which we opened on October 1, 2026.

• Microsoft Support: Windows Secure Boot certificate expiration and CA updates
• Microsoft Support: guidance for IT professionals and organizations
• Microsoft Learn: Secure Boot key creation and management guidance
• Your manufacturer's support site (Dell, HP, Lenovo, ASUS, Acer, Microsoft Surface and others): search for your exact model and "BIOS" or "UEFI".

For readers in Canada, the Canadian Centre for Cyber Security publishes general guidance on patching and keeping systems updated, and the Office of the Privacy Commissioner of Canada and Quebec's Commission d'accès à l'information explain breach obligations if personal information is ever exposed. Neither has a Secure Boot page that we verified, so we mention them as general references rather than as sources for any claim above.

What we could not verify, stated honestly

We stated as fact only what we read on Microsoft's pages, and we flagged the rest. The exact registry values to write for manual deployment, the likelihood of a BitLocker recovery prompt on a given model, distribution-specific Linux behavior, the procedure for each hypervisor, and any effect on game anti-cheat software were not confirmed on a page we opened, so we did not present them as established. If an article elsewhere states these with certainty, ask where it got them.

The information is current as of October 1, 2026. Microsoft updates these pages as the rollout progresses, so recheck the support article if you read this later.

When to call a professional

Call a technician if your BitLocker recovery key cannot be found, if the PC will not start after a firmware update, if Event ID 1801 persists after several days and a firmware update, or if you manage more than a handful of computers and cannot afford downtime. Stopping early is cheaper than repeated forced restarts, which can damage the file system and turn a fixable problem into a recovery job.

IT Cares has provided remote and on-site IT support in Quebec and across Canada since 2014. A remote session lets a technician connect to your computer while you watch, check Secure Boot status and the event log, confirm that your recovery key is stored, guide the firmware update, and explain what each result means. For several computers, we can do an inventory and plan waves so your office never loses a day. If a failed update has made files hard to reach, our article on data recovery after a Windows update or reinstall explains what is realistically recoverable. If you are also deciding what to do about older Windows versions, see our Windows 11 25H2 update guide.

To talk to someone now, call 1 (888) 711-9428 or book a remote session. If you have a BitLocker prompt on the screen right now, tell us on the call and we will triage by urgency.

Frequently asked questions

Related guides

• BitLocker recovery key after a Windows update
• Fix Windows 11 boot failure 0xc0430001
• Windows will not boot after an update: fixes
• Windows Update stuck or failing: how to fix it
• Windows 11 25H2 update guide
• Windows 10 end of life: migrating to Windows 11
• Linux for small business
• Cloud backup for business in Canada
• Data recovery after a Windows update or reinstall
• What are managed IT services

Sources and official references

Last verified: October 1, 2026

• Microsoft Support: Windows Secure Boot certificate expiration and CA updates
• Microsoft Support: Secure Boot certificate updates, guidance for IT professionals and organizations
• Microsoft Learn: Windows Secure Boot Key Creation and Management Guidance