Microsoft Intune: Secure Boot 2023 CA Certificate Update Rollout – Part 4

From Validation to Posture: Turning “Capable” into “Protected”

With the Secure Boot 2023 certificate update servicing now understood and validated — we can finally address the next category of devices:

UEFI-capable systems where Secure Boot is turned OFF.

TL;DR (Executive Summary)

This post finishes the Secure Boot 2023 CA update journey by addressing the uncomfortable middle ground:
devices that are UEFI‑capable, running Windows 11, but still have Secure Boot turned OFF.

• Secure Boot certificate updates do not enable Secure Boot for you
• Devices with Secure Boot OFF are not “broken” — they’re quietly under‑protected
• Leaving them untouched is no longer neutral; it’s a posture decision

This part focuses on deliberate, controlled Secure Boot enablement:

• Detecting only devices where enablement is safe and allowed
• Respecting platform boundaries (Intune orchestrates; OEM firmware decides)
• Using PowerShell with OEM‑supported interfaces (Lenovo WMI, Dell BIOS Provider / CCTK)
• Accounting for real risks: bootloader validation, BitLocker recovery, BIOS passwords, firmware prerequisites

The result:

• Secure Boot enabled without panic
• No blanket policies
• No surprise outages
• No “mid‑Teams reboot” tickets

This series wasn’t about flipping switches.
It was about moving an enterprise fleet from “capable” to “protected” — and finishing the job properly.

Because the boot chain is no longer below the OS.
It is the security perimeter.

This guidance reflects field‑tested experience. It is not an official Microsoft statement. Always review current Microsoft and OEM documentation for your environment.

Introduction

There’s a moment in every engineering lifecycle where you stare at something and think:

I deeply respect the architecture… but for now, I would simply like it to work.

That was me — elbow‑deep in Microsoft’s Secure Boot 2023 certificate transition, staring past registry keys, scheduled tasks, and firmware logs… and realizing how many hidden dependencies sit beautifully beneath that deceptively simple label called Secure Boot.

On paper, it’s immaculate:

• Great documentation
• Clear timelines
• A well‑designed trust chain
• Cryptographically elegant by any reasonable standard

It’s hard not to admire it.

But elegance has a half‑life.

Because the moment you try to operationalize that elegance at scale — it starts dissolving — often like a BIOS update attempted on 2% battery!

Suddenly, you’re no longer admiring architecture.
You’re navigating reality.

And that reality looks like:

• UEFI modes of questionable origin
• Firmware inconsistencies across “identical” models
• OEM surprises hiding behind polite release notes
• Bootloader validation paths with zero tolerance for imperfection

Secure Boot is usually very polite.
It stays quiet. Rarely demands attention.

…until it really does.

How We Got Here

Let’s briefly recap where this series brought us.

• ✅ Part 1: We built visibility first — discovering what state devices were actually in, instead of trusting assumptions.
• ✅ Part 2: We safely triggered (yes, 0x5944) the Secure Boot 2023 CA certificate update, without detonating the fleet.
• ✅ WinCsFlags.exe Bridge: We explained the mechanics of Secure Boot servicing.
• ✅ Part 3: We validated, at scale, that the trust chain was truly in place — with evidence, not vibes.

On paper, that should have been the end of the story.

But as reporting settled and validation dust cleared, a very specific class of devices started surfacing — the kind that makes every IT admin pause:

• UEFI mode: ✅
• Secure Boot: ❌
• OS: Fully functional, happily running Windows 11

Nothing was broken.
Nothing failed.

They simply NEVER HAD Secure Boot enabled — often for reasons that made sense years ago, like

• compatibility concerns,
• legacy imaging practices,
• forgotten exceptions, or
• the classic “don’t touch firmware unless you absolutely must” rule.

Those decisions weren’t wrong when they were made, and they certainly weren’t made with bad intentions. But like most reasonable shortcuts, they followed us into trust‑chain modernization as technical debt.

And here’s the uncomfortable truth:

You don’t finish a Secure Boot trust modernization story by ignoring devices that are capable, current, and quietly unenforced.

Leaving them alone is no longer neutral.
It’s a posture decision — just not a good one.

Important Reality Check (Before Anyone Panics)

Let’s separate two things people love to mash into one panic blob:

Secure Boot certificate updates (2023 trust chain)

Microsoft explicitly explains this as a certificate refresh required because 2011-era certificates begin expiring in June 2026. [techcommun…rosoft.com]

