What Is the SEC Phase?

Explains the UEFI SEC phase, temporary RAM, cache-as-RAM, SEC to PEI handoff, and early firmware debugging points.

October 28, 2025 Updated June 19, 2026 3 min read

The SEC phase is the first PI/UEFI firmware phase after the reset vector. SEC stands for Security, but in practice it is not only about security. Its main job is to create the minimal environment needed to enter PEI.

In short: SEC builds the first execution foundation before DRAM and Boot Services exist.

A simple flow looks like this:

Reset Vector
  -> SEC entry
  -> temporary RAM / CAR
  -> temporary stack
  -> SEC to PEI handoff
  -> PEI Core

SEC runs with very few services

During SEC, the system does not have a full execution environment. DRAM is usually not initialized, normal heap does not exist, the protocol database does not exist, and Boot Services do not exist. SEC code is therefore small, low dependency, and close to hardware.

SEC usually prepares:

minimal CPU state
temporary RAM or cache-as-RAM
temporary stack
first firmware volume information
handoff information for PEI Core
early measurement or verification when the platform requires it

Temporary RAM and cache-as-RAM

Before DRAM is ready, firmware still needs a stack and temporary storage to call functions. Many platforms use cache-as-RAM, meaning CPU cache is used as temporary RAM during the earliest stage.

The important point is that this storage is temporary. Once PEI initializes real DRAM, required data must be migrated or recreated in stable memory. If code keeps a pointer into temporary RAM for too long, the bug may appear in a later phase and become difficult to debug.

SEC to PEI handoff

SEC does not perform the full memory initialization by itself. It prepares enough information to call PEI Core. The handoff usually includes firmware volume information, temporary RAM, stack information, boot mode, or other platform data.

If this handoff is wrong, PEI may not run, or it may run but fail to find required PEIMs.

Common symptoms include:

reset log exists but no PEI Core log
PEI Core runs and asserts very early
firmware volume containing PEIMs is not found
stack corruption in early PEI
boot mode is detected incorrectly

How SEC differs from PEI

SEC builds the minimum execution environment. PEI uses that environment to initialize DRAM, dispatch PEIMs, and create the HOB list for DXE. In other words, SEC is the bridge from raw reset code into the first firmware infrastructure.

SEC: build temporary execution environment
PEI: initialize memory, dispatch PEIMs, create HOBs
DXE: load drivers, publish protocols

Debugging SEC

SEC is hard to debug because logging may not be stable. Do not assume every debug print function is safe. Adding logs too early may change timing or touch resources that are not ready.

Check these points:

Does the reset vector jump into the SEC entry?
Was temporary RAM/CAR set up successfully?
Is the stack pointer inside a valid temporary range?
Is the firmware volume base correct?
Does SEC call the correct PEI Core entry?
Is handoff data using the correct size and alignment?

Source-reading checklist

When reading SEC source, follow this order:

1. Which SEC entry does the reset stub jump to?
2. What kind of temporary memory does SEC use?
3. Where is the stack placed?
4. How is the first firmware volume located?
5. What does SEC pass to PEI Core?
6. Is there verification or measurement before PEI?
7. How is temporary data handled after real DRAM becomes available?
8. Is the first log before or after temporary RAM setup?

Conclusion

The SEC phase is the first foundation of the UEFI firmware flow. If there is no PEI log, a very early reset loop, or memory initialization never starts, check the reset vector, SEC entry, temporary RAM, and SEC to PEI handoff before debugging higher phases.