Device Vulnerability Levels When Stolen 🔒

Comprehensive Analysis with BIOS/GRUB, Encryption, Sleep States, and Authentication

When a computer is stolen, the real loss is not the hardware – it's the data. This article provides an exhaustive, up-to-date risk assessment of common security configurations, integrating the latest attack vectors (Cold Boot, DMA, SED bypasses, Secure Boot flaws, biometric injection) and actionable mitigations validated by 2025-2026 research.

---

📖 Lexicon — Abbreviations used in the matrix

Abbreviation	Full meaning
BIOS Pwd	BIOS Password — Supervisor (protects settings) + Boot (required at every startup)
Boot Ext.	External Boot disabled — USB, DVD, and network boot blocked in BIOS
GRUB	Grand Unified Bootloader — Linux boot manager, password-protected
Soft. Enc.	Software Encryption — BitLocker (Windows) or LUKS (Linux)
TPM PIN	Trusted Platform Module + Startup PIN — prevents automatic disk unlocking
ShutD	Shutdown only — no Sleep, no Hibernate, RAM fully cleared at power-off
SED+PSID	Self-Encrypting Drive + Physical Security ID printed on the drive label
MFA	Multi-Factor Authentication — biometric + strong password combined
TB/PCIe off	Thunderbolt and PCIe ports disabled in BIOS — removes direct DMA attack vector
IOMMU	Input-Output Memory Management Unit — Intel VT-d / AMD-Vi, blocks DMA attacks

---

📌 Legend

Cell values

Symbol	Meaning
✅	Control active / enabled
✅*	Control active — see comment (*) below the table
❌	Control not active / disabled
❌*	Control not active — see comment (*) below the table
∅	Not applicable for this configuration

Risk levels (Risk column)

Symbol	Risk level
🟥	Extreme — no meaningful protection
🟧	High — easily bypassed with basic tools
🟨	Moderate — significant attack vectors remain
🟩 L	Low — good protection for most threats
🟩 VL	Low – Very Low / Very Low — strong configuration
🟩 VL+	Very Low+ — strong configuration with port hardening
🟩 XL	Extremely Low — all controls active and verified

Note column icons

Icon	Meaning
🔑	Password added (BIOS, GRUB, or login)
🚫	External boot disabled (USB / DVD / network)
🔐	Software encryption enabled (BitLocker / LUKS)
📌	TPM Startup PIN added
🌙	Shutdown only — no Sleep, no Hibernate
🚀	Hardware-encrypted SSD (SED) enabled
🆔	PSID — Physical Security ID added to SED
🖐️+🔑	MFA — Biometric + strong password
🖐️	Biometric-only — no password fallback
⚡	Thunderbolt / PCIe ports disabled in BIOS
🛡️	IO/MMU enabled and verified (Intel VT-d / AMD-Vi)
🔒	UEFI + Secure Boot
⚠️	Regression — this configuration raises the risk back up

---

📊 Cumulative Risk Assessment Matrix

We identified 14 vulnerability scenarios, each reflecting a real-world configuration that results primarily from insufficient human security decisions — missing a password here, skipping encryption there, trusting a single factor. Each row adds exactly one security measure compared to the previous. Asterisks (*) refer to the comments below the table.

#	BIOS Pwd	Boot Ext.	GRUB	Soft. Enc.	TPM PIN	ShutD	SED +PSID	MFA	TB/ PCIe off	IO MMU	Risk	Note
1	❌	❌	❌	❌	❌	❌	❌	❌	❌	❌	🟥	—
2	✅*	❌	❌	❌	❌	❌	❌	❌	❌	❌	🟧	🔑
3	✅	✅	❌	❌	❌	❌	❌	❌	❌	❌	🟨	🚫
4	✅	✅	✅	❌	❌	❌	❌	❌	❌	❌	🟨	🔑
5	✅	✅	✅	✅*	❌	❌	❌	❌	❌	❌	🟨	🔐
6	✅	✅	✅	✅	✅*	❌	❌	❌	❌	❌	🟩 L	📌
7	✅	✅	✅	✅	✅	✅*	❌	❌	❌	❌	🟩 VL	🌙
8	✅	✅	✅	❌	∅	✅	✅*	❌	❌	❌	🟨	⚠️ 🚀
9	✅	✅	✅	❌	∅	✅	✅	❌	❌	❌	🟩 L	🆔
10	✅	✅	✅	❌	∅	✅	✅	✅*	❌	❌	🟩 L	🖐️+🔑
11	✅	✅	✅	❌	∅	✅	✅	❌*	❌	❌	🟨	⚠️ 🖐️
12	✅	✅	✅	✅	∅	✅	✅	✅	❌	❌	🟩 VL	🚀 🔐
13	✅	✅	✅	✅	∅	✅	✅	✅	✅*	❌	🟩 VL+	⚡
14	✅	✅	✅	✅	∅	✅	✅	✅	✅	✅*	🟩 XL	🛡️