Devices without the new certs will still boot and receive most Windows updates — but they won’t receive future boot-level protections (boot manager trust, DB/DBX updates, revocations).

Secure Boot enforcement (ON/OFF)

This is a firmware posture control — it decides whether that trust chain is actively enforced at boot. Microsoft explicitly warns that disabling Secure Boot reduces protection and increases security/compliance risk. [support.mi…rosoft.com]

Microsoft’s own rollout guidance states

The deployment and monitoring steps are framed for devices having Secure Boot enabled — if Secure Boot is OFF in UEFI, those update steps are considered NOT APPLICABLE until enforcement is turned on. [support.mi…rosoft.com]

So no — if Secure Boot is OFF in UEFI, the certificate refresh workflow WILL NOT magically flip it to ON for you.

But yes — once you deliberately enable Secure Boot, you’re officially in the world where this trust chain matters long-term.

That’s exactly why Part 4 exists:
Enable Secure Boot deliberately — not impulsively — with controlled risk and a plan.

What this post DOES NOT cover: This post is not a legacy‑to‑UEFI conversion guide, not a firmware flashing walkthrough, and not a WinRE repair clinic. We’re solving one specific, high‑impact problem: Secure Boot is disabled on UEFI‑capable hardware.

Welcome to the Boss Fight

Everything up to this point was preparation.

Parts 1–3 earned confidence in:

• what you could see,
• what you could trigger,
• what you could prove.

Part 4 is where confidence stops being theoretical.

Because… enabling Secure Boot IS NOT

• a learning exercise, or
• a checkbox, or
• something you test once and scale with hope.

It’s where firmware, BitLocker, boot measurements, and user behavior intersect and collide — and mistakes stop being silent.

You are no longer validating outcomes.
You are changing posture.

And posture changes don’t forgive improvisation.

No more reconnaissance.
No more triggers.
No more proof.

Just deliberate action, controlled risk, and consequences you’re choosing — not discovering by accident.

Welcome to the boss fight.

The Real Risks (And Why You Should Still Do It)

Let’s be honest.

Turning Secure Boot ON will surface problems that have been hiding quietly for years — problems that never mattered because nothing was enforcing them at boot.

Secure Boot doesn’t introduce these issues.
It simply stops ignoring them.

Here are the real risks you must account for — upfront, and not during a panic escalation!

1️⃣ Invalid or Non‑Standard Bootloaders

Old imaging leftovers.
Ancient WinPE customizations.
Unsigned or unsupported drivers injected sometime around “it worked back then”.

Secure Boot has zero interest in your nostalgia.

If a bootloader, driver, or early‑boot component does not match what firmware expects, Secure Boot will block it — immediately and without apology.

This is why devices that have “booted fine for years” can suddenly fail once enforcement begins.

Nothing changed.
The platform simply stopped looking the other way.

2️⃣ BitLocker Without Proper TPM Binding

This one hurts the most at scale.

If BitLocker was enabled without proper TPM protector alignment, enabling Secure Boot will often change PCR measurements used by Bitlocker — which means BitLocker does exactly what it’s supposed to do:

🔐 Enters recovery mode.

If recovery keys are:

• not escrowed,
• not accessible,
• or assumed instead of verified,

you will lock users out during reboot.

This isn’t BitLocker being fragile.
This is BitLocker enforcing trust correctly.

BitLocker integrity protection commonly relies on TPM measurements including PCR 7, which is tied to Secure Boot state/integrity validation — so Secure Boot changes can legitimately push devices into Bitlocker recovery. This isn’t random. It’s the platform doing its job. [learn.microsoft.com], [learn.microsoft.com]

Which is why Secure Boot enablement must always be paired with deliberate BitLocker validation.

3️⃣ BIOS Password Reality

This is where theory meets fleet archaeology.

Many environments still have devices with:

• unknown BIOS admin passwords,
• vendor defaults that were never rotated,
• or no firmware protection at all.

Secure Boot enablement frequently requires:

• modifying protected firmware settings, or
• satisfying OEM security pre‑conditions.

If you don’t know who controls firmware access on a device, Secure Boot enablement will expose that gap immediately.

So… Why Do This At All?

Because leaving Secure Boot disabled doesn’t make these risks go away.

It simply means:

• early‑boot integrity isn’t enforced,
• compromises below the OS go undetected, and
• your “modern” platform quietly stops evolving where Microsoft expects it to.

Secure Boot OFF is not a safe default.
It’s a deferred RISK decision.

