"Beyond BIOS: Developing with the Unified Extensible Firmware Interface" https://www.amazon.com/Beyond-BIOS-Implementing-Extensible-Interface/dp/0974364908
reaches its twenty year anniversary
The book came out of a practical need: EFI (then transitioning to UEFI) had a specification, but no single reference that walked a systems programmer from the metal up through protocols, drivers, and the security model. The UEFI spec https://uefi.org/specifications was (and is) comprehensive and precise, but at ~2,000 pages in 2006 it was not a learning document. We wanted something a firmware engineer new to the ecosystem could actually read cover-to-cover.
Looking back at what the ecosystem looked like in 2006 is instructive. The Unified EFI Forum had just been formed (2005). EDK2 as an open-source project didn't exist yet — EDK (the first-generation toolkit) was the state of the art. Secure Boot wasn't in the UEFI spec. IPv6 network boot wasn't in the spec. The notion of UEFI as the firmware substrate for ARM and RISC-V platforms would have sounded speculative. The footprint of the then-current EFI reference implementation was a fraction of today's EDK2's multi-million-line codebase shipping on essentially every server, PC, and an increasing number of embedded and mobile platforms.
The subsequent editions in 2010 and 2017 tracked the evolution: a second edition https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1934053295/ added Secure Boot and more on the PI (Platform Initialization) spec work. After Intel Press shut down in the mid 2010's, DeGruyter https://www.amazon.com/dp/1501514784 picked up the third edition in 2017. DeGruyter is Eur
**What held up**
The architectural framing — protocols as the unit of interface abstraction, the PI phases (SEC, PEI, DXE, BDS, RT) as the organizing principle, handles and GUIDs as the extension mechanism — held up remarkably well. UEFI is accused of complexity, sometimes fairly, but the core services and driver model are coherent and the spec has maintained backward compatibility across 20 years in a way that is genuinely difficult to achieve (maybe 25+ years if you consider EFI1.02 and elide things like device i/o protocol).
The security chapters aged less well, which is entirely predictable in retrospect. We knew that SMRAM needed stronger isolation guarantees. We didn't fully anticipate the firmware attack surface becoming a primary target for advanced persistent threat actors. The years between 2006 and the NIST SP 800-147 guidance https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-147.pdf in 2011 represented a period where the attack surface was well ahead of the defensive specification.
It was probably a wise choice not to read in too much on the open source. Although De Gruyter has been around since the mid-1700's, it's beaten by Springer Verlag that has been publishing since the late 15th-century. And APress (a Springer imprint) has been where you see more implementation-focused books https://link.springer.com/search?query=&content-type=Book&dateFrom=&dateTo=&contributor=Vincent+Zimmer&sortBy=newestFirst.
I joke to myself that all of these books are BG, or "Before GPT." Now that we are in the AG or "After GPT" era does anything read these tech books (other than models integrating them in their training data set)? You still need code to realize these solutions, so maybe Rust docs, Git books, and other literate programming approaches where the documentation lives with the code in live repo's is the way to go.
**What's different in 2026**
I have always felt that the specification needed to be more precise than prose allowed. The evolution from "here's what the spec says in English" to "here are the machine-checked invariants the implementation must maintain" is the direction the field needs to move https://beneficial-ai-foundation.github.io/SVIL2026/. And moving from C (where you can drop CBMC and Frama-C) to Rust (where you have Kani, Verus, Aeneas) goes hand-in-hand with that evolution. Or maybe the TCB is too large and more focused art like DRTM will prevail for aspects of the boot chain that need more assurance? Or everyone will build their own bespoke stack and have a variant of a vertically-integrated iBoot-style solution? Twenty years from 2026 will be interesting.
