NIST’s 5G False Base Station Tests: What Defenders Should Do

A false base station does not need to break 5G encryption to cause trouble. By impersonating radio access network infrastructure before a secure connection is established, a rogue cell can interfere with registration, degrade service, and in some configurations expose privacy-sensitive behavior. A new initial public draft from the US National Institute of Standards and Technology (NIST) shows where 5G defenses hold and where denial of service remains possible.

NIST published False Base Station: Applying 5G Cybersecurity and Privacy Capabilities (NIST CSWP 36G, initial public draft) on September 30, 2026. The NCCoE team exercised six simulated false-base-station scenarios against a laboratory 5G standalone network. In every scenario, the test device lost service, even when 5G security controls stopped the attempted manipulation from succeeding as intended.

What is a 5G false base station?

A false base station (FBS), sometimes called a rogue cell, imitates legitimate radio access network equipment. A nearby phone may select it because the signal appears attractive or because the rogue station claims suitable network parameters. The critical opportunity occurs during the pre-authentication phase: some radio resource control and non-access stratum messages must be exchanged before the network and device have established a protected security context.

NIST’s draft explains that inexpensive commercial hardware and open-source software have lowered the barrier to building realistic test systems. That does not mean every anomaly is malicious. Coverage gaps, configuration errors, roaming problems, overloaded cells, and handset defects can create similar symptoms. Defenders therefore need corroborating evidence rather than treating a strong signal or failed registration as proof of attack.

What NIST tested

The NCCoE testbed used a software-defined radio, srsRAN, Open5GS, an Ubuntu host, and two Samsung handsets. The laboratory represented a controlled standalone 5G environment; it was not a claim about every carrier, device, modem, or deployment. The six scenarios focused on messages that can influence registration before authentication completes.

The most important result is nuanced: the test devices did not simply trust every malicious response. In the fake-registration-accept scenario, 5G mutual authentication prevented the device from accepting an unauthenticated network message. In the capability-manipulation scenario, the device rejected the tampered message because 5G does not permit null integrity protection for that exchange. Yet all six cases still produced denial of service.

5G privacy protections that still matter

It would be wrong to read the results as “5G security failed.” The draft highlights several controls that make fifth-generation networks more resistant to identity collection and tracking than older mobile generations:

• Subscription Concealed Identifier (SUCI): a non-null concealment scheme prevents the permanent subscriber identifier from being sent openly over the radio interface.
• Temporary identity reallocation: changing temporary identifiers reduces the usefulness of long-term passive tracking.
• No SUPI-based paging: the permanent identifier should not be exposed in paging messages.
• Protected initial NAS messaging: a secure container can protect early signaling content when a suitable security context already exists.

Legacy fallback remains a material concern. If a device can be pushed toward 2G or 3G, it may lose protections that are available in 5G. Enterprises managing their own devices should disable obsolete radio modes where coverage and business requirements allow it, then document any exceptions.

What security teams should do now

1. Correlate radio, core, and endpoint evidence

A single indicator is weak evidence. Combine repeated RRC or NAS rejects, registration loops, abnormal backoff timers, unexpected cell identifiers, sudden signal changes, mobility patterns, and user reports. For private 5G, send relevant RAN and core events to the same analytics pipeline used by the SOC. Teams building this pipeline may also find our guides to network monitoring with Zabbix, Grafana, and Nagios and network routing security useful for the broader monitoring architecture.

2. Establish normal registration behavior

Measure registration attempts, reject causes, retry frequency, paging failures, and mobility events by device class and location. NIST points to the 5G Network Data Analytics Function (NWDAF) as one source of network metrics and notes that machine-learning techniques may help identify anomalous behavior. Whether you use NWDAF, a vendor analytics platform, or a SIEM, the useful outcome is a location-aware baseline, not an unexplainable risk score.

3. Design for degraded connectivity

Critical private-network applications need a failure plan. Consider dual connectivity, an independently managed out-of-band path, local fail-safe behavior, and clear recovery objectives. A second cellular path is not independent if both subscriptions rely on the same radio infrastructure and physical site.

4. Harden the device policy

Use mobile device management or supported handset settings to remove unnecessary 2G and 3G access. Confirm that subscriber-identity concealment is correctly configured, temporary identities are refreshed, and modem and operating-system updates are deployed. These controls reduce exposure, but they should not be described as a complete answer to radio-layer denial of service.

5. Build an FBS response playbook