---

📝 Comments (referenced by *)

• *2 : A single BIOS password blocks 94.2% of boot-time attacks (Dell SecureWorks), but does not prevent physical HDD extraction.
• *5 : Software encryption without a Startup PIN leaves the decryption key in RAM. If the device is in Sleep mode, a Cold Boot or Volt Boot attack can extract it.
• *6 : Adding a TPM Startup PIN prevents automatic disk unlocking, but the key remains in RAM while running — DMA or Cold Boot attacks are still possible if the machine is in Sleep.
• *7 : Switching to Shutdown only (no Sleep, no Hibernate) eliminates RAM persistence. This is the best practice for software encryption.
• *8 : Self-Encrypting Drives (SEDs) resist software attacks, but physical attacks exist (Hot Unplug, Forced Restart, Key Capture). Risk goes back to Moderate — this is a regression.
• *10 : Multi-factor authentication (biometric + strong password) resists spoofing and template injection, provided the backup password is strong and unique.
• *11 : Biometric-only is vulnerable: Faceplant attack (template injection into Windows Hello, Black Hat 2025) and Master Prints (up to 65% of fingerprint readers fooled). Never use without a fallback — this is a regression.
• *13 : Disabling Thunderbolt, ExpressCard, or external PCIe ports removes the most direct DMA attack vector. Do this in BIOS if ports are not needed.
• *14 : IOMMU (Intel VT-d / AMD-Vi) must be enabled and verified (e.g., dmesg | grep -i iommu on Linux). Many motherboards claim it is active when it is not.

---

🔍 Key Scenarios Explained (mapping to the 14 cumulative cases)

1. No protection → 🟥 Extreme (case 1)
2. + BIOS password → 🟧 High (case 2)
3. + External boot disabled → 🟨 Moderate (case 3)
4. + GRUB password → 🟨 Moderate (case 4)
5. + Software encryption (no PIN, sleep on) → 🟨 Moderate (case 5)
6. + TPM Startup PIN → 🟩 Low (case 6)
7. + Shutdown only → 🟩 Low – Very Low (case 7)
8. Switch to Hardware SED (no PSID) → 🟨 Moderate — regression (case 8)
9. + PSID → 🟩 Low (case 9)
10. + MFA (biometric + password) → 🟩 Low (case 10)
11. Switch to Biometric only → 🟨 Moderate — regression (case 11)
12. + Software overlay on SED → 🟩 Very Low (case 12)
13. + Disable Thunderbolt/PCIe → 🟩 Very Low+ (case 13)
14. + IOMMU verified → 🟩 Extremely Low (case 14)

---

🌳 Risk Overview — Diagram 1 of 3 : No Encryption (Cases 1–4)

The root of all configurations. Without any encryption layer, only boot-level controls are available. This branch feeds into the global root shared by all three diagrams.

graph TD
    root[("Security<br>Configurations")]
    root --> branch1["🔓 No encryption<br>(cases 1 to 4)"]
    branch1 --> c1["Case 1: 🟥 Extreme<br>(nothing)"]
    branch1 --> c2["Case 2: 🟧 High<br>(+BIOS)"]
    branch1 --> c3["Case 3: 🟨 Moderate<br>(+Boot Ext.)"]
    branch1 --> c4["Case 4: 🟨 Moderate<br>(+GRUB)"]

    style root fill:#1e293b,stroke:#94a3b8,color:#ffffff
    style branch1 fill:#7f1d1d,stroke:#fca5a5,color:#ffffff
    style c1 fill:#991b1b,stroke:#fca5a5,color:#ffffff
    style c2 fill:#7c2d12,stroke:#fdba74,color:#ffffff
    style c3 fill:#78350f,stroke:#fcd34d,color:#ffffff
    style c4 fill:#78350f,stroke:#fcd34d,color:#ffffff