This post is not about pretending these risks don’t exist.
It’s about confronting them intentionally, methodically, and without surprises.

That’s the difference between reckless enforcement… and controlled posture change.

Can Intune Enable Secure Boot?

Short answer: No.
Long answer: Also no.

You’d think enabling Secure Boot would be as simple as flipping a configuration setting in Intune. But OEMs disagree.

Every vendor seems to have their own interpretation of the same question:

“How many steps can we hide behind a firmware menu before IT gives up?”

Here’s the reality:

• Secure Boot is a firmware‑level setting
• Changing it requires authenticated access to UEFI setup
• Windows CSPs can report Secure Boot state
• Windows CSPs cannot Enable or Disable it

That last point is where most people trip.

In the general OEM fleet case, there’s no universal CSP that flips Secure Boot ON. The exception is DFCI on supported devices, where Intune can manage UEFI settings via UEFI CSP—but that’s a special lane with hardware + Autopilot prerequisites.

This is not an Intune limitation.
This is a platform boundary.

If Intune Can’t Enable Secure Boot… How Do We?

In most enterprise fleets, Secure Boot enablement on existing UEFI systems collapses into two legitimate paths.

Important to note: Some environments may also leverage DFCI/UEFI CSP for firmware configuration where supported, but availability is OEM and model dependent. [learn.microsoft.com]

1️⃣ OEM‑mediated Enablement (Best‑Case Scenario)

Some OEMs support:

• BIOS configuration via OEM management utilities
• Password‑protected, auditable changes
• The ability to perform mass enablement — if all prerequisites are met

When this works, it’s elegant. When it exists, it’s worth using.

Caveat:
This varies wildly by:

• OEM
• model family
• firmware version
• and historical sins committed against the BIOS

Treat this path as opportunistic, not guaranteed.

If your hardware supports it — great.
If it doesn’t — don’t force it.

2️⃣ Manual / Assisted Enablement (The Reality Case)

This is where most enterprises actually land — not because it’s desirable, but because it’s predictable.

A typical flow looks like this:

1. Device is flagged via Intune reporting or posture assessment
2. A remediation ticket or task is raised
3. The user schedules downtime or hands the device to IT
4. Secure Boot is manually enabled in UEFI firmware
5. The device boots, validates, and re‑enters compliance

Is it glamorous? No.
Is it fast? Not really.
Is it controlled? Yes.

And most importantly: Is it safer than pretending these devices don’t exist? Absolutely.

But…

…and there will always be a but.

Intune Can’t — But It Has a Mechanism That Can!

Let’s refine the boundary from the previous section — because precision matters here.

Intune itself cannot enable Secure Boot.
There is no native policy, CSP, or direct firmware toggle.

That statement still remains true.

But stopping there would be incomplete.

Because while Intune cannot change firmware configuration directly, it can deliver the execution layer that invokes OEM‑supported firmware interfaces, when those interfaces exist, and prerequisites are met.

And this is where PowerShell enters the picture — not as a workaround, but as a supported control-plane extension.

When you work with Windows devices long enough, you learn to never forget your oldest, most reliable ally —  PowerShell.

The Correct Model: Orchestration, Execution, Enforcement

With PowerShell in the frame, the Secure Boot enablement model looks like this:

Intune provides orchestration:

• Targeting & scoping
• Eligibility filtering & exclusion logic
• Sequencing & retry control
• Reporting & blast‑radius control

PowerShell (via Intune) provides execution:

• Invocation of OEM‑supported firmware interfaces
• Prerequisite validation before any change is attempted
• Verification after reboot

OEM firmware ultimately decides and provides enforcement:

• If prerequisites are satisfied
• Whether the request should be rejected or accepted
• Whether Secure Boot can be enabled

This is not bypassing firmware safeguards.
This is operating within them.

Most importantly, this is how enterprise OEMs expect Secure Boot to be managed at scale.

Why Lenovo and Dell Matter Here

Before going further, let’s set an explicit scope boundary right here.

This guide focuses only on:

• Lenovo and Dell commercial devices having,
• Modern UEFI firmware with,
• OEM-supported configuration interfaces available.

Why?

Because that’s the fleet I actually have in my hands —
in production, in labs, and occasionally on my desk when they decide to misbehave.

And when it comes to firmware automation, there is one rule I do not bend:

Never — ever — trust anything you cannot test relentlessly on real hardware.

A note on community resources: 

