Secure Boot + TPM: What They Protect (and What They Don’t)

Start with the threat model, not the checkbox

Secure Boot and the TPM are often sold as “boot security.” That’s like selling “seatbelts.” Seatbelts are great—against specific problems. They do nothing against others. Your job is to pick the right safety features for the crash you’re actually likely to have.

What Secure Boot is for (in one sentence)

Secure Boot is about enforcement: only trusted boot components (firmware → bootloader → kernel) are allowed to run, based on signature verification.

What the TPM is for (in one sentence)

The TPM is about secrets and evidence: it can securely hold keys and it can record measurements of the boot process (PCRs) so you can bind access to “known-good” states or prove what happened.

Realistic boot threats you can actually mitigate

• Evil maid attacks: someone gets hands-on access to a powered-off laptop or server and tampers with the boot chain or grabs disk keys.
• Bootkit persistence: malware plants itself below the OS (bootloader, early kernel, initramfs) so reimaging “from inside the OS” won’t clean it.
• Supply chain / golden image drift: a node boots something other than what you built, and you want a cryptographic way to detect it.
• Credential theft via offline disk access: attacker steals a disk or a whole machine and tries to read it elsewhere.

Threats these features won’t solve by themselves

• Remote RCE in your app once the OS is up.
• Kernel exploits post-boot that don’t require replacing the boot chain.
• Bad insiders with admin access who can sign their own malware if you let them hold signing keys.
• Vulnerable firmware that happily lies about what it verified.

One quote worth keeping on your wall, because it prevents nonsense projects:

Paraphrased idea (Gene Kim): “Improving reliability is about improving the system of work, not heroics during outages.”

Secure Boot and TPM are system-of-work improvements when you operationalize them: key management, update flows, attestation checks, and break-glass procedures. If your plan is “turn it on and hope,” that’s not a plan. That’s a future incident report.

Secure Boot: what it enforces

UEFI Secure Boot is firmware-level signature enforcement. The firmware will only execute EFI binaries that are signed by a key it trusts. That’s the core. Everything else—shim, MOK, distro tooling—is plumbing to make that work in real life.

The chain of trust, concretely

A typical Linux chain on commodity hardware looks like this:

• UEFI firmware contains trusted keys and verification logic.
• shim is a small signed bootloader that’s usually signed by a widely trusted key and can load additional keys.
• GRUB/systemd-boot is loaded by shim and may itself verify the kernel and initramfs.
• Kernel loads modules; module signature enforcement is a separate control.
• initramfs brings up storage and mounts root; if this is untrusted, you can lose everything before your “real” OS starts.

Secure Boot’s value is simple: it prevents an unsigned (or wrongly signed) EFI component from running. That blocks a class of bootkits and tampering attempts. It also blocks you at 2 a.m. if your signing workflow is sloppy.

Keys you will run into (and should respect)

• PK (Platform Key): top-level key controlling Secure Boot configuration.
• KEK (Key Exchange Key): authorizes updates to signature databases.
• db: allowed signatures/hashes.
• dbx: revoked signatures/hashes (the “nope list”).
• MOK (Machine Owner Key): a shim-managed key list commonly used to allow custom kernels/modules without replacing platform keys.

If you remember only one operational rule: treat signing keys like production database credentials. If your signing key leaks, “Secure Boot enabled” becomes “Secure Boot enables persistence for attackers.”

Joke #1: Secure Boot is like a bouncer with a clipboard—very effective until you hand out photocopied wristbands in the parking lot.

TPM: what it measures, stores, and refuses to forget

The TPM (Trusted Platform Module) is a tamper-resistant component (chip or firmware-backed) designed to do a few things extremely well: protect keys, produce cryptographic proofs, and record measurements of early boot state into PCRs (Platform Configuration Registers).

TPM 2.0 basics that matter in operations

