The Security Header is a field used in LTE's NAS signaling messages to indicate the type of security protection applied to the message. This field is part of the NAS protocol header and plays a critical role in ensuring the confidentiality and integrity of signaling messages exchanged between the UEand the Core Network (MME/AMF).

• Security Header Type
• What are the Roles of the Security Header Type ?
• What does it mean by the value of each security header type ?
• Security Header Type in Action - LTE
• Security Header Dynamics : Blank Start vs Stored Security Context
• Blank Start
• Context Reuse
• Reference :

Security Header Type

The Security Header Type in LTE NAS signaling plays a crucial role in identifying the level and type of security protection applied to a specific NAS message. It is an integral part of the Security Header field and helps both the User Equipment (UE) and the Mobility Management Entity (MME) (or AMF in 5G) understand how to process and validate a NAS message.

The table below follows 24.301 v20.0.0. The non-standard codepoints were wrong in the earlier copy on this page: the SERVICE REQUEST header is 1100 (0xC), not 1000, and the latest version adds 1011 (0xB) for the EMM TRANSPORT message.

< 24.301 -  Table 9.3.1: Security header type : LTE>

< 24.501 -  Table 9.3.1: Security header type : NR>

What are the Roles of the Security Header Type ?

Security Header Type acts as a key indicator of the security state applied to NAS messages, specifying whether they are unprotected, protected with integrity only, or both integrity-protected and encrypted. By doing so, the Security Header Type facilitates secure communication, differentiates between message types, supports smooth transitions between security states, and maintains synchronization of the security context. These functions collectively safeguard sensitive signaling information and ensure seamless network operations.

• Indicating the Security State: The Security Header Type informs whether the message is:
• Unprotected (Plaintext)
• Protected with integrity only
• Protected with integrity and encryption
• Ensuring Secure Communication: By specifying the type of security applied, it ensures that sensitive information is either encrypted, integrity-protected, or both, based on the current security context.
• Message Differentiation: It allows the network and UE to differentiate between messages that need further processing (e.g., decryption or integrity verification) and messages that are sent without security for specific reasons (e.g., initial signaling).
• Support for Transition States: It supports transitions between unprotected and protected states, such as during the establishment of the NAS security context. For example:
• Plain NAS messages are used before the security context is set up.
• Protected NAS messages are used after the security context is established.
• Maintaining Context Synchronization: It ensures that both the UE and the network operate on the same security context by signaling whether the current or a new security context applies.

What does it mean by the value of each security header type ?

The table above gives each value in one line, but not when it appears in a real exchange. Values 0x3 and 0x4 appear once each, in the security mode control procedure, while 0x2 carries almost all NAS signalling after it. Values 0x5 and 0xC belong to single messages with their own format.

Followings are the descriptions of each security header type value.

• 0x0: Plain NAS Message (No Security Applied)
• Purpose:
• Used for NAS messages that are not protected by any security mechanisms (neither integrity-protected nor ciphered).
• Examples:
• Initial NAS messages such as Attach Request or Identity Request.
• Reason:
• At this stage, no security context has been established between the UE and the network, so the message must remain plaintext.
• 0x1: Integrity Protected
• Purpose:
• NAS messages are protected using integrity protection to ensure the authenticity of the message and prevent tampering.
• No encryption is applied; the content of the message remains readable.
• Examples:
• Some messages after security mode is established but do not require confidentiality, such as Identity Response or Detach Request.
• Reason:
• Suitable for messages that are not highly sensitive but require protection against tampering.
• 0x2: Integrity Protected and Ciphered
• Purpose:
• Ensures that NAS messages are both integrity-protected (to verify authenticity) and encrypted (to protect confidentiality).
• Examples:
• Attach Complete, Authentication Response, or Bearer Resource Command.
• Reason:
• Used after a security context is established to protect sensitive signaling information.
• 0x3: Integrity Protected with New EPS Security Context
• Purpose:
• Applies integrity protection, without ciphering, using a newly established EPS (Evolved Packet System) security context.
• Examples:
• Security Mode Command message only (24.301 Table 9.3.1, NOTE 1).
• Reason:
• Indicates that the current message is the first to use the new security context, ensuring a secure transition.
• 0x4: Integrity Protected and Ciphered with New EPS Security Context
• Purpose:
• Specific to the Security Mode Complete message, the first message the UE sends with the new EPS security context.
• Both integrity protection and ciphering are applied.
• Examples:
• Security Mode Complete message only (24.301 Table 9.3.1, NOTE 2).
• Reason:
• Used only during the exchange that establishes a secure context.
• 0x5: Integrity Protected and Partially Ciphered NAS Message
• Purpose:
• Specific to the CONTROL PLANE SERVICE REQUEST message. Only the value part of its ESM message container or NAS message container IE is ciphered (24.301 clause 4.4.5).
• Examples:
• Control Plane Service Request carrying small data with the CIoT EPS optimization.
• Reason:
• The rest of the message stays readable, so the MME can identify the UE and its security context before it deciphers the container.
• 0xC: Security Header for Service Request
• Purpose:
• Indicates the short SERVICE REQUEST message. It is not a plain NAS message, and it carries only a KSI, a short sequence number and a short MAC.
• Examples:
• Service Request message during idle-to-connected state transitions.
• Reason:
• Protects the Service Request message to ensure it is legitimate and tamper-proof.