Forums and community posts are absolute gold mines — many skilled IT professionals publish lifesaving solutions there, and every one of us has been rescued by them at some point.

But firmware configuration is different.

It requires precision, a thorough understanding of the underlying mechanism, and extensive testing on real hardware.

Community scripts are excellent research inputs.
They are not drop‑in production solutions.

Thus, while the community knowledge is invaluable, BIOS configuration changes are not something you blindly copy‑paste without knowing exactly what they’ll do on your hardware.

Firmware Automation Is Not Configuration Management

BIOS modification isn’t like:

• registry tweaks,
• CSP policies,
• or reversing a bad script with another script.

Firmware changes are closer to surgery.

• You don’t guess.
• You don’t assume.
• And you definitely don’t copy‑paste a BIOS configuration script from a forum and hope for the best.

Once firmware state changes, rollback options are limited, slow, or non-existent — and mistakes stop being theoretical very quickly.

What About Other OEMs?

Fair question — and here’s the honest answer:

• HP? Likely possible. HP provides tools like BIOSConfigUtility, but without equivalent hardware to validate behavior across models and BIOS versions, I won’t publish a production‑safe path.
• ASUS? Possibly. Enterprise tooling exists… somewhere in the shadows. Again, without repeatable testing, it stays out of scope.
• Acer, Panasonic, Fujitsu, MSI, insert‑your‑favorite‑OEM‑here? Probably scriptable to some degree.
  But without live devices to break, recover, and retest, I cannot stand behind the results.

This isn’t gatekeeping.
It’s engineering responsibility.

Why This Boundary Matters

Secure Boot enablement crosses the point where mistakes stop being silent.

At this layer,

Documented = Tested
Tested = Repeatable

Eligibility & Pre-flight Gate (the ‘no surprises’ filter)

Before any Secure Boot enablement attempt — scripted or manual — devices must pass this eligibility gate.

Not because we enjoy bureaucracy.
Because firmware posture changes have consequences.

• Confirm: UEFI mode ✅, Secure Boot supported ✅, Secure Boot currently OFF ✅
• Confirm BitLocker readiness + key escrow hygiene (because posture change triggers consequences) [learn.microsoft.com], [learn.microsoft.com]
• Confirm firmware prerequisites (model/BIOS versions matter)

If any of these fail → DO NOT proceed.

There is no “we’ll fix it after reboot” at this layer.

Gate 1 — Confirm UEFI mode + Secure Boot capability

This Part 4 flow assumes all of the following are true:

• ✅ Device is already in UEFI mode (not Legacy/CSM).
• ✅ Secure Boot is supported by the device (not just “UEFI exists”).
• ✅ Secure Boot is currently Off/Disabled in UEFI (the exact contradiction we’re fixing).

If you’re dealing with:

• Legacy → UEFI conversion
• broken boot partitions
• WinRE surgery
• firmware flashing as a prerequisite

…that’s a different post, a different blast radius, and a different set of nightmares.

Gate pass condition: UEFI ✅ + Secure Boot supported ✅ + Secure Boot currently OFF ✅

Gate 2 — BitLocker Reality Check

Secure Boot enablement changes what the TPM measures during boot.
And BitLocker loves measurements.

By default, BitLocker integrity protection commonly uses TPM PCR measurements — including PCR 7, which is associated with Secure Boot integrity validation.

Thus,

If you flip Secure Boot ON without preparing for BitLocker outcomes, you’re not “enabling a security feature” — you’re scheduling a recovery-key festival.

✅ What you must validate before touching firmware.

1. Is BitLocker even enabled?
2. Are keys escrowed and retrievable?
3. What protectors and PCR profile is in use?

Run and review, don’t just execute:

manage-bde -status C:
manage-bde -protectors -get C:

If your PCR validation profile includes PCR 7, Secure Boot state changes can legitimately trigger recovery if the protector chain isn’t aligned.

✅ Best-practice safety move (when you are ready to execute).

If your operational model allows it, suspend protection for the reboot window:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

This is not “weakening security forever.”
This is controlled change management so the platform doesn’t misinterpret your planned action as tampering.

Gate pass condition: You can prove keys are recoverable before you trigger posture change. ✅

Gate 3 — Firmware Prerequisites

Microsoft explicitly recommends representative testing across unique device buckets (manufacturer/model/firmware versions) because firmware compatibility determines whether Secure Boot-related changes behave predictably.

So your pre-flight data collection should include:

• Manufacturer / Model
• BIOS/Firmware version
• Baseboard identifiers