• PCRs: special registers that record a hash chain of measurements. You don’t “set” PCRs; you extend them, meaning PCR = HASH(PCR || new_measurement). This makes history sticky.
• Sealing: encrypting (wrapping) a secret so the TPM will only release it if the machine is in a specific state (often defined by PCR values).
• Attestation: producing a signed statement about PCR values (and sometimes event logs), so a remote party can verify boot state.
• Endorsement and identity keys: keys that let a TPM prove it’s a genuine TPM, and then speak as a particular machine.

The “TPM auto-unlock” trap

Using the TPM to auto-unlock LUKS/BitLocker is common. It’s also where people get burned, because they confuse convenience with security.

If you seal a disk key to PCRs that measure bootloader and kernel, you’re forcing the attacker to keep those intact to get the key. If you seal it to a weak set of PCRs—or worse, you don’t use PCR binding at all—you might just be storing the key in a fancy box that opens whenever it feels like it.

TPM is not a magic “secure enclave for everything”

The TPM is good at small secrets and proofs. It is not a high-throughput crypto accelerator for your database. It’s also not a substitute for patching firmware, controlling admin access, or having tamper-evident processes in the supply chain.

Joke #2: A TPM is a vault, not a nanny; it won’t stop you from leaving the server room door open.

Secure Boot vs Measured Boot: enforcement vs evidence

These two get conflated because both are about boot integrity. They are different tools with different failure modes.

Secure Boot (enforcement)

• Question it answers: “Should this binary be allowed to execute?”
• Mechanism: signature verification against allowed keys (db) and revocations (dbx).
• Failure mode: you don’t boot.
• Operational pain: signing workflow, key rollovers, revocations, third-party drivers.

Measured Boot (evidence)

• Question it answers: “What did execute?”
• Mechanism: measurements extended into PCRs + event log; later attested.
• Failure mode: you might still boot, but your attestation fails or your sealed secrets don’t release.
• Operational pain: PCR drift due to updates, firmware changes, or configuration changes.

In practice, strong platforms do both: Secure Boot prevents obvious tampering; measured boot gives you auditability and conditional trust for key release.

What Secure Boot + TPM do not protect

This is the section that prevents budget waste. If you’re spending political capital on boot security, make sure you’re not claiming it fixes things it does not.

They don’t stop runtime compromise

If an attacker gets code execution in your running OS and escalates to root, Secure Boot doesn’t kick them out. The TPM doesn’t call the cops. You still need kernel hardening, patching, least privilege, and real monitoring.

They don’t guarantee firmware is honest

Secure Boot and measured boot depend on firmware behaving correctly. If firmware is compromised, it can lie about what it verified or measured. This is why firmware update hygiene is not optional, and why some environments require hardware roots of trust plus verified firmware update paths.

They don’t protect against “authorized” malware

If your org signs a malicious bootloader with a trusted key, Secure Boot will happily boot it. If an attacker steals your signing key, your enforcement layer becomes their distribution channel. Put signing keys in HSM-backed processes, gate usage, and log every signing event like it’s a production deploy.

They don’t solve stolen-session problems

Secure Boot and TPM can help protect disk keys at rest. They do not protect an already-unlocked machine from a logged-in attacker, stolen SSH agent, or compromised SSO session. Different threat. Different controls.

They don’t make recovery “easier”

They often make recovery harder. That’s the point: you’re enforcing integrity. Plan for break-glass recovery using recovery keys, out-of-band console access, and documented procedures for key enrollment.

Interesting facts and historical context (the parts people forget)

1. Secure Boot arrived with mainstream UEFI PCs in the early 2010s, and it immediately collided with the reality that people install operating systems that aren’t the factory default.
2. TPM 1.2 predates TPM 2.0 by years; TPM 2.0 expanded algorithms and flexibility, which is great until you try to standardize it across a messy fleet.
3. Measured boot is older than most cloud-native careers: the concept of a chain of measurements goes back to early trusted computing research, not to modern DevSecOps branding.
4. The UEFI revocation list (dbx) is a real operational lever: it can brick older bootloaders after an update if you depend on revoked components.
5. shim exists because reality exists: it’s a practical compromise to let distros participate in Secure Boot ecosystems without each user managing platform keys from day one.
6. Module signing is not the same thing as Secure Boot: even with Secure Boot on, unsigned kernel modules can still be a path to kernel compromise unless module signature enforcement is configured.
7. PCR values change for boring reasons, like a firmware update, a boot order change, or toggling certain UEFI settings. That’s not “TPM being flaky,” that’s measurement doing its job.
8. Virtual TPMs (vTPM) exist and are widely used in virtualization stacks; they’re useful, but your trust shifts to the hypervisor and its key management.

