From cc8248129af8b5c452f47704f224034b5b170bf3 Mon Sep 17 00:00:00 2001
From: fria <138676274+friadev@users.noreply.github.com>
Date: Mon, 27 Oct 2025 07:01:16 -0500
Subject: [PATCH] add more secure firmare update key info

---
 blog/posts/secure-boot.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/blog/posts/secure-boot.md b/blog/posts/secure-boot.md
index 27051eb5..f593d7a7 100644
--- a/blog/posts/secure-boot.md
+++ b/blog/posts/secure-boot.md
@@ -75,4 +75,6 @@ graph LR
 
 The PK acts as the root of trust for the KEK which in turn verifies both the signature database and revoked signature database. They're all stored in non-volatile memory (NVRAM) so they can be erased and replaced with different keys if desired.
 
-The secure firmware update key is typically stored in such a way that it's non-writable and protected by hardware, that way in order to flash new firmware, you always need to verify that the firmware is signed by the OEM. This process is separate from Secure Boot.
\ No newline at end of file
+The secure firmware update key is typically stored in such a way that it's non-writable and protected by hardware, that way in order to flash new firmware, you always need to verify that the firmware is signed by the OEM. This process is separate from Secure Boot.
+
+The design of UEFI Secure Boot allows for users to delete the keys all the way up to the PK and use their own keys if they want, so that's another reason the secure fimware update key is typically different than the PK.
\ No newline at end of file