The playbook should identify who can collect modem diagnostics, who contacts the mobile operator or private-RAN team, how suspected locations are preserved, and when legal or spectrum authorities must be involved. Do not deploy active radio countermeasures: transmitting, jamming, or impersonating cellular infrastructure can be unsafe and unlawful without authorization.

Hands-on lab: detect suspicious registration patterns offline

This defensive lab uses synthetic CSV data and the Python standard library. It does not transmit radio signals, connect to a mobile core, or create a false base station. The thresholds are deliberately simple teaching examples; tune them with your own baseline before using them in production.

Prerequisites and isolated environment

• Python 3.8 or later
• An empty working directory
• No elevated privileges and no network access

mkdir -p fbs-detection-lab
cd fbs-detection-lab
python3 -m venv .venv
. .venv/bin/activate

Create fbs_events.csv:

timestamp,device,cell_id,rrc_rejects,nas_rejects,registration_attempts,backoff_minutes,signal_dbm
2026-10-05T07:00:00Z,ue-014,cell-east-01,0,0,1,0,-83
2026-10-05T07:05:00Z,ue-021,cell-east-01,7,0,14,0,-47
2026-10-05T07:10:00Z,ue-032,cell-west-02,0,2,5,12,-71
2026-10-05T07:15:00Z,ue-045,cell-west-02,1,0,2,0,-79

Create detect_fbs_patterns.py:

#!/usr/bin/env python3
import csv
import sys

required = {
    "timestamp", "device", "cell_id", "rrc_rejects", "nas_rejects",
    "registration_attempts", "backoff_minutes", "signal_dbm"
}

def as_int(row, key):
    try:
        return int(row[key])
    except (KeyError, ValueError) as exc:
        raise ValueError(f"invalid integer in {key}: {row.get(key)!r}") from exc

def main(path):
    alerts = 0
    with open(path, newline="", encoding="utf-8") as handle:
        reader = csv.DictReader(handle)
        missing = required - set(reader.fieldnames or [])
        if missing:
            raise ValueError("missing columns: " + ", ".join(sorted(missing)))

        for row in reader:
            rrc = as_int(row, "rrc_rejects")
            nas = as_int(row, "nas_rejects")
            attempts = as_int(row, "registration_attempts")
            backoff = as_int(row, "backoff_minutes")
            signal = as_int(row, "signal_dbm")
            reasons = []

            if attempts >= 10 and rrc + nas >= 5:
                reasons.append("continuous-registration-loop")
            if attempts >= 5 and backoff >= 10:
                reasons.append("intermittent-retry-with-long-backoff")
            if signal > -55 and rrc + nas >= 3:
                reasons.append("strong-cell-plus-reject-spike")

            if reasons:
                alerts += 1
                print(
                    f"ALERT {row['timestamp']} device={row['device']} "
                    f"cell={row['cell_id']} reasons={','.join(reasons)}"
                )

    print(f"SUMMARY alerts={alerts}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit(f"usage: {sys.argv[0]} EVENTS.csv")
    main(sys.argv[1])

Run the detector:

python3 detect_fbs_patterns.py fbs_events.csv

Expected output:

ALERT 2026-10-05T07:05:00Z device=ue-021 cell=cell-east-01 reasons=continuous-registration-loop,strong-cell-plus-reject-spike
ALERT 2026-10-05T07:10:00Z device=ue-032 cell=cell-west-02 reasons=intermittent-retry-with-long-backoff
SUMMARY alerts=2

Interpretation, troubleshooting, and cleanup

The first alert combines a registration loop, reject spike, and unusually strong signal. The second shows a retry pattern followed by a long backoff. Neither proves an FBS; both justify correlation with location, neighboring cells, maintenance activity, and operator telemetry. If the script reports missing columns, compare the CSV header exactly. If it reports an invalid integer, remove units such as dBm from numeric fields. When finished, leave the virtual environment and remove only the lab directory you created:

deactivate
cd ..
rm -rf fbs-detection-lab

The practical takeaway

NIST’s initial draft confirms a boundary that mobile defenders should plan around: 5G authentication and identity protections can block several forms of trust and privacy abuse, but they cannot guarantee radio availability. The most useful response is layered: disable unnecessary legacy access, keep devices and network components current, correlate registration anomalies across the RAN and core, and design critical services to survive a cellular outage.

Because CSWP 36G is an initial public draft, teams should treat its findings as evidence and engineering guidance rather than a final standard. NIST’s official publication page provides the draft and comment process.

Primary sources

• NIST CSWP 36G publication page
• NIST CSWP 36G initial public draft (PDF)
• NIST announcement: Draft 5G white paper now available
• NCCoE 5G Cybersecurity project