Practical tasks: commands, output meaning, and the decision you make

These are the checks I run when someone says “Secure Boot is on” or “TPM is configured.” I’m not interested in vibes. I’m interested in evidence.

Task 1: Verify Secure Boot state from Linux

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

What it means: UEFI Secure Boot is enabled and the kernel sees it as such.

Decision: If it’s disabled on machines that should enforce boot integrity, fix firmware policy; if enabled on a developer workstation that needs unsigned kernels, plan for MOK or separate profiles.

Task 2: Confirm UEFI boot mode (UEFI vs legacy BIOS)

cr0x@server:~$ test -d /sys/firmware/efi && echo UEFI || echo Legacy
UEFI

What it means: Secure Boot requires UEFI mode; legacy mode makes this entire conversation mostly academic.

Decision: If you see “Legacy” on hardware that should be secured, you have a build/firmware baseline problem.

Task 3: Inspect enrolled MOK keys (common in Linux fleets)

cr0x@server:~$ mokutil --list-enrolled | head
MokListRT:
  SHA1 Fingerprint: 12:34:56:78:90:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88
  Subject: CN=Corp Kernel Signing CA

What it means: shim will trust binaries signed by these keys (depending on configuration).

Decision: If you don’t recognize the subject, treat it as a potential policy breach. If you do, make sure the private key is controlled like a production secret.

Task 4: Check whether the bootloader and kernel are signed (Debian/Ubuntu style)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Windows UEFI Driver Publisher
image signature certificates:
 - subject: /CN=Canonical Ltd. Secure Boot Signing

What it means: The EFI binary contains a signature chain. Secure Boot enforcement is only as good as what you actually execute.

Decision: If the signature issuer is unexpected for your environment, you may be trusting broader keys than you intended. For strict environments, use your own PK/KEK/db strategy.

Task 5: Verify kernel module signature enforcement status

cr0x@server:~$ cat /sys/module/module/parameters/sig_enforce
Y

What it means: The kernel requires signed modules (as configured).

Decision: If “N” on systems exposed to untrusted code, consider enabling it; if “Y” breaks vendor drivers, you need a clean module signing workflow, not a late-night exception.

Task 6: Confirm TPM device presence

cr0x@server:~$ ls -l /dev/tpm* 2>/dev/null
crw------- 1 root root  10, 224 Feb  5 10:12 /dev/tpm0
crw------- 1 root root 253,   0 Feb  5 10:12 /dev/tpmrm0

What it means: TPM is exposed to the OS. /dev/tpmrm0 is the resource manager interface (preferred for many tools).

Decision: If missing, check BIOS/UEFI settings (TPM disabled), missing drivers, or VM configuration (no vTPM attached).

Task 7: Read TPM capabilities to confirm TPM 2.0

cr0x@server:~$ tpm2_getcap properties-fixed | grep -E 'TPM2_PT_FAMILY_INDICATOR|TPM2_PT_MANUFACTURER'
  TPM2_PT_FAMILY_INDICATOR: "2.0"
  TPM2_PT_MANUFACTURER: "INTC"

What it means: Confirms TPM family and manufacturer. This helps when you’re debugging inconsistent behavior across hardware revisions.

Decision: If you expected 2.0 but see something else (or tool errors), stop and standardize hardware/firmware or adjust tooling accordingly.

Task 8: Dump current PCR values (snapshot)

cr0x@server:~$ tpm2_pcrread sha256:0,2,4,7
sha256:
  0 : 2F4A...9C11
  2 : A1B2...C3D4
  4 : 88EE...1020
  7 : 0D0C...BEEF

