Updated TPM Boot certificates

155 views
Skip to first unread message

Mike Leone

unread,
May 15, 2026, 11:35:41 AMMay 15
to NTSysAdmin
OK, I'm gonna ask a couple stupid questions here.

I still have a bunch of Win 2012 R2 servers (not my choice, I've been trying for years t get them upgraded. Hey, I just work here ....).  I will double check, but I'm practically certain all the VM BIOSes are in LEGACY mode, not UEFI, and the TPM boot certs only apply to UEFI BIOS, right?

That BIOS LEGACY concern applies to any later OS, too, right? I still have Windows 2016, 2019, and 2022 VMs all over the place. Pretty sure the vast majority of them are not using UEFI BIOS, so they'd never need (or get) the updated certificates, either. Is that right?

Sorry for the dense questions.

--

Mike. Leone, <mailto:tur...@mike-leone.com>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

Wright, John M

unread,
May 15, 2026, 11:58:08 AMMay 15
to ntsys...@googlegroups.com

Yes, it’s only under UEFI.

 

--

John Wright

IT Support Specialist

1800 Old Bluegrass Avenue, Louisville, KY 40215

502.708.9953

Please submit IT requests to Hazelwoo...@bluegrass.org

24 Hour Helpline 1.800.928.8000

  

CONFIDENTIALITY NOTICE: This message contains confidential information and is intended only for the individual(s) addressed in the message. If you are not the named addressee, you should not disseminate, distribute, or copy this e-mail. If you are not the intended recipient, you are notified that disclosing, distributing, or copying this e-mail is strictly prohibited.

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Friday, May 15, 2026 11:37 AM
To: NTSysAdmin <ntsys...@googlegroups.com>
Subject: [ntsysadmin] Updated TPM Boot certificates

 

EXTERNAL EMAIL - This email was sent by a person from outside your organization. Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

Secured by Check Point

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAHBr%2B%2BhqjNxEDk5EFC7Bqv6obxHEf7JdHKDffYYcSzg-zgK8jw%40mail.gmail.com.

Mike Leone

unread,
May 15, 2026, 2:40:19 PMMay 15
to ntsys...@googlegroups.com
OK! That's something ... I assume that the same applies to physical boxes, right? They will get their updated TPM certs from MS, too? I don't need to go digging on the hardware manufacturer site for them?


Wright, John M

unread,
May 15, 2026, 2:48:54 PMMay 15
to ntsys...@googlegroups.com

Yes, as long as they’re getting updates, the certs will be updated.

 

If you check around, you might find that some at least have already been updated.  My work laptop for example has a cert with this subject property.

 

Subject           : CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=US

Charles F Sullivan

unread,
May 18, 2026, 5:43:58 PMMay 18
to ntsys...@googlegroups.com
Mike is giving me the courage to ask what also might be a stupid question.

If I simply enter the BIOS of a computer and disable secure boot, then that solves the problem, should it arise. Isn't that correct?

If I'm right, then anyone with physical access can disable it unless the BIOS is password protected.



--

Charlie Sullivan

Principal Windows Systems Administrator

Charles F Sullivan

unread,
May 18, 2026, 5:46:19 PMMay 18
to ntsys...@googlegroups.com
That could be taken as me suggesting Mike's question was stupid. It wasn't stupid at all, despite his framing it that way!

Mike Leone

unread,
May 18, 2026, 6:01:15 PMMay 18
to NTSysAdmin
On Mon, May 18, 2026, 5:46 PM 'Charles F Sullivan' via ntsysadmin <ntsys...@googlegroups.com> wrote:
That could be taken as me suggesting Mike's question was stupid. It wasn't stupid at all, despite his framing it that way!

Not all, I understood what you were saying. LOL

Chris Brewer

unread,
May 18, 2026, 6:11:36 PMMay 18
to ntsys...@googlegroups.com
I wouldn't say disabling Secure Boot "solves" the problem, but it does allow you to cover your ears, close your eyes, and go "la la la la la" while the Secure Boot expiration date passes by uneventfully. Of course, you open yourself up to many other potential vulnerabilities that Secure Boot protects against.

Regarding your second statement, yes - anyone with physical access and no BIOS password can disable Secure Boot. And boot to another OS. And even install that other OS. Or reinstall Windows. Or whatever they want, really.

It's not a stupid question, but it's good to think through the available options for approaching this expiration date. As John mentioned, many devices may already see the certificate updates when they reboot for monthly patches, for example. Other devices may not apply the updates for some reason; the trick is figuring out what each machine looks like centrally.

Thanks,
Chris

To view this discussion visit https://groups.google.com/d/msgid/ntsysadmin/CAEuHzz%3D_LvPyUidRXFE1sGVDg1_d5zuSa%3DiYOCb%2BXrRx-3LAJg%40mail.gmail.com.

Philip Elder

unread,
May 18, 2026, 6:22:55 PMMay 18
to ntsys...@googlegroups.com

So, on the low hanging fruit side of things, has anyone seen an exploit that SecureBoot would protect against?

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@MPECSInc.Ca

Phone: +1 (780) 458-2028

Web: www.MPECSInc.Com

Blog: Blog.MPECSInc.Com  

Twitter: Twitter.com/MPECSInc

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

Charles F Sullivan

unread,
May 20, 2026, 3:01:15 PMMay 20
to ntsys...@googlegroups.com
Thanks for the confirmation.

The problem I was referring to is if a machine won't boot. That would very much be a problem that needs immediate attention.

I am retiring at the end of next week and I'll be leaving hundreds of server VMware VMs behind. I'm scrambling to test, document and hopefully find a good solution to leave behind. I am apparently the only one in my small group who was even aware of this. I didn't feel that compelled to act because Broadcom seemed to say for so long that there was nothing to worry about. Then that changed somewhat. (That's not to say that I didn't plan on acting on this, it just seems a bit dire now.)

We only have about 15 physical servers and I don't think most have secure boot enabled, but I'll confirm. Speaking of that, we have at least 100 server VMs that are not UEFI based, so they are vulnerable by nature.

Thanks mostly to this group, I have lots of links and such to help me out with this. (I've been saving the related conversations for months.)

Michael B. Smith

unread,
May 20, 2026, 3:26:10 PMMay 20
to ntsys...@googlegroups.com

FinSpy, ESpecter, MoonBounce – pop to mind.

Mike Leone

unread,
May 20, 2026, 3:39:01 PMMay 20
to NTSysAdmin
So I spent some time thinking about this. And currently I am this stage of thought:

There are a number of checks, some of which problem don't apply. Follow me on this:

1. UEFI BIOS. Updated certificates mean nothing for legacy BIOS, so no UEFI, no problem.

2. TPM must be present. I have a number of VMs (Win 2022) and even hardware, that have no TPM. These VMs were created a while ago, and the TPM option not checked. They're Win 2022, where TPM is not required (unless you need like BitLocker or something). So again, updated certificates mean nothing if you have no TPM. 

3,  It's possible for TPM to be present but not enabled (I suppose - none of my hosts match this).
4. It's possible for TPM to be presented and not be activated? (again, none of my hosts match this)

So then the script logic comes down to something like this:

  $script:BIOS = Invoke-Command -ComputerName $MemberServer -ScriptBlock { $env:firmware_type }
IF ($BIOS -eq "UEFI") {
    $script:HasTPM = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Get-TPM }
    IF ($HasTPM) {
         $TPM_Present = $HasTPM.TpmPresent
          $TPM_Enabled = $HasTPM.TpmEnabled
          $TPM_Ready = $HasTPM.TpmReady
          $TPM_Activated = $HasTPM.TpmActivated
      }
      IF ($TPM_Present) {
          IF ( $TPM_Enabled) {
              IF ( $TPM_Activated ) {
                     $script:Check_for_TPM_certificates = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Confirm-SecureBootUEFI }-ErrorAction SilentlyContinue

                      IF ( $Check_For_Updated_TPM_Certificates) {
                              Has updated Certs
                       ELSE
                              Needs updated certs

(yes, I've left off the ELSEs and the closing braces. It's pseudo code, more or less, for clarity)

That's right, isn't it? Must be UEFI BIOS *AND* TPM must be present (and enabled and activated) else no need to worry about updated certificates. And UEFI and TPM prescense *required* only apply to Win 11 and Win 2025. They're optional on earlier (Win 2022) servers, and only need to be updated if they even exist for such earlier OSes.

Did I miss something here?

Michael B. Smith

unread,
May 20, 2026, 4:09:09 PMMay 20
to ntsys...@googlegroups.com

So, I’ve stayed out of this because – pedantry. 😊

 

Secure Boot and TPM are not the same thing.

 

Secure Boot requires TPM.

 

You can have TPM without Secure Boot.

 

You can have UEFI without Secure Boot.

 

You cannot have Secure Boot without TPM.

 

You cannot have Secure Boot without UEFI.

 

You can have TPM without it being enabled (tpm.msc is the console for handling the TPM and obviously you can do it from PowerShell and .NET).

 

If your firmware is UEFI, then you have a TPM and you might have secure boot enabled.

 

To confirm secure boot is enabled, you use Confirm-SecureBootUEFI.

 

To confirm that the certificates are updated:

 

[System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023'

 

So, on a target computer:

 

               if( $env:Firmware_Type -eq ‘UEFI’ )

               {

                              if( Confirm-SecureBootUEFI )

                              {

                              if( [System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )

                              {

                                             ## has updated certs

                              }

                              else

                              {

                                             ## needs updated certs

                              }

                              }

                              else

                              {

                                             ## secure boot not enabled

                              }

               }

               else

               {

                              ## BIOS, not UEFI

               }

 

You can obviously add in the remoting as you please.

--

You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Mike Leone

unread,
May 20, 2026, 4:22:28 PMMay 20
to ntsys...@googlegroups.com
On Wed, May 20, 2026 at 4:09 PM Michael B. Smith <mic...@smithcons.com> wrote:

So, I’ve stayed out of this because – pedantry. 😊

 

Secure Boot and TPM are not the same thing.

 

Secure Boot requires TPM.

 

You can have TPM without Secure Boot.

 

You can have UEFI without Secure Boot.

 

You cannot have Secure Boot without TPM.

 

You cannot have Secure Boot without UEFI.

 

You can have TPM without it being enabled (tpm.msc is the console for handling the TPM and obviously you can do it from PowerShell and .NET).

 

If your firmware is UEFI, then you have a TPM and you might have secure boot enabled.

 

To confirm secure boot is enabled, you use Confirm-SecureBootUEFI.

 

To confirm that the certificates are updated:

 

[System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023'


OH. I thought the  Confirm-SecureBootUEFI checked for updated certificates. But it doesn't ...

    The Confirm-SecureBootUEFI cmdlet confirms that Secure Boot is enabled by checking the Secure Boot status on a
    UEFI computer.

Now I feel even more stupid then usual. LOL

So, on a target computer:

 

               if( $env:Firmware_Type -eq ‘UEFI’ )

               {

                              if( Confirm-SecureBootUEFI )

                              {

                              if( [System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )

                              {

                                             ## has updated certs

                              }

                              else

                              {

                                             ## needs updated certs

                              }

                              }

                              else

                              {

                                             ## secure boot not enabled

                              }

               }

               else

               {

                              ## BIOS, not UEFI

               }

 

You can obviously add in the remoting as you please.


I'll be re-writing that section of my script tomorrow.  
$script:Updated_Certs = Invoke-Command -ComputerName $MemberServer -ScriptBlock { ([System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )}

And that should evaluate to TRUE or FALSE, right? 

Michael B. Smith

unread,
May 20, 2026, 4:26:40 PMMay 20
to ntsys...@googlegroups.com

>> I'll be re-writing that section of my script tomorrow.  

>> $script:Updated_Certs = Invoke-Command -ComputerName $MemberServer -ScriptBlock { ([System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )}

>> 

>> And that should evaluate to TRUE or FALSE, right? 

 

Yes. And in case it isn’t obvious, it must be executed from an elevated session.

Mike Leone

unread,
May 21, 2026, 12:05:14 PMMay 21
to ntsys...@googlegroups.com
So after yet more thinking, I'm down to this:

Updated TPM certificates only apply to Win 2025 servers (earlier OSes did not require TPM, so - for MY SITUATION - anything earlier than Win 2025 wouldn't have a TPM. And even if it does, the OS isn't looking at it , anyway. So I don't need to worry about it.) I am not checking workstations with this script (yet).

Right?

If so, then I'm down to this:

If I can connect to a server, I check its OS. If it's Win 2025, I check that it has Secure Boot enabled. If so, I check the TPM certs therein.

ForEach ($MemberServer in $AllMemberServers) {
  IF (Test-Connection -ComputerName $MemberServer -Count 2 -Quiet) {
    $Connected = $TRUE
    $OS_being_checked = $NULL
    $script:OS_being_checked = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Get-ComputerInfo | Select-Object -ExpandProperty OSName }
    $OS_Requires_TPM_Certs = ($OS_being_checked -match $Server_OS_that_requires_TPM)
    IF ( $OS_Requires_TPM_Certs ) {

      $script:BIOS = Invoke-Command -ComputerName $MemberServer -ScriptBlock { $env:firmware_type }
      $script:HasTPM = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Get-TPM }
      $Has_Secure_Boot = $NULL
      $Has_Updated_Certs = $NULL
      $script:Has_Secure_Boot = Invoke-Command -ComputerName $MemberServer -ScriptBlock { Confirm-SecureBootUEFI }-ErrorAction SilentlyContinue
      IF ( $Has_Secure_Boot) {
         $script:Has_Updated_Certs = Invoke-Command -ComputerName $MemberServer -ScriptBlock {([System.Text.Encoding]::Ascii.GetString( ( Get-SecureBootUEFI db ).bytes ) -match 'Windows UEFI CA 2023' )}
         IF ($Has_Updated_Certs ) {
            $SuccessCnt ++
         } ELSE {
            $NonSuccessCnt ++
         }
     }

(I'm old, I like resetting variables in loops before I try and set them, just to avoid any leftover issues)

There's actually a bit more to the script, in terms of writing output and compiling it into an email. But that should work, to check 

Anybody see any glaring errors here? (thanks to Michael Smith for setting me straight on the difference between SecureBootEUFI and actually checking for an updated cert within that)


Michael B. Smith

unread,
May 26, 2026, 10:45:34 AMMay 26
to ntsys...@googlegroups.com

Conceptually, this looks ok. I didn’t test it.

Dave Lum

unread,
Jun 4, 2026, 1:10:10 PMJun 4
to ntsys...@googlegroups.com

This little task just landed on my desk today. I also see the May MS updates creates necessary scripts in %systemroot%\SecureBoot\ExampleRolloutScripts.

Dave Lum (he/him)

Systems Administrator
Work hours: Tues – Fri 5:30a – 4:30p Pacific
P: 503.546.2163
E: lu...@ochin.org

Facebook LinkTwitter LinkLinkedin Link www.ochin.org
OCHIN email

 

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Mike Leone
Sent: Thursday, May 21, 2026 9:07 AM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] Updated TPM Boot certificates - UPDATED

 

CAUTION: This email originated from outside of OCHIN’s network

Do not click links or open attachments unless you recognize the sender and know the content is safe. If you suspect this email is phishing or a scam, use the report button in the Outlook toolbar to report it to Desktop Support.

 

Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compl...@ochin.org, delete this email and destroy all copies.

Mike Leone

unread,
Jun 4, 2026, 2:35:27 PMJun 4
to ntsys...@googlegroups.com
On Thu, Jun 4, 2026 at 1:10 PM 'Dave Lum' via ntsysadmin <ntsys...@googlegroups.com> wrote:

This little task just landed on my desk today. I also see the May MS updates creates necessary scripts in %systemroot%\SecureBoot\ExampleRolloutScripts.


Depends if you use Orchestrator, it seems. We don't, so I'm not sure  if the "EnableSecureBootTask" script would help me ...

Dave Lum

unread,
Jun 4, 2026, 7:16:39 PMJun 4
to ntsys...@googlegroups.com

Philip Elder

unread,
Jun 4, 2026, 10:04:09 PMJun 4
to ntsys...@googlegroups.com

We have these big signs in front of our shop that say 2Hr parking yet the summer kids that work for the city mowing the grass always seem to miss them until by-law gets a call from one of us.

 

 

We have signs in the back for each bay. There’s seven in this building.

 

Every tenant respects the signs but one tenant runs kid’s music sessions in the afternoons and sometimes the evenings. Guess what? The parents don’t pay attention either.

 

That colour makes me want to make some raspberry or strawberry ice cream in the CREAMI my wife got me for my birthday.

 

Otherwise, it’s just background noise … just like our signs! 😉

 

Philip Elder MCTS

Senior Technical Architect

Microsoft High Availability MVP

MPECS Inc.

E-mail: Phili...@MPECSInc.Ca

Phone: +1 (780) 458-2028

Web: www.MPECSInc.Com

Blog: Blog.MPECSInc.Com  

Twitter: Twitter.com/MPECSInc

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.

 

 

Reply all
Reply to author
Forward
0 new messages