Loading

---

🌳 Risk Overview — Diagram 2 of 3 : Software Encryption (Cases 5–7)

Same root as Diagram 1. This branch adds a software encryption layer on top of the boot controls. Cases 5 to 7 differ only by whether a TPM PIN and shutdown policy are enforced.

graph TD
    root[("Security<br>Configurations")]
    root --> branch2["🔐 Software encryption<br>(cases 5 to 7)"]
    branch2 --> c5["Case 5: 🟨 Moderate<br>(+Soft.Enc, no PIN)"]
    branch2 --> c6["Case 6: 🟩 Low<br>(+TPM PIN)"]
    branch2 --> c7["Case 7: 🟩 Low–Very Low<br>(+ShutD)"]

    style root fill:#1e293b,stroke:#94a3b8,color:#ffffff
    style branch2 fill:#14532d,stroke:#86efac,color:#ffffff
    style c5 fill:#78350f,stroke:#fcd34d,color:#ffffff
    style c6 fill:#166534,stroke:#86efac,color:#ffffff
    style c7 fill:#14532d,stroke:#6ee7b7,color:#ffffff

Loading

---

🌳 Risk Overview — Diagram 3 of 3 : Hardware SED Encryption (Cases 8–14)

Same root as Diagrams 1 and 2. This branch replaces or overlays software encryption with hardware SED. Two regressions appear (Cases 8 and 11) — adding a control in the wrong way raises the risk back up.

graph TD
    root[("Security<br>Configurations")]
    root --> branch3["💾 Hardware SED encryption<br>(cases 8 to 14)"]

    branch3 --> sub3_1["SED without PSID<br>(case 8)"]
    sub3_1 --> c8["Case 8: 🟨 Moderate<br>(regression — hardware attacks)"]

    branch3 --> sub3_2["SED + PSID<br>(cases 9 to 11)"]
    sub3_2 --> c9["Case 9: 🟩 Low<br>(+PSID)"]
    sub3_2 --> c10["Case 10: 🟩 Low<br>(+MFA)"]
    sub3_2 --> c11["Case 11: 🟨 Moderate<br>(biometric only — regression)"]

    branch3 --> sub3_3["SED + PSID + software overlay<br>(cases 12 to 14)"]
    sub3_3 --> c12["Case 12: 🟩 Very Low<br>(+software overlay)"]
    sub3_3 --> c13["Case 13: 🟩 Very Low+<br>(+TB/PCIe off)"]
    sub3_3 --> c14["Case 14: 🟩 Extremely Low<br>(+IOMMU verified)"]

    style root fill:#1e293b,stroke:#94a3b8,color:#ffffff
    style branch3 fill:#1e3a5f,stroke:#93c5fd,color:#ffffff
    style sub3_1 fill:#1e40af,stroke:#93c5fd,color:#ffffff
    style sub3_2 fill:#1e40af,stroke:#93c5fd,color:#ffffff
    style sub3_3 fill:#1e40af,stroke:#93c5fd,color:#ffffff
    style c8 fill:#78350f,stroke:#fcd34d,color:#ffffff
    style c9 fill:#166534,stroke:#86efac,color:#ffffff
    style c10 fill:#166534,stroke:#86efac,color:#ffffff
    style c11 fill:#78350f,stroke:#fcd34d,color:#ffffff
    style c12 fill:#14532d,stroke:#6ee7b7,color:#ffffff
    style c13 fill:#064e3b,stroke:#6ee7b7,color:#ffffff
    style c14 fill:#022c22,stroke:#34d399,color:#ffffff

Loading

---

🛠️ Detailed Technical Advice

These are specific, actionable measures that complement the matrix.

1. BIOS/UEFI: Two passwords, not one

• Supervisor password – prevents changes to BIOS settings.
• Boot password – required at every startup.
• Always disable external boot (USB, DVD, network) even if you have a password.

2. GRUB hardening (Linux)

Set a GRUB password to prevent editing boot parameters (init=/bin/bash). Secure the config file — only root can read/write:

sudo chmod 600 /boot/grub/grub.cfg

⚠️ Rolling distributions (openSUSE Tumbleweed, Arch): every kernel update regenerates grub.cfg automatically, which overwrites any password set directly in that file. On rolling systems, the GRUB password must be configured via /etc/grub.d/ (e.g., a custom 40_custom script) so it survives regeneration. Failing to do this means the password silently disappears after the next kernel update — a false sense of security. Weigh this maintenance overhead before enabling GRUB passwords on rolling systems.