What it means: PCRs are hashes representing measured boot state (depending on firmware and configuration). PCR 7 is commonly associated with Secure Boot policy state on many platforms.

Decision: Use these values to detect drift or bind secrets. If PCR 7 changes unexpectedly after updates, expect sealed secrets to stop unsealing until you reseal or adjust policy.

Task 9: Check IMA/EVM measurement logs (if enabled)

cr0x@server:~$ test -r /sys/kernel/security/ima/ascii_runtime_measurements && head -n 3 /sys/kernel/security/ima/ascii_runtime_measurements
10 8b6c2f0c8d9e1e... ima-ng sha256:... boot_aggregate
10 1a2b3c4d5e6f... ima-ng sha256:... /usr/lib/systemd/systemd
10 9f8e7d6c5b4a... ima-ng sha256:... /usr/bin/sudo

What it means: IMA extends measurement beyond early boot into runtime file measurements (if configured). Different control, but often paired with TPM attestation.

Decision: If you’re building attestation, decide whether you need just boot integrity or ongoing file integrity evidence. Don’t enable IMA in production without a rollout plan; it can be loud.

Task 10: Confirm LUKS is using TPM-based unlocking (systemd-cryptenroll example)

cr0x@server:~$ sudo systemd-cryptenroll --dump /dev/nvme0n1p3 | sed -n '1,25p'
CRYPTTAB ENROLLMENT:
  Entry Token 0:
        Token Type: systemd-tpm2
        PCRs: 7
        SRK Handle: 0x81000001

What it means: The volume has a TPM2 token enrolled, bound to PCR 7 in this example.

Decision: PCR 7-only binding is common and sometimes acceptable, but often not sufficient for high assurance. Consider binding additional PCRs (e.g., bootloader/kernel-related) based on your platform and tolerance for update breakage.

Task 11: Test unsealing behavior by simulating a policy mismatch (safe read-only check)

cr0x@server:~$ sudo systemd-cryptenroll --tpm2-pcrs=0+7 --dry-run /dev/nvme0n1p3
Failed to enroll TPM2 token: PCR 0+7 policy would change (existing token uses PCRs: 7)

What it means: Changing PCR policy changes when the TPM will release the key. This is why “just bind to more PCRs” is not free.

Decision: Decide based on threat model: more PCRs usually increases integrity but increases operational coupling to updates and configuration changes.

Task 12: Inspect boot entries and confirm you’re booting what you think you’re booting

cr0x@server:~$ sudo efibootmgr -v | head -n 15
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,2c9d...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

What it means: Shows the path to the EFI binary actually used. Attackers and accidents both love alternate boot entries.

Decision: If BootCurrent isn’t your expected path, fix boot order and remove stale entries. On servers, lock down firmware setup access and log changes.

Task 13: Check for Secure Boot-related boot failures in the journal

cr0x@server:~$ sudo journalctl -b -0 | grep -iE 'secure boot|shim|mok|verification|lockdown' | head
kernel: secureboot: Secure boot enabled
kernel: Lockdown: integrity: Kernel is locked down from EFI Secure Boot mode
shim: MokManager: Processing MOK enrollment request

What it means: Confirms lockdown mode and shows key enrollment events.

Decision: If you see verification errors after updates, you likely have a signing mismatch or revocation event. Stop guessing and validate signatures and dbx state.

Task 14: Determine kernel lockdown mode (common with Secure Boot on)

cr0x@server:~$ cat /sys/kernel/security/lockdown
integrity [confidentiality]

What it means: The kernel is in lockdown mode, restricting certain actions that could bypass integrity guarantees.

Decision: If your tooling relies on restricted interfaces (like some debugging), plan alternative workflows. Don’t disable Secure Boot just to make your debugger happy; use proper signed kernels or controlled debug builds.

Task 15: Inspect dbx updates (revocations) that can break boot

cr0x@server:~$ sudo mokutil --dbx | head
dbx:
  0: sha256 3f2a...d91c
  1: sha256 7a9b...0011

What it means: Lists revoked hashes/certs in dbx as seen via mokutil.

