I have multiple Lenovo machines in my office. This morning I was checking a ThinkPad P16 Gen 3 mobile workstation and a ThinkStation P3 Ultra desktop in the wake Patch Tuesday’s update. Both run Windows 11, with Secure Boot enabled. While poking around in their Secure Boot UEFI settings, I noticed something that stopped me cold. These two machines report different Secure Boot SVN values. Same vendor. Roughly the same generation. Same security feature switched on. So why the difference? As it turns out, the answer is genuinely interesting, and it matters if you manage a mixed fleet of Lenovo hardware. Bottom line: Lenovo PC SVNs can vary. Let’s explore…
How Is It That Lenovo PC SVNs Can Vary?
SVN stands for Secure Version Number — a monotonically increasing counter (meaning it only ever goes up, never down). It’s embedded directly in UEFI firmware. Its job is to record how many Secure Boot security revisions a device has seen over its lifetime.
Let’s distinguish the Secure Boot SVN from two things it often gets confused with. First, it is not the same as the Secure Boot DB/DBX (the UEFI allow-list and deny-list databases that control which bootloaders and drivers are trusted or revoked). Second, it is not the same as your plain BIOS version number. The BIOS version tracks firmware feature releases; SVN tracks security-policy changes.
The practical muscle behind the SVN is its rollback prevention. If a piece of firmware or a bootloader carries a Secure Boot SVN lower than the minimum value stored in non-volatile memory, the UEFI stack simply refuses to load it. That makes it much harder for an attacker to downgrade your firmware to a vulnerable older version — a classic attack vector the SVN is designed to close.
Lenovo P16 Gen 3 vs. ThinkStation P3 Ultra
The lead-in graphic shows the output from Garlin’s check script and the get-SecureBootSVN command on the P16. Here’s what I found on the P3 Ultra, by way of contrast and comparison:
For the P16 Gen3 SVN is 8.0; for the TSP Ultra, it’s 9.0. WTF?
My first instinct was that something was misconfigured. It was not. These two machines serve quite different market segments. The P16 Gen 3 is a mobile workstation, designed for road warriors and power users who demand both portability and security. The ThinkStation P3 Ultra is a compact desktop workstation, built for workstation-class compute in a fixed location, where stability and long-term reliability tend to trump rapid update cycles.
Critically, the two platforms ship from separate firmware engineering teams inside Lenovo, each running its own BIOS release cadence. ThinkPad-family machines — including the P16 series — have historically received more frequent UEFI updates, driven by the constant churn of mobile power-management tuning, thermal firmware, and rapid security patch integration. ThinkStation platforms, by contrast, follow a slower, more deliberate update cadence that prioritizes stability for long-running workloads. Neither approach is wrong. They just produce different Secure Boot SVN trajectories over time. This time, however, the usual order got stood on its head: the ThinkStation preceded the ThinkPad.
How the SVN Update Pipeline Works
To really understand the divergence, you need to know how the Secure Boot SVN update pipeline actually flows. It is a three-layer process, and each layer operates on its own schedule.
- Microsoft issues a Secure Boot policy change or DBX update. A concrete example: the revocation of vulnerable bootloaders tied to CVE-2023-24932 (the so-called BlackLotus UEFI bootkit vulnerability). Microsoft publishes updated Secure Boot DB and DBX payloads, and the associated policy mandates a new minimum SVN level.
- OEMs like Lenovo incorporate updated SVNs into a new BIOS/UEFI release. Here is where the divergence begins. Lenovo’s mobile and desktop firmware teams each pick up the Microsoft changes on their own schedules. The ThinkPad team typically ships updated BIOS builds faster; the ThinkStation team takes longer to validate the changes against its broader ISV (independent software vendor) compatibility matrix.
- Windows Update stages Secure Boot DB/DBX changes to end-user systems in controlled waves. Microsoft doesn’t push Secure Boot policy changes to every machine simultaneously. It uses a staged rollout — sometimes spanning months — so different machines in your fleet can legitimately sit at different SVN levels even if they have all received recent Windows updates.
One more wrinkle worth noting: Lenovo now pre-configures newer-generation machines from the factory with both the legacy CA 2011 and the new CA 2023 Secure Boot certificates already in place. Older units, however, need a BIOS update to pick up those 2023 trust anchors. That factory-level difference alone can produce an SVN gap between otherwise-similar machines.
ℹ️ Key Insight
What Should You Do?
The good news is that remediation steps here are straightforward. Here is what I recommend:
- Update BIOS/UEFI on all machines to the latest Lenovo-published version. Head to the Lenovo Support site (support.lenovo.com), search for your specific model, and grab the current BIOS update. For the ThinkStation P3 Ultra in particular, confirm the release notes explicitly mention CA-2023 certificate integration. Do not rely on Windows Update alone to deliver BIOS updates; go direct to Lenovo.
- Verify CA-2023 is present in the Secure Boot DB using PowerShell. Run the following one-liner on each machine to confirm the 2023 trust anchor is actually installed:
A result of True means the CA-2023 certificate is in the DB and your Secure Boot SVN should reflect the update. A result of False means the machine still needs the BIOS update or the Windows Update wave has not yet reached it.
- For managed fleets, track SVN parity via Intune or MECM compliance policies. Build a compliance rule that surfaces machines whose Secure Boot SVN falls below your defined minimum baseline. That way you can proactively identify stragglers before 2026 certificate expiration forces your hand.
Bottom line: Secure Boot SVN divergence across a heterogeneous fleet of Lenovo machines is normal, expected behavior. It’s no red flag. The firmware update pipeline simply operates in waves, and different product families move at different speeds. What matters is establishing a consistent minimum Secure Boot SVN across all your machines well before the 2026 CA expiration deadline arrives. Start the BIOS update sweep now, and you’ll have plenty of time to close gaps without deadline pressure.