3. Hibernation is not a silver bullet

The file hiberfil.sys stores RAM contents (including encryption keys) on disk. If an attacker extracts your disk, they can analyse it offline.

Disable hibernation on sensitive devices:

powercfg /h off

4. Software encryption best practices

• BitLocker: Enable TPM + Startup PIN (not just TPM alone).
• Linux LUKS: Bind to TPM using systemd-cryptenroll:

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/sdaX

Encrypt the entire drive — including temp and swap partitions.

5. SED (Self-Encrypting Drives) – know their limits

• PSID is printed on the drive label — an attacker with physical access can read it and perform a cryptographic erase (data loss, not leak).
• Known hardware attacks: Hot Unplug, Forced Restart, Key Capture.
• Recommendation: combine SED with software encryption (BitLocker over SED) for defence-in-depth.

6. DMA protection – verify it actually works

Many motherboards claim DMA protection is enabled but IOMMU is not initialised.

Verify on Linux:

dmesg | grep -i iommu
cat /proc/cmdline | grep iommu

Look for intel_iommu=on or amd_iommu=on.

Verify on Windows:

Get-Service -Name "DmaProtection"

Disable unused Thunderbolt/PCIe ports in BIOS.

7. Biometric authentication – never alone

• Faceplant (Black Hat 2025): A local admin can inject their own biometric template into Windows Hello.
• Master prints can fool up to 65% of fingerprint readers.
• Always pair biometrics with a strong password or PIN.
• Store recovery keys offline (printed, in a safe) — not only in your Microsoft account.

8. Keep firmware updated

Secure Boot has been bypassed multiple times in 2025-2026:

• CVE-2025-4275 ("Hydroph0bia") – Insyde H2O
• CVE-2026-0421 – Lenovo ThinkPad
• CVE-2026-21265 – Expired Microsoft certificates

Enable automatic firmware updates or check your vendor's site monthly.

9. BIOS password effectiveness

"The simple presence of a BIOS password blocks 94.2% of theft attempts based on boot-time attacks." — Dell SecureWorks

---

✅ Prioritised Security Checklist

1. Enable full-disk encryption — BitLocker (TPM + Startup PIN) or LUKS (with TPM).
2. Set both Supervisor and Boot passwords in BIOS/UEFI, and disable external boot.
3. Disable Sleep — use Shutdown or Hibernate only. On high-security devices, disable hibernation as well.
4. Add a GRUB password on Linux, and chmod 600 its config file.
5. Never rely solely on biometrics — always combine with a password.
6. Disable Thunderbolt/PCIe ports if not needed, or enable and verify Kernel DMA Protection.
7. Store BitLocker recovery keys offline — printed, kept in a safe.
8. Keep BIOS/UEFI firmware updated — check monthly.

---

📚 Recent Vulnerabilities (2025–2026)

CVE / Attack	Description	Impact
CVE-2025-4275	Secure Boot bypass — Insyde H2O	Bootkit installation
CVE-2025-48818	BitLocker encryption bypass	Data exposure
CVE-2026-0421	Lenovo ThinkPad — disable Secure Boot silently	Firmware compromise
CVE-2026-21265	Expired Microsoft Secure Boot certificates	Local bypass
Faceplant (2025)	Biometric template injection — Windows Hello	Authentication bypass
Volt Boot (2025)	Extract data from on-chip SRAM via power domains	Key theft
Hot Unplug / Forced Restart	SED hardware bypasses	Data access without password

---

🎯 Conclusion

No single measure makes your data safe when a device is stolen. Layering is the only effective strategy.

• Most users: Software encryption + Startup PIN + shutdown + strong password = 🟩 Low – Very Low risk.
• High-risk environments: SED + PSID + software overlay + MFA + shutdown + disabled Thunderbolt + verified IOMMU = 🟩 Extremely Low risk.

"Security is a journey, not a product." — Keep your firmware updated, re-evaluate yearly, and always assume physical access is game over — but make that game as hard as possible.

---

Security Layers Overview 🔐

Figure 1: Layered security approach (BIOS, Encryption, Authentication)

---

References: Princeton Cold Boot, KPMG SED attacks, CVE databases, Black Hat 2025, ACM 2025, Dell SecureWorks.