Decision: If a bootloader you rely on appears in dbx (directly or via cert chain), you need to update boot components across the fleet before revocation enforcement strands nodes.

Task 16: Confirm TPM is not in a weird “needs attention” state

cr0x@server:~$ dmesg | grep -iE 'tpm|crb|tis' | head -n 10
tpm_tis 00:05: 2.0 TPM (device-id 0x1B, rev-id 16)
tpm tpm0: TPM2.0 device found (CRB interface)

What it means: Kernel recognizes TPM and interface. Errors here often correlate with firmware misconfigurations or buggy BIOS revisions.

Decision: If you see timeouts or locality errors, prioritize firmware updates or platform fixes before you build “TPM-dependent” systems on top.

Fast diagnosis playbook: find the bottleneck fast

When boot security breaks, people tend to flail. Don’t. Use a short playbook and you’ll usually find the culprit in minutes.

First: is it enforcement failing or key release failing?

• Machine won’t boot at all, drops to firmware or bootloader prompt: likely Secure Boot enforcement or revoked boot component.
• Machine boots but disk doesn’t unlock automatically / prompts for recovery key: likely TPM unseal failure due to PCR drift or TPM state change.
• Machine boots and disk unlocks, but attestation says “untrusted”: likely measured boot mismatch, event log parsing, or baseline drift.

Second: check the three “truth sources”

1. Firmware settings: Secure Boot enabled? CSM/legacy disabled? TPM enabled/activated? Any recent firmware update?
2. Boot components: what EFI binary was executed (efibootmgr), are signatures valid (sbverify), did dbx change (mokutil –dbx)?
3. Measurements/keys: PCR values (tpm2_pcrread), enrollment policy (systemd-cryptenroll –dump), and logs (journalctl, dmesg).

Third: decide what kind of fix you’re allowed to do

• Emergency restore service: use recovery keys, boot known-good signed media, roll back offending update.
• Correctness fix: update/re-sign bootloader/kernel, adjust PCR policy with a controlled reseal procedure, deploy db/dbx changes in the right order.
• Long-term fix: standardize firmware versions, key management, and update cadence; implement attestation gating for sensitive workloads.

The bottleneck is usually not “TPM is broken.” It’s “we changed something we didn’t measure and now our policy is doing exactly what we asked.”

Common mistakes: symptoms → root cause → fix

1) Symptom: After a kernel update, servers boot but LUKS auto-unlock fails

Root cause: TPM-sealed key was bound to PCRs affected by the update (or to Secure Boot state that changed due to db/dbx updates).

Fix: Use recovery path to boot, then reseal/enroll the TPM token against the new measured state. Consider binding to PCRs that match your update strategy, and test updates in a canary ring.

2) Symptom: “SecureBoot enabled” but unsigned kernel modules still load

Root cause: Module signature enforcement not enabled (or modules are signed by a key the kernel trusts via MOK/embedded cert).

Fix: Enable module signature enforcement where required; audit trusted keys; implement a module signing pipeline. Don’t rely on Secure Boot alone for module integrity.

3) Symptom: Suddenly can’t boot older rescue media

Root cause: dbx update revoked the old bootloader/shim used on that media.

Fix: Maintain updated rescue media signed with currently trusted keys; test boot media after dbx updates; keep a documented break-glass path that doesn’t depend on revoked components.

4) Symptom: Attestation fails on a subset of identical model servers

Root cause: Firmware versions differ, or BIOS settings differ (CSM, Secure Boot mode, boot order), causing PCR drift.

Fix: Standardize firmware, enforce configuration baselines, and collect PCR baselines per model/firmware. Fleet “identical” is usually aspirational, not factual.

5) Symptom: TPM tools error with “No TPM device found” in a VM

Root cause: vTPM not attached or not exposed; or the guest lacks drivers.

Fix: Attach a vTPM device in the hypervisor config; verify /dev/tpmrm0 existence; ensure kernel modules are present. If you can’t trust the hypervisor, don’t pretend the vTPM buys you hardware-level assurances.

6) Symptom: Secure Boot enabled, but bootchain tampering still possible via physical access