Security Header Type in Action - LTE

A table of codepoints does not show when each value is used. The initial attach is the clearest example, because the UE starts with no security context and the header type changes three times in one procedure: 0x0 first, then 0x3 and 0x4, then 0x2.

Security Header Types in the context of initial attach process in LTE can be illustrated as follows.

For messages such as the Attach Request and Authentication Request/Response, no security is applied initially, and the security header is set to 0x0 (Plain NAS message). During the Security Mode Command procedure, the NAS message is protected with an outer security header (0x3 or 0x4) indicating integrity and optional ciphering with a new EPS security context, while the inner message remains unprotected (0x0).

Similarly, the Security Mode Complete message follows the same format with integrity protection in the outer layer and plaintext in the inner layer. Once security is fully established, subsequent messages like Attach Accept, Attach Complete, and EMM Information are protected with both integrity and ciphering (0x2). This table highlights how LTE manages security in NAS signaling based on the context and the state of the session.

NOTE : This diagram is based on the assumption that UE does not have any pre-stored security context (e.g, this is what would happened when you power on the UE right after the purchase). This is based on the this log from Amarisoft Callbox and Amarisoft UEsim.

NOTE : If UE has any pre-stored security context, it may try with Security Protected header from the beginning (i.e, Attach Request) as you can see in this log from Amarisoft Callbox and a commercial UE.

NOTE : How to force UE to do 'blank initiation' is up to UE implmentation. I see some UE tries blank start after power-off / power on, but some UE tend to use the stored security context even after the power cycle.

Initial attach without a stored security context. The header type moves from 0x0 to 0x3 for the NAS Security Mode Command, 0x4 for its Complete, and 0x2 from the Attach Accept on.

The flow shown above can be represented as a table as shown in the following example.

This table provides an example of the Security Header Type in LTE NAS signaling and how it is used in various message exchanges between the UE (User Equipment) and the Network (NW) during initial attach procedure in LTE.

NOTE : This is based on the log between Amarisoft Callbox and SamSung Galaxy 24

It outlines the direction, type of NAS message, and the corresponding security header applied to those messages.

NOTE : What do you mean by Outer and Inner ?

The term 'Outer', 'Inner' is indicated in the following example

Capture: decoded Attach accept from a test log. The values are as captured, not specification text.

Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x2 (Integrity protected and ciphered) <== Outer
Auth code = 0x6bb083ed
Sequence number = 0x02
Protocol discriminator = 0x7 (EPS Mobility Management)
Security header = 0x0 (Plain NAS message, not security protected) <== Inner (Always Plain)
Message type = 0x42 (Attach accept)
EPS attach result = 2 (combined EPS/IMSI attach)
T3412 value:
  Value = 30
  Unit = 1 (1 minute)
TAI list:
  Length = 6
  Data = 00 00 f1 10 00 01

NOTE : Message stucture defined by 24.301

The message structure defined by 24.301 - 9.1 is as follows. Outer and Inner marked as below.

1) if the message is a plain NAS message:

a) protocol discriminator;

b) EPS bearer identity or security header type;

c) procedure transaction identity;

d) message type;

e) other information elements, as required.

2) if the message is a security protected NAS message:

a) protocol discriminator;

b) security header type; <== Outer

c) message authentication code;

d) sequence number;

e) plain NAS message, as defined in item 1. <== Inner

< 24.301 - Figure 9.1.1: General message organization example for a plain NAS message >

The picture above shows the 5GS layout of 24.501 Figure 9.1.1, with an extended protocol discriminator and a PDU session identity. In 24.301 Figure 9.1.1, octet 1 holds the EPS bearer identity or security header type and the protocol discriminator.

< 24.301 - Figure 9.1.2: General message organization example for a security protected NAS message >

24.301 Figure 9.1.2. The outer header is octet 1, the MAC octets 2 to 5 and the sequence number octet 6. The plain NAS message from octet 7 is the inner part.

Security Header Dynamics : Blank Start vs Stored Security Context

The differences in the Security Header between the first Attach (e.g., after powering on a device for the first time after purchase) and a subsequent Attach (e.g., after a radio on-off cycle) stem from the security context establishment and reuse.

Main difference between these two states in terms of Security Process are :

• During the first Attach, no prior security context exists, so the UE and network must establish one via the Authentication and Key Agreement (AKA) procedure.
• In subsequent Attaches, an existing security context may be reused if it’s still valid, affecting how security headers are applied.

Blank Start

This refers to the case where UE does not have any valid security context stored in it. This happens when you power on the UE for the first time after the purchase. Or after replacing UEsim.

Context

• The UE has no prior security context with the network because it’s the first time it’s connecting.
• The USIM (Universal Subscriber Identity Module) contains the permanent key (K), but no derived keys (e.g., K_ASME in LTE or K_AMF in 5G) or security context exist yet.

Procedure and Security Header

• Attach Request (UE → Network):
• Security Header Type: 0000 (Plain NAS message).
• Reason: No security context exists yet, so the initial Attach Request is sent unprotected. It includes the IMSI (or GUTI if somehow available) and other parameters.
• Integrity/Ciphering: None applied.
• Authentication (Network ↔ UE):
• After receiving the Attach Request, the network (the MME in LTE, using authentication vectors from the HSS, or the AMF with the AUSF and UDM in 5G) triggers the AKA procedure.
• Authentication vectors are exchanged, and the UE and network derive session keys (e.g., K_ASME or K_AMF).
• Authentication Request and Response are NAS messages, sent without NAS protection until security is established.
• Security Mode Command (Network → UE):
• Security Header Type: 0011 (Integrity-protected with new security context).
• Reason: The network sends this to activate NAS security, specifying the algorithms for integrity (e.g., EIA1) and ciphering (e.g., EEA1). It’s integrity-protected using the newly derived keys but not yet ciphered.
• Integrity: Yes (first use of integrity protection).
• Ciphering: No (not yet activated).
• Security Mode Complete (UE → Network):
• Security Header Type: 0100 (Integrity-protected and ciphered with new EPS security context).
• Reason: The UE confirms security activation, and from this point, both integrity and ciphering are applied using the agreed algorithms.
• Integrity: Yes.
• Ciphering: Yes.
• Attach Accept (Network → UE):
• Security Header Type: 0010 (Integrity-protected and ciphered).
• Reason: With security fully established, the network sends the Attach Accept, which is both integrity-protected and ciphered.
• Integrity: Yes.
• Ciphering: Yes.

Context Reuse

This is the cases where UE has some stored Security context from previous attach. This usually happens when you airplane mode on / off in not too long interval.

Context

• The UE has previously attached to the network and established a security context.
• After a radio off-on cycle (e.g., toggling airplane mode or rebooting), the UE may retain a stored security context (e.g., K_ASME, NAS keys, and GUTI) if it hasn’t expired or been deleted.
• The network (MME/AMF) may also retain this context, depending on its policies and the time elapsed.

Procedure and Security Header

• Attach Request (UE → Network):
• Security Header Type: 0000 (Plain NAS message) or 0001 (Integrity-protected), depending on context reuse.
• Scenario 1: No Context Reuse:
• If the security context is no longer valid (e.g., expired, deleted, or network doesn’t recognize the GUTI), the Attach Request is sent as plain (0000), similar to the first Attach.
• The process then mirrors the first Attach: AKA, Security Mode Command, etc.
• Scenario 2: Context Reuse:
• If the UE and network still share a valid security context (e.g., GUTI and NAS keys are intact), the Attach Request can be sent as 0001 (integrity-protected) using the existing keys. 24.301 clause 4.4.5 requires the UE to send the ATTACH REQUEST always unciphered.
• Integrity: Yes.
• Ciphering: No.
• Reason: The UE uses the stored NAS security context to protect the message, avoiding the need for full re-authentication.
• Authentication (Optional):
• If the network accepts the reused context, authentication may be skipped.
• If the context is invalid or the network requires fresh authentication (e.g., for security policy), AKA is performed, and the Security Mode Command sequence follows (0011, then 0100).
• Attach Accept (Network → UE):
• Security Header Type: 0010 (Integrity-protected and ciphered).
• Reason: Whether reusing an old context or establishing a new one, the Attach Accept is sent with full security once the context is confirmed or re-established.
• Integrity: Yes.
• Ciphering: Yes.

Reference :

• 24.301 - LTE;5G;Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS);
• 24.501-5G;Non-Access-Stratum (NAS) protocol for 5G System (5GS);
• 3GPP TS 24.301 v20.0.0 - clause 4.4.5 and Table 9.3.1, Security header type