Example:

Get-CimInstance Win32_ComputerSystem | Select Manufacturer, Model
Get-CimInstance Win32_BIOS | Select SMBIOSBIOSVersion, ReleaseDate
Get-CimInstance Win32_BaseBoard | Select Manufacturer, Product

Gate pass condition: Firmware levels are known ✅ and you’ve validated behavior for that model family ✅

Gate 4 — Firmware Access Control

This is the part everyone discovers too late:

• BIOS admin password unknown
• Vendor default still set
• No password, but settings are “locked”
• OEM tool refuses to apply changes without preconditions

If you don’t have a reliable and consistent way to authenticate firmware changes, automation becomes theatre.

Gate pass condition: You have a repeatable, auditable method to modify the setting on that device family — either via OEM tooling or an assisted/manual route. ✅

Gate 5 — DFCI / UEFI CSP (optional lane, not your default story)

Some environments can manage firmware settings via DFCI, surfaced through the UEFI CSP in Intune — depends on platform/firmware support and isn’t universal.

Gate pass condition (if using this lane): Device + Firmware explicitly support DFCI/UEFI CSP operations. ✅

✅ Definition of Done

A device isn’t “done” because the setting was flipped. It’s done when it survives reality:

• ✅Secure Boot reports On (msinfo32 or Confirm-SecureBootUEFI)
• ✅Device boots normally across at least one reboot cycle (no recovery loop)
• ✅BitLocker protection state is healthy (no key prompt surprises)
• ✅Device returns to your defined compliance posture

Anything less is an incomplete posture change.

🧨 Hard stop conditions

Do not attempt Secure Boot enablement if any of the following are true:

• ❌UEFI mode isn’t confirmed
• ❌Secure Boot support is unclear
• ❌BitLocker keys are not escrowed / not retrievable
• ❌BIOS password ownership is unknown and OEM tooling requires it
• ❌You haven’t validated this model/firmware combo in a pilot ring

Because once firmware changes happen, rollback is not a Ctrl+Z moment.

It’s a “hope you like weekend shifts” moment.

So with the guardrail gates set, let’s now shift gears and get into the real action mode.

The Strategy – Two Roads Diverged in a BIOS Menu… and You Get to Pick One

There are two legitimate ways to automate Secure Boot enablement from Intune.

Both work.
Both are technically valid.
Both have trade‑offs.

The difference is how much control you want over timing, user experience, and blast radius.

Choose wisely.

🛠️ Option 1 — PowerShell as an Intune Remediation

Fast, lightweight, elegant… and slightly chaotic.

Intune Remediations are fantastic for:

• configuration drift
• registry changes
• posture enforcement
• “fix it quietly” tasks

Secure Boot enablement is not one of those tasks.

Why?

Enabling Secure Boot requires a reboot to take effect — and Remediations give you:

• ❌ No precise control over execution timing
• ❌ No built‑in user warning
• ❌ No graceful reboot handling

If your script includes a forced restart, Windows will happily comply:

• during a customer call
• during a leadership presentation
• during the one meeting the user promised wouldn’t be interrupted

Remediations can work — technically.
But for firmware‑level changes, they are too spontaneous for most enterprises.

Use this path only if:

• devices are unattended, or
• downtime is explicitly acceptable

Still valid.
Just not gentle.

🧳 Option 2 — Wrap It as an Intune Win32 App (With PSADT for Graceful Restarts)

This is the grown‑up, enterprise‑polite, user‑friendly option.

Packaging Secure Boot enablement logic as a Win32 app — ideally wrapped in PSADT — gives you:

• ✅ Full control over execution and detection
• ✅ Explicit install intent
• ✅ User notifications (before anything reboots)
• ✅ Deferral options
• ✅ Scheduled, predictable restarts
• ✅ Clean success/failure reporting

In other words:

You fix Secure Boot without triggering a company‑wide flood of “Why did my laptop restart in the middle of a Teams call?”

This is the method I recommend.
This is the method we deployed.

So to summarize:

Secure Boot enablement is not just a security change.
It’s a posture change with user impact.

Choose the path that matches your environment — not just what’s easiest to script.

Detecting Devices Ready for Secure Boot Enablement

Before we get to the OEM-specific script that do the actual magic, the detection logic must be locked in first. Because this logic applies regardless of delivery method, whether you are trying to enable Secure Boot using PowerShell via:

• Intune Remediation, or
• Win32 app packaging

This section is what allows you to say — with confidence and audit defensibility:

“I’m not running firmware logic everywhere… I’m running it only where it’s allowed to succeed.”

Readiness Classification (Simple but Critical)

A minimal, reliable readiness filter you can use in Intune reporting or detection logic looks like this:

This ensures you’re building a targeted remediation set, not a blanket policy — and that execution is limited to devices that are both:

• technically eligible, and
• operationally safe

What We’re Actually Doing in Detection

At a high level, this is just gatekeeping — and that’s intentional.

Gatekeeper rules (minimum):

• ✅ If the device IS NOT UEFI → abort
• ✅ If the device IS UEFI and Secure Boot IS already ON → abort
• ✅ Only proceed when IS UEFI = True but Secure Boot ON = False

Anything outside that boundary is not a remediation candidate — it’s noise.

Detection Logic (Baseline: UEFI + Secure Boot OFF)

# Secure Boot Enablement - Detection / Gatekeeper
# Exit 0 = not applicable / nothing to do
# Exit 1 = eligible and needs enablement (Secure Boot is OFF)

# --- Gate 1: UEFI check ---
$firmwareType = (Get-ComputerInfo -Property BiosFirmwareType).BiosFirmwareType
if ($firmwareType -ne 'UEFI') {
    Write-Output "Firmware type: $firmwareType. Not UEFI. Abort."
    exit 0
}

# --- Gate 2: Secure Boot state check ---
$sb = $null
try {
    $sb = Confirm-SecureBootUEFI -ErrorAction Stop
}
catch {
    # Confirm-SecureBootUEFI throws if unsupported, not admin, or on some VMs
    $sb = $null
}

switch ($sb) {
    $true {
        Write-Output "UEFI device with Secure Boot ON. Nothing to do."
        exit 0
    }
    $null {
        Write-Output "Secure Boot state unknown/unsupported. Abort."
        exit 0
    }
    default {
        Write-Output "UEFI device with Secure Boot OFF. Eligible for enablement."
        exit 1
    }
}

Why This Detection Is Safe?

• It ONLY runs on UEFI devices
• It ONLY runs when Secure Boot is OFF
• It gracefully aborts when Secure Boot state can’t be determined

No guessing.
No forced execution.
No accidental firmware interaction.

That’s a proper blast-radius limiter.

How to Use This Detection in Both Delivery Models

A) If you choose to use Intune Proactive Remediation

Use the script as your Detection script:

• Exit 1 → Noncompliant → Remediation runs
• Exit 0 → Compliant / Not applicable → Remediation does not run

Your remediation script then becomes the OEM-specific “do the thing” script.

B) If you choose to use Win32 App

⚠️ In Intune Win32 “Requirement (Script)”, the IME expects the PowerShell process to exit with code 0 so it can evaluate the script output. If the process exits non‑zero exit code, the requirement is treated as not fulfilled and the app won’t be considered applicable.[nicolonsky.ch]

You can use the same logic as above as Requirement check for Intune win32 app, but refactored to:

• Exit 0 when firmware is UEFI but Secure Boot is Off.
• Output exactly this string with above exit code: UEFI device with Secure Boot OFF. Eligible for enablement.
• Exit 1 → For all other cases.

Once this is done, in your Win32 app → Requirements → Add → Script:

• Value: UEFI device with Secure Boot OFF. Eligible for enablement.
• Script output data type: String
• Operator: Equals

This ensures the Win32 app executes only on devices that meet the Secure Boot readiness criteria.

PowerShell That Turns Secure Boot Back On (Lenovo + Dell)

Once detection and scoping are in place, this is where we move from readiness to execution.

This section covers how Secure Boot is actually enabled, using OEM‑supported firmware interfaces — for Lenovo and Dell commercial PCs.

Enabling Secure Boot on Commercial Lenovo

While researching existing approaches, I came across a script called Enable‑SecureBootOnLenovo.ps1. The goal was simple:

Don’t reinvent the wheel unless I absolutely have to.

That said — and this is worth repeating — never trust scripts that claim to tweak firmware settings unless you fully understand how they work and what guardrails they rely on.

Following that principle, I tested this script extensively across supported Lenovo models I had access to.
And I can confirm that it does what it claims — and it does it using documented, OEM‑supported mechanisms.

You can use it as‑is.
But you should understand what it’s doing.

How Lenovo Exposes BIOS Configuration

Lenovo business‑class devices expose UEFI firmware settings through WMI/CIM classes under:

root\wmi

Commonly used classes include:

• Lenovo_SetBiosSetting
• Lenovo_SaveBiosSettings

The classic two‑step model works like this:

1️⃣ Stage a setting
SetBiosSetting("Setting,Value")

2️⃣ Commit staged changes
SaveBiosSettings()

This pattern is documented in Lenovo’s BIOS WMI deployment guides and has existed across multiple firmware generations. [support.lenovo.com]

What the Script Actually Does

At its core, Secure Boot enablement boils down to two calls.

Step 1: Stage the Secure Boot setting

gwmi -Class Lenovo_SetBiosSetting -Namespace root\wmi).SetBiosSetting("SecureBoot,Enable")

What’s happening here:

• gwmi is an alias for Get-WmiObject (Windows PowerShell)
• It connects to the Lenovo_SetBiosSetting class in root\wmi
• That class exposes firmware configuration hooks provided by Lenovo
• The method SetBiosSetting() is invoked directly on the WMI instance
• The parameter is a single positional string in the format: SettingName,Value
• This stages the change — it does not persist it

At this point, nothing has been written to NVRAM yet.

Step 2: Commit the staged changes

gwmi -Class Lenovo_SaveBiosSettings -Namespace root\wmi).SaveBiosSettings()

This call:

• Invokes the SaveBiosSettings() method
• Commits all pending staged changes to firmware NVRAM
• Causes the changes to take effect — typically after the next reboot

That’s the entire flow.

No hacks.
No undocumented calls.
Just OEM‑supported firmware interaction.

Important Notes & Gotchas

There are some realities you must account for up front.

• Must run as Administrator (for local testing or execution)
• Requires a Lenovo business‑class device that supports the BIOS WMI interface
  (ThinkPad, ThinkCentre, ThinkStation — model and BIOS dependent)
• Restart is required for Secure Boot enablement to take effect

BIOS / Supervisor Password Considerations

In our environment, no Supervisor/BIOS password is set. Neither the original script nor the commands shown here handle password‑protected firmware.

If a BIOS password is configured:

• Calls may fail silently or no‑op
• Some Lenovo models require:
  • SetBiosSetting("Setting,Value,Password"), or
  • a separate authentication / password‑handling method
• Behavior varies by model and firmware generation

This must be validated before attempting fleet‑wide execution.

Common Failure Reasons (Lenovo)

If the script fails or it runs but Secure Boot state does not changes, the cause is usually one of the following:

• 🔴Script running without elevated privileges
• 🔴Device is not a supported Lenovo model, or BIOS version is too old
• 🔴Supervisor / BIOS password exists but was not supplied
• 🔴Secure Boot prerequisites are not met
  (e.g. CSM / Legacy Boot still enabled — Secure Boot requires pure UEFI mode)

These are not script failures.
They are firmware guardrails doing exactly what they’re supposed to do.

Enabling Secure Boot on Commercial Dell

For commercial Dell laptops and desktops, there are two viable and supported enablement paths:

• Dell Command | PowerShell Provider (DellBIOSProvider)

A modern, native PowerShell module that exposes firmware attributes through the DellSmbios:\ PSDrive — including Secure Boot.

✅ Preferred approach for online Windows execution.

• Dell Command | Configure (CCTK)

The classic BIOS configuration tool — reliable in WinPE, task sequences, or constrained environments where PowerShell modules aren’t practical.

⚠️ More complex; certain Secure Boot modes may require manual key restoration in BIOS first.

Both methods are vendor‑supported. The choice depends on execution context, not preference.

Here, for this blog post, I will stick with DellBIOSProvider for enabling Secure Boot on Dell commercial PCs.

Enabling Secure Boot via DellBIOSProvider

(Simple, focused, and preferred)

This approach uses Dell’s supported PowerShell provider, which abstracts firmware interaction behind a structured PSDrive. [dell.com]

OEM Validation

$cs = Get-CimInstance -ClassName Win32_ComputerSystem
$manufacturer = ($cs.Manufacturer).Trim()
$model        = ($cs.Model).Trim()

Write-Output "Detected OEM: $manufacturer | Model: $model"
if ($manufacturer -notmatch 'Dell') {
    Write-Output "Device not Dell. Abort."
    exit 0
}

Install and Import Dell BIOS Provider