Root cause: Firmware setup is unprotected (no admin password), attacker can disable Secure Boot or enroll their own keys.

Fix: Lock down firmware setup, restrict physical access, use chassis intrusion detection if available, and inventory/monitor firmware configuration drift.

7) Symptom: You can’t debug production because lockdown blocks access to kernel interfaces

Root cause: Secure Boot triggers kernel lockdown policy that restricts certain debug operations.

Fix: Provide signed debug kernels for controlled environments, or use supported observability tools that don’t require breaking integrity guarantees. If your debugging plan requires disabling controls, it’s not a plan.

Three corporate mini-stories (anonymized, plausible, and painful)

Mini-story 1: The incident caused by a wrong assumption (“Secure Boot means our drivers are safe”)

A mid-size SaaS company rolled out Secure Boot across their Kubernetes worker nodes. It was a compliance push. The security team got their checkbox, the infrastructure team got a bunch of firmware reboots, and everyone declared victory.

Weeks later, a node pool started behaving oddly: intermittent packet drops, CPU spikes in softirq, and then occasional kernel panics. Classic “hardware or driver” vibes. They drained nodes, replaced a couple, and the problem followed the image, not the chassis.

The root cause wasn’t exotic: a third-party kernel module had been installed as part of a “performance pack.” It was signed—because the org had enrolled a broad MOK key to make vendor installs painless. A compromised build artifact slipped into the supply chain, still signed by the key everyone trusted. Secure Boot dutifully enforced the policy: “If it’s signed by this key, run it.”

The fix wasn’t to turn Secure Boot off. The fix was to stop treating MOK enrollment as a convenience feature. They rotated the MOK key, narrowed who could sign modules, and required reproducible build evidence for vendor blobs. They also learned the hard way that trusting a key is the real policy; signatures are just the format.

Mini-story 2: The optimization that backfired (“Let’s bind the disk key to more PCRs for better security”)

A financial services team decided to tighten their disk encryption posture on Linux laptops. They used TPM-based unlock and thought, reasonably, that binding the key to more PCRs would make tampering harder. So they bound it to a broad set: firmware, bootloader, kernel, and some configuration-related measurements.

It looked great in a lab. Then the normal world happened. Firmware updates rolled out in waves, sometimes triggered by OEM tooling, sometimes by IT. A subset of machines got a BIOS update that changed measured components and PCR values. The laptops booted, but the TPM refused to unseal. Users were dumped into recovery flows, and support lines melted.

The security team initially called it “TPM instability.” It wasn’t. It was policy doing its job: those machines were not in the old measured state anymore.

They recovered by leaning on recovery keys and a controlled re-enrollment process after updates. They also learned to bind to PCRs that match their operational cadence and to stage firmware updates with the same discipline as OS updates. More PCRs can be stronger. It can also be a denial-of-service you schedule for yourself.

Mini-story 3: The boring but correct practice that saved the day (“We tested dbx changes like a production deploy”)

A large enterprise ran a mixed Linux fleet: bare metal servers, some laptops, and a batch of appliances that were basically PCs in a box. They had a habit that looked painfully conservative: any firmware update and any Secure Boot db/dbx update went through canary rings, with boot testing that included rescue media.

One quarter, a dbx update rolled out that revoked a vulnerable boot component. This was the right security move. It was also the kind of move that strands machines if you’re still booting old shims or relying on stale recovery images.

Because they had canaries, they caught it early: their legacy rescue ISO wouldn’t boot anymore. The fix was straightforward: refresh rescue media with a current signed shim and update their appliance vendor image before the revocation hit the wider fleet.

No drama. No outage call. No executives learning what “dbx” means. Just a small ticket, closed quietly. This is the kind of unglamorous operational hygiene that keeps you employed.

Checklists / step-by-step plan (what to do in a real organization)

Checklist A: Rolling out Secure Boot without self-inflicted outages

