False 5G base stations: when network infrastructure becomes a trust boundary

When a corporate smartphone displays “5G”, its user normally assumes it is interacting with legitimate carrier infrastructure.

That trust is almost invisible, yet it sits upstream of the VPN, SaaS application, business API and often enterprise authentication.

On 30 September 2026, NIST released CSWP 36G — False Base Station: Applying 5G Cybersecurity and Privacy Capabilities as an Initial Public Draft.1

The paper evaluates how tested 5G devices respond to six simulated false-base-station scenarios on the NCCoE 5G security testbed.1

It is not a report about a live attack campaign. It is a laboratory study of a specific trust boundary: can a device safely interact with the radio infrastructure presenting itself as the network?

A false base station imitates legitimate infrastructure

A false, rogue or fake base station mimics a carrier radio access network and attempts to make user equipment interact with it.

NIST examines risks including service degradation, privacy effects, location tracking and denial of service. It also notes that successive mobile generations have improved protections against several older techniques.1

“More secure”, however, does not mean “no trust boundary”.

Enterprise maps usually start too late

A common enterprise view begins with:

smartphone → VPN → application → API → data

The actual dependency begins earlier:

smartphone → radio access → carrier network → Internet/private network → VPN → application → data

The organisation controls the smartphone and probably the VPN. It may control the application or its SaaS contract.

It generally does not own the base station or carrier network.

The dependency remains real.

External infrastructure can be critical without being under IT control

This illustrates a broader architecture rule: mapping only what the organisation administers removes many modern dependencies.

Public DNS, telecom operators, identity providers, CDNs, certificate authorities and cloud services can all be essential without belonging to the enterprise.

A risk model can therefore distinguish:

controlled component

contracted service

trusted external infrastructure

uncontrolled dependency

The purpose is not to label external infrastructure as unsafe. It is to show where responsibility changes.

Security begins before enterprise authentication

Strong passwords, MFA, managed devices, TLS and VPNs remain essential controls.

But some interactions with mobile infrastructure occur before enterprise application controls apply.

NIST’s work is valuable precisely because it studies security and privacy capabilities at the 5G layer itself.1

Think of the chain as nested trust layers:

radio → carrier → transport → VPN → identity → application

Each layer addresses different threats. None should be assumed to replace every other layer.

What NIST actually tested

CSWP 36G is an Initial Public Draft published on 30 September and open for comments until 30 October 2026.1

The authors used the NCCoE operational 5G testbed to evaluate six false-base-station scenarios, observe tested-device behaviour and identify protections and areas for improvement.

These results do not establish that every 5G smartphone behaves identically, nor that a false base station automatically exposes the contents of a properly encrypted application.

The architectural conclusion is narrower and more useful: the access layer has its own threats and controls.

Availability matters too

NIST notes that 5G improves protections against several privacy and tracking risks while denial-of-service scenarios remain relevant.1

For enterprises, the question is therefore not only “can someone read our data?” but also “what happens if mobile access stops working correctly?”

The impact may be minor for an ordinary office user and much larger for field response, isolated sites, telemetry or systems that use 5G as a resilience link.

Constructed case: an executive smartphone

Consider a managed smartphone running a business application protected by MFA and TLS.

Its path is:

smartphone → base station → carrier → Internet → identity service → SaaS application

With a corporate VPN:

smartphone → 5G access → VPN → enterprise network → application

Useful questions follow: is application content encrypted end to end? Is VPN use mandatory? What happens when radio access is unavailable? Is an alternate path available for critical functions? Which controls remain under enterprise responsibility?

The goal is not to turn the IT department into a telecom operator.

It is to document the assumptions on which service continuity depends.

Three mapping levels are often enough

Enterprises do not need to reproduce a carrier’s complete 5G architecture.

Usage: which business services depend on mobile connectivity?

Access: which devices, SIM/eSIM profiles, operators and fallback modes are used?

Control: which protections remain enterprise-controlled — MDM, VPN, encryption, identity, filtering and monitoring?

This separates carrier responsibility from enterprise responsibility.

The system boundary is not the ownership boundary

NIST’s false-base-station draft illustrates a general architecture principle.

Organisations depend every day on infrastructure they do not own.

Excluding it from architecture views because it is external hides part of the risk. Representing it does not mean pretending to control it.

The useful relationship is:

business service → endpoint → external connectivity → enterprise controls → application

The important question is not “does this antenna belong to our information system?”

It is “which part of our activity assumes that this infrastructure is available and trustworthy?”