if (-not (Get-Module -ListAvailable -Name DellBIOSProvider)) {
    try {
        [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    } catch {}
    Install-Module -Name DellBIOSProvider -Force -Scope AllUsers -ErrorAction Stop
}

Import-Module -Name DellBIOSProvider -Force -ErrorAction Stop

Define Desired Firmware State

Not all of these settings are strictly required for Secure Boot, but they represent a known‑good, UEFI‑native posture commonly used in enterprise fleets.

$Settings = @(
    @{ Name = "BootList"; DesiredValue = "Uefi";      Location = "DellSmbios:\BootSequence" }
    @{ Name = "SecureBoot"; DesiredValue = "Enabled"; Location = "DellSmbios:\SecureBoot" }
    @{ Name = "Fastboot"; DesiredValue = "Thorough";  Location = "DellSmbios:\POSTBehavior" }
    @{ Name = "Virtualization"; DesiredValue = "Enabled"; Location = "DellSmbios:\VirtualizationSupport" }
    @{ Name = "UefiNwStack"; DesiredValue = "Enabled"; Location = "DellSmbios:\SystemConfiguration" }
    @{ Name = "EmbNic1"; DesiredValue = "EnabledPxe"; Location = "DellSmbios:\SystemConfiguration" }
    @{ Name = "CapsuleFirmwareUpdate"; DesiredValue = "Enabled"; Location = "DellSmbios:\Security" }
)

Apply Settings

if ((Get-Location).Path -ne "DellSmbios:\") {
    Set-Location -Path DellSmbios:\ -ErrorAction Stop
}

foreach ($Setting in $Settings) {
    Write-Output "Processing $($Setting.Name)"
    $CurrentValue = (Get-Item "$($Setting.Location)\$($Setting.Name)").CurrentValue

    if ($CurrentValue -ne $Setting.DesiredValue) {
        Write-Output "Updating $($Setting.Name) to $($Setting.DesiredValue)"
        Set-Item "$($Setting.Location)\$($Setting.Name)" -Value $Setting.DesiredValue -PassThru
    }
    else {
        Write-Output "$($Setting.Name) already correctly set. No change needed."
    }
}

Write-Output "Dell remediation complete. Reboot required."
# Restart-Computer -Force   ## Commented Out. Uncomment for action.

This approach uses Dell’s supported PowerShell provider path and interacts directly with firmware attributes exposed by the OEM — no undocumented behavior.

Common Failure Reasons (Dell)

When Secure Boot enablement fails on Dell systems, it is almost always due to one of the following:

• 🔴 Not running as Administrator
• 🔴 Device is not a supported Dell commercial model. Consumer lines or older platforms may not expose required firmware attributes.
• 🔴 DellBIOSProvider module not available or blocked. Common causes:
  • PowerShell Gallery access restricted
  • TLS protocol issues
  • Module installation blocked by policy
• 🔴 BIOS Admin password exists but is not supplied. This is one of the most common failure points and often looks like a silent no‑op.
• 🔴 Secure Boot prerequisites not met Examples:
  • Legacy Option ROMs enabled
  • Boot mode not fully UEFI
  • Secure Boot keys not present or in Audit / Custom mode

Again, these are not script failures.
They are firmware guardrails doing exactly what they’re supposed to do.

Where This Leaves Us

By the end of this phase, your eligible Lenovo + Dell fleet should be in a very different place than where it started:

• UEFI: ✅ Yes
• Secure Boot: ✅ ON
• Users: Informed — not surprised
• Helpdesk: Not dealing with “my laptop restarted mid‑Teams” tickets

That’s not accidental. That’s what happens when firmware change is treated as posture management — not a fire drill.

Closing Thoughts

Secure Boot being disabled on UEFI devices is not a failure.

Ignoring it is.

Secure Boot isn’t magic. It doesn’t replace EDR. It doesn’t stop users from clicking nonsense.

What it does do is remove an entire class of boot‑level attacks from your threat model — quietly, deterministically, and before Windows even loads.

And the Secure Boot 2023 CA update was your forcing function to finally look at this layer properly.

This series was never about flipping switches.
It was about systematically dragging an enterprise fleet into modern security reality — without breaking users, without creating emergencies, and without losing your mind in the process.

If this series gave you anything, I hope it was:

• Better visibility into what your fleet actually looks like
• Safer rollout patterns you can repeat and adapt
• Stronger instincts around firmware‑level change management

And if you’ve reached this point:

• You did the discovery
• You respected platform boundaries
• You didn’t confuse reporting with enforcement
• And you finished the job

That’s what grown‑up endpoint security looks like.

Because the boot chain is no longer “below the OS”.

It is the security perimeter.