5G NAS Authentication, Security Mode, and Initial NAS Protection
Authentication, Security Mode Command, and early protected NAS signaling should be read as one connected security progression. This is the part of NAS Mobility Management that establishes trust, confirms the security algorithms and protection state, and determines when later NAS messages should begin to appear in protected form.
A common practical question is: how should authentication and initial NAS protection be read correctly in a 5G trace? This page answers that by tying together primary authentication, Security Mode Command, the first protected NAS messages, and the failure patterns that appear when this chain breaks.
Quick facts
| Technology | 5G |
|---|---|
| Area / Protocol | NAS Mobility Management security progression |
| Main scope | Primary authentication, Security Mode Command, and early protected NAS messages |
| Main objective | Establish trust, activate NAS security, and confirm when later NAS signaling should be protected |
| Key messages | Authentication Request, Authentication Response, Security Mode Command, Security Mode Complete, Security Mode Reject |
| Related topics | N1, AMF, AUSF, UDM, registration, NAS security header, protected NAS, initial registration |
Contents
Overview
This part of NAS answers three questions in sequence. First, can the UE and core complete the primary authentication branch? Second, can the network and UE establish the NAS protection state through Security Mode Command? Third, do later NAS messages appear in the expected protected form once that security state should be active?
Those questions belong together because many later NAS problems are actually security-progression problems in disguise. A registration issue, service issue, or later NAS decode problem often begins here.
Why these belong together
Primary authentication, Security Mode Command, and initial NAS protection are not three unrelated topics. They form one chain in which each stage defines what the next stage is allowed to do and how later NAS messages should look in traces.
| Stage | Main role | Why it affects later reading |
|---|---|---|
| Primary authentication | Establishes trust between UE and core. | If this branch fails, Security Mode Command and later protected NAS should not be assumed to be healthy. |
| Security Mode Command | Activates the NAS protection state and confirms later security behavior. | This is the key transition point between early NAS progression and later protected NAS reading. |
| Initial protected NAS | Shows whether later NAS messages match the expected security state. | Helps confirm that the security branch did not only start, but actually carried into later NAS continuity. |
Primary authentication
Primary authentication is the stage where the UE and the network establish the initial trust branch for later NAS security. In practical trace reading, this stage answers whether the security chain even has the right to continue on N1.
A clean authentication result should be followed by the expected NAS security progression. If authentication fails, later Security Mode or protected NAS interpretation is usually secondary to the earlier break between the UE, AMF, and supporting authentication functions such as AUSF and UDM.
| Question | What to inspect | Why it matters |
|---|---|---|
| Did the challenge branch complete? | Authentication Request, Authentication Response, Authentication Failure, or Authentication Reject. | Determines whether the NAS security chain should continue. |
| Did the result make sense? | Whether the branch ended positively or moved into failure handling. | Prevents readers from blaming later messages for a break that began in authentication. |
Security mode control
Security Mode Command is the point where the NAS protection state becomes operationally important. It confirms how later NAS signaling should be protected and therefore changes how the next messages in the trace should be interpreted. For sequence context, read it together with the Security Mode Command call flow.
| Stage question | Expected message view | Reading implication |
|---|---|---|
| Did the network request the NAS security transition? | Security Mode Command | Shows that the security branch moved from trust establishment into protection activation. |
| Did the UE complete the transition? | Security Mode Complete or Security Mode Reject | Determines whether later protected NAS should be expected or whether the branch already failed here. |
If Security Mode Command appears but later NAS does not look consistent with the expected protected form, the real break may be between protection activation and later NAS continuity, not in the later message itself. Re-check the later framing with NAS message structure and security header before assuming the later decode is correct.
Initial NAS protection
Initial NAS protection is the early stage at which later NAS signaling should begin to reflect the new protection state established by the security branch. This does not only mean that security was configured; it means later NAS must now be read through that security context.
The key reader question here is simple: after the security procedure completes, do later NAS messages appear in the expected protected form, or does the trace still look like earlier unprotected progression through initial registration?
| Reading point | What should be true | Why it matters |
|---|---|---|
| Post-security continuity | Later NAS should align with the protection state now expected in the trace. | Confirms that Security Mode was not only signaled, but also carried into later NAS behavior. |
| Security header reading | The outer NAS form should match the later protected-message expectation. | Helps separate decode issues from real security-continuity issues. |
Procedure sequence
A practical read order for this branch is to treat it as a short security chain rather than as isolated messages.
1. Primary authentication starts
2. Authentication result confirms whether the branch may continue
3. Security Mode Command activates the NAS protection state
4. Security Mode Complete confirms the transition
5. Later NAS should now be read in the expected protected context
Message view
The following NAS messages are the main practical anchors for this branch. If you need message-level field detail after this overview, continue into the 5G NAS message library.
| Message | Main role | Why it matters |
|---|---|---|
| Authentication Request | Starts the main authentication branch. | Shows that the trust-establishment phase is underway. |
| Authentication Response / Failure / Reject | Closes or redirects the authentication branch. | Determines whether Security Mode should be expected next. |
| Security Mode Command | Requests the transition into protected NAS behavior. | Defines the turning point for later protected NAS interpretation. |
| Security Mode Complete / Reject | Confirms or denies that the protection transition completed cleanly. | Determines whether later NAS continuity should be treated as protected and healthy. |
5GMM message
Message type: Authentication Request
...
5GMM message
Message type: Authentication Response
...
5GMM message
Message type: Security Mode Command
...
5GMM message
Message type: Security Mode CompleteDecode and trace reading
A practical decode method for this branch is to ask three questions in order: did authentication complete, did Security Mode complete, and do later NAS messages now match the expected protected context? This read method is especially useful inside initial registration and later Security Mode Command call-flow views.
| Step | Question | Expected outcome |
|---|---|---|
| 1 | Did authentication succeed? | The trace should move toward Security Mode rather than stay in failure handling. |
| 2 | Did Security Mode complete? | The transition into later protected NAS behavior should be visible. |
| 3 | Do later NAS messages match the expected security state? | The security header and later continuity should align with the completed security branch. |
Common failure patterns
Many traces make later NAS look broken when the real problem is earlier in the security chain.
| Symptom | Likely break point | What to verify |
|---|---|---|
| Security Mode never appears | Authentication branch did not really complete. | Check the authentication outcome before blaming later NAS. |
| Security Mode appears but later NAS still looks wrong | Protection continuity did not carry into later NAS as expected. | Check the Security Mode result and later security-header interpretation. |
| Later NAS decode looks inconsistent | The reader is interpreting later messages without the correct protection context. | Re-check whether the later NAS should already be read as protected. |
NAS Message Structure and Security Header
Use this next when the failure symptom looks like a framing or protected-versus-plain NAS reading problem.
Registration Procedure
Open this when the security issue needs to be placed back into the wider registration sequence.
Security Mode Command Call Flow
Use the call flow when the question is exactly where the security branch stopped or changed direction.
Registration Failure Troubleshooting
Move here when the visible problem is a failed registration outcome and you need symptom-led checks.
References
- 3GPP TS 24.501, Non-Access-Stratum (NAS) protocol for the 5G System
- 3GPP TS 23.501, System architecture for the 5G System
- 3GPP TS 23.502, Procedures for the 5G System
FAQ
Why should authentication, Security Mode Command, and initial NAS protection be read together?
Because they form one practical security progression in which each stage defines what later NAS should look like in the trace.
What usually follows successful authentication in this branch?
Security Mode Command usually follows as the next major stage in the NAS security progression.
What should I check first if later protected NAS looks wrong?
First confirm that authentication and Security Mode both completed cleanly before assuming the later message is itself the root problem.
Why is the security header important after Security Mode Command?
Because later NAS should be interpreted through the security context established by the protection branch, and the header is the visible clue for that in decoding.