5G NR - SecurityModeCommand Message Explained

The SecurityModeCommand message is the NR RRC message the gNB uses to activate AS security for the UE in 5G NR. It is sent after the UE has already completed the basic RRC setup path and before the network continues with later protected connected-mode signaling.

In simple terms, this is the moment where the network tells the UE which RRC security algorithms to use. After this step succeeds, later RRC signaling is expected to use the activated protection context.

This page covers the NR RRC SecurityModeCommand from 3GPP TS 38.331. It does not cover the similarly named NAS Security Mode Command from TS 24.501.

Why SecurityModeCommand matters

SecurityModeCommand is the bridge between early connected-mode setup and protected RRC operation.

It matters because it tells you:

  • the network is ready to activate AS security
  • which ciphering and integrity algorithms were selected
  • whether the UE can move into protected RRC signaling
  • whether later failures might actually be rooted in security activation rather than reconfiguration

If this message is missing, malformed, or followed by the wrong UE behavior, later procedures such as RRC Reconfiguration can fail even though the earlier setup path looked healthy.

Where SecurityModeCommand appears in the call flow

A common success path is:

  1. RRC Setup from gNB to UE
  2. RRCSetupComplete from UE to gNB
  3. SecurityModeCommand from gNB to UE
  4. SecurityModeComplete from UE to gNB
  5. RRC Reconfiguration and other later protected RRC signaling

In a broader registration trace, this means SecurityModeCommand usually appears after the UE has already delivered its initial NAS message through RRCSetupComplete and the network is ready to activate radio-side security.

Call flow position

A compact NR signaling view is:

UE                              gNB
|                               |
|----- RRCSetupComplete ------->|
|                               |
|<---- SecurityModeCommand -----|
|                               |
|---- SecurityModeComplete ---->|
|                               |
|<----- RRCReconfiguration -----|
|                               |

This sequence shows the normal success path:

  • RRCSetupComplete finishes the initial connection setup
  • SecurityModeCommand activates AS security
  • SecurityModeComplete confirms that the UE accepted and applied the security configuration
  • RRC Reconfiguration and later connected-mode signaling continue under the activated protection context

For the full procedure walkthrough, see the dedicated call flow page:

Transport characteristics

For trace analysis, the transport profile is:

  • Direction: gNB to UE
  • Bearer: SRB1
  • Logical channel: DL-DCCH
  • RLC mode: AM
  • Protocol layer: NR RRC

This is different from early setup messages on SRB0. By the time SecurityModeCommand appears, the UE is already using the dedicated connected-mode control bearer.

Protection behavior

SecurityModeCommand is special because it is part of security activation itself.

In practice:

  • the message is integrity protected
  • the message is not ciphered
  • the UE verifies the message and then activates the selected AS security context if the procedure succeeds

This is why engineers should not expect the command itself to be encrypted, even though it is directly tied to enabling later protected signaling.

What engineers should inspect first

When SecurityModeCommand appears, inspect in this order:

  1. Did it arrive on SRB1 / DL-DCCH?
  2. What algorithms were selected in securityAlgorithmConfig?
  3. Does the UE respond with SecurityModeComplete or fail silently?
  4. Are later messages protected as expected after this step?
  5. Is there any confusion between RRC SecurityModeCommand and NAS Security Mode Command in the trace?

Practical troubleshooting guidance

This message is best analyzed together with:

If the command is present but the procedure still fails, the main engineering questions are:

  • did the UE verify the message successfully?
  • were the selected algorithms expected for this UE and scenario?
  • did the connection actually transition into protected RRC operation?
  • is the failure in AS security activation or in a later connected-mode procedure?

Summary

SecurityModeCommand is the NR RRC message that activates AS security in the radio connection.

The key engineering points are:

  • it is an RRC message, not the NAS message with a similar name
  • it carries the selected securityConfigSMC
  • it is sent on SRB1 / DL-DCCH
  • it is integrity protected but not ciphered
  • later connected-mode signaling depends on this step succeeding cleanly

FAQ

What does SecurityModeCommand do in 5G NR?

It commands the UE to activate the selected AS security algorithms for NR RRC signaling.

Who sends SecurityModeCommand?

The gNB sends SecurityModeCommand to the UE.

Is SecurityModeCommand an RRC or NAS message?

This page covers the NR RRC SecurityModeCommand defined in TS 38.331, not the NAS Security Mode Command from TS 24.501.

What is the most important IE in SecurityModeCommand?

securityConfigSMC, especially securityAlgorithmConfig, is the most important part because it tells the UE which algorithms to activate.

What comes after SecurityModeCommand?

A successful path leads to SecurityModeComplete, and later protected RRC signaling such as RRCReconfiguration.

Is SecurityModeCommand ciphered?

No. The message is integrity protected but not ciphered.

Why would SecurityModeCommand fail?

Typical reasons include integrity verification failure, unsupported or inconsistent algorithm handling, or broader security activation issues.

Summary

Downlink NR RRC message used by the gNB to activate AS security for the UE in RRC_CONNECTED.