1. Inventory firmware mode: confirm UEFI mode everywhere; eliminate legacy BIOS installs.
2. Decide key strategy: vendor defaults vs custom PK/KEK/db. If you need strong org control, plan custom keys and escrow.
3. Establish signing pipeline: who signs kernels/modules? where is the key stored? what approvals exist? where are audit logs?
4. Plan for dbx changes: track revocations; test that your boot components and rescue media aren’t revoked.
5. Canary everything: firmware, shim, bootloader, kernel, and dbx updates. Boot-testing is not optional.
6. Define break-glass: out-of-band console, recovery media, recovery keys, and the human process to use them.

Checklist B: Using TPM for disk unlock without lying to yourself

1. Define what you’re defending against: stolen laptop, stolen server, or tampering?
2. Pick PCR policy intentionally: PCR 7-only is convenient; broader policies are stronger but brittle. Choose based on update realities.
3. Store recovery keys safely: escrow with access control and audit logs. Test recovery quarterly.
4. Plan for firmware updates: they will change PCRs. Build a re-enrollment workflow.
5. Monitor for drift: collect PCR baselines; alert on unexpected changes for sensitive roles.

Checklist C: Attestation that doesn’t become theatre

1. Decide what you do with attestation results: block workload placement, restrict secrets, or just record evidence.
2. Baseline per platform class: hardware model + firmware version + config profile.
3. Handle updates: treat new baselines like a release; promote through rings.
4. Keep the logs: attestation without retention is a hobby, not a control.

FAQ

1) Does Secure Boot encrypt anything?

No. Secure Boot verifies signatures to decide what can execute. Encryption at rest is a separate control (LUKS, BitLocker, etc.).

2) If Secure Boot is enabled, am I safe from bootkits?

You’re safer from unsigned or untrusted bootkits. If attackers can get a malicious component signed by a trusted key (or compromise your key), Secure Boot will happily boot it.

3) What does the TPM actually store?

It can store keys (or key material), counters, and small blobs. It also stores PCR values (measurements) and can sign attestation statements. It’s not general-purpose storage.

4) What’s the difference between PCR binding and “TPM present” disk unlock?

PCR binding means the TPM releases the key only if measured state matches policy. “TPM present” without meaningful PCR policy is mostly convenience; it may not resist tampering.

5) Why does a firmware update break TPM-based auto-unlock?

Because measured components changed, PCR values changed, and the TPM refuses to unseal a key bound to the old measurements. That’s expected behavior.

6) Can I use a TPM in a VM and still claim hardware trust?

You can use a vTPM and gain features like sealing and attestation within the virtualization trust boundary. But your trust shifts to the hypervisor, its storage of vTPM secrets, and its attestation story.

7) Should I use custom Secure Boot keys (own PK/KEK/db) everywhere?

Only if you’re ready to operate it: key generation, secure storage, rotation, recovery, and lifecycle management. For many orgs, shim + MOK is a pragmatic middle ground. For high assurance, custom keys are worth it.

8) Is Secure Boot the same as kernel lockdown?

No, but they’re connected on many distros. When Secure Boot is enabled, the kernel may enter lockdown mode to prevent certain actions that could bypass integrity guarantees.

9) Can Secure Boot prevent someone from booting from a USB stick?

It can prevent booting unsigned/untrusted USB bootloaders. But if firmware boot options aren’t locked down, an attacker could still change settings. Physical security and firmware access controls matter.

10) What should I log and monitor?

At minimum: Secure Boot state, enrolled keys (MOK/db), dbx changes, firmware versions, TPM availability, and attestation results for machines running sensitive workloads.

Next steps that actually move the needle

If you want Secure Boot + TPM to be more than a compliance sticker, do three things:

1. Write down your threat model in plain language. “Evil maid on laptops” and “bootkit persistence on hypervisors” are different worlds.
2. Operationalize keys and updates: treat signing like production deploys, test dbx changes like you test kernel rollouts, and standardize firmware.
3. Practice recovery: escrow recovery keys, keep updated rescue media, and run a quarterly “can we recover a sealed disk after a firmware update?” drill.

Secure Boot enforces what you trust. The TPM helps you bind secrets and prove what happened. Neither replaces patching, access control, or boring process. And “boring process,” inconveniently, is where most security actually lives.