RMF Security Controls for Tactical 5G Deployments

Deploying 5G in a tactical environment is not the same as rolling out a commercial wireless network. The architecture is different, the threat surface is different, and the authorization pathway is significantly more complicated. When you introduce a standalone 5G core, disaggregated radio access network components, and potentially satellite or WWAN backhaul into a forward-deployed or expeditionary environment, you are not just adding a communications layer. You are adding a system that touches nearly every control family in the Risk Management Framework.

Most RMF practitioners encounter 5G in one of two ways. Either they inherit a deployment that was stood up operationally before authorization was fully worked through, or they are handed a program requirement with a tight fielding timeline and told to figure out the ATO path. Both situations create pressure. Both situations require understanding which controls are most consequential for tactical 5G specifically, rather than treating it like a conventional wired or Wi-Fi infrastructure assessment.

The challenge with tactical 5G is that the technical boundaries are genuinely unclear until you map them. The 5G core might run on a hardened compute platform. The radio heads might be mounted on vehicles or forward positions. The user plane traffic might traverse multiple enclaves with different classification levels. The management plane might be exposed to the same network as mission systems. Each of these conditions carries specific RMF implications, and the control families that matter most are System and Communications Protection and Access Control.

This article focuses on the RMF control considerations that are unique to deployable 5G environments. It is written for ISSOs, ISSMs, security engineers, and architects who need to understand not just which controls apply, but why they are operationally harder to satisfy in a tactical context than in a fixed facility.

The intent is not to replace a system-specific security plan. The intent is to give practitioners a clear picture of where the hard problems actually live so they can plan authorization efforts accordingly.

---

Why System Boundary Definition Changes Everything in Tactical 5G

The single biggest factor that determines whether a tactical 5G authorization effort succeeds or stalls is how the system boundary gets defined. This sounds like a procedural detail, but in practice it shapes every subsequent decision about control inheritance, control applicability, and assessment scope.

A standalone 5G architecture includes at minimum a radio access network layer, a disaggregated or integrated core network, user equipment, and management interfaces. In a tactical environment, you may also have containerized core functions running on a compute platform that is part of a separate program of record, backhaul provided by a SATCOM terminal that has its own authorization boundary, and user devices that belong to individual service members rather than the program. None of these boundaries are obvious when you receive the initial requirement document.

If the boundary is drawn too narrowly, the authorization will look clean on paper but will not reflect operational reality. The assessor will find undocumented interfaces during the site visit. If the boundary is drawn too broadly, the authorization effort becomes unmanageable because you are now responsible for controls that belong to a different program office and a different ISSO.

The practical approach is to start the boundary definition process from a physical and logical architecture diagram that has been validated by the engineering team, not by the program manager. Walk the interfaces. Every point where a 5G component exchanges data with something outside the core architecture is a potential boundary decision. Document each one explicitly and decide whether it falls inside or outside the authorization boundary before writing a single control implementation detail.

For tactical 5G, the interfaces that create the most boundary complications are typically the O1 and A1 management interfaces in Open RAN architectures, the N6 interface where the user plane exits the core toward mission applications, and the backhaul connection between the distributed unit and the centralized unit when those functions are physically separated across vehicles or sites. Each of these deserves an explicit boundary disposition documented in the SSP before authorization package review begins.

SC Control Family Considerations for 5G Environments

The System and Communications Protection family is where tactical 5G deployments face the most concentrated technical control requirements. The SC family covers encryption, network boundary protection, session authenticity, information in transit, and protection of communication integrity. In a conventional enterprise network, many of these controls are addressed through well-understood mechanisms. In a tactical 5G deployment, the same controls require answers to architecture questions that most programs have not fully worked through at the time they begin authorization.

Encryption Across Disaggregated Interfaces

SC-8 addresses transmission confidentiality and integrity. SC-28 covers protection of information at rest. In a disaggregated 5G core, the user plane function, session management function, access and mobility function, and other core network functions may run on separate compute nodes communicating over service-based interfaces. If those interfaces traverse a shared transport segment, even one that is physically controlled, the encryption implementation needs to be documented and validated at the control level.

The problem is that 5G specifications define encryption requirements at the standard level, but implementation varies by vendor and deployment configuration. A program that inherits SC-8 from an enclave authorization and assumes that inheriting the control means the 5G-specific interfaces are covered is taking on risk it may not have assessed. Assessors looking at SC-8 for a 5G system will want to see evidence that traffic on the N2, N3, N4, and inter-function service-based interfaces is protected at the transport layer, not just that the enclave has a boundary firewall.

Network Segmentation and Boundary Protection

SC-7 is the boundary protection control, and it creates real implementation pressure in tactical 5G for a straightforward reason. The 5G system creates its own internal network segments for signaling, management, and user traffic, and those segments need to be isolated from each other and from mission networks in ways that a single firewall at the enclave perimeter cannot fully address. The N6 interface where user plane traffic exits the 5G core and reaches mission applications is a particularly sensitive point. Traffic classification, inspection, and filtering at that interface need to be addressed explicitly in the SC-7 implementation description.

In a fixed facility, you have the physical infrastructure to implement separate management and data plane networks with hardware controls. In a tactical environment, those same logical separations often run on a common physical infrastructure to reduce weight and power. The implementation statement for SC-7 in that context needs to demonstrate that the logical separation is enforced by configuration and tested, not just described in an architecture diagram.

SC-39, which covers process isolation, also comes into scope for containerized 5G core deployments. If core network functions are running as containers on a shared compute platform, the isolation between containers, and between containers and the host operating system, needs to be documented and substantiated with configuration evidence. This is frequently underdocumented in tactical 5G authorization packages because the engineering team built the containerization for operational reasons without thinking through the RMF implications.

AC Control Family Considerations and Network Slicing Complications

The Access Control family presents a different category of challenge for tactical 5G. The core questions in AC are about who can access what, under what conditions, and with what level of accountability. In a traditional network, those questions map relatively cleanly to user accounts, role-based access, and authentication mechanisms. In a 5G environment, particularly one that uses network slicing, the access control model becomes more complex because the thing being accessed is not just a system but a logical network instance with its own traffic isolation and policy characteristics.

AC-3 covers access enforcement. AC-4 covers information flow enforcement. AC-17 covers remote access. All three require careful implementation consideration in tactical 5G. The access enforcement question for 5G is not just about administrative console access to core network functions. It is also about how user equipment is authenticated and authorized to attach to the network, which slices are accessible to which device classes, and what controls prevent unauthorized devices from attaching and accessing mission traffic.

5G authentication uses the 5G-AKA protocol, which is a significant improvement over previous generations. But the implementation of that authentication mechanism within a specific deployment needs to tie back to identity management infrastructure that is authorized and documented. In a tactical environment, that infrastructure may be disconnected from the garrison identity management system. How the 5G system handles authentication when it cannot reach a central identity provider is a critical question for both AC-2 and AC-17 that many programs have not answered in writing.

Network slicing adds an additional layer to AC-4 information flow enforcement. If different slices are used to carry traffic with different classification or sensitivity levels, the enforcement mechanism that prevents traffic from migrating between slices is a control implementation question, not a design assumption. Assessors examining AC-4 in a sliced 5G environment will want to understand how slice isolation is enforced at the data plane level and what happens when a device that is authorized on one slice attempts to access resources that belong to a different slice.

For joint or coalition environments where partner nation devices or coalition user equipment may attach to shared 5G infrastructure, the AC control family requirements become significantly more complicated. AC-2 account management, AC-6 least privilege, and AC-20 use of external information systems all come into play, and the authorization boundary questions get harder to answer cleanly when the user population is not entirely under the control of the authorizing organization.

The Inherited Control Problem in Tactical Deployments

Control inheritance is a legitimate and necessary mechanism in RMF. It is how organizations avoid re-documenting and re-assessing controls that are already covered by a higher-level authorization, such as a data center enclave or a platform ATO. The problem in tactical 5G is that programs frequently inherit controls that do not actually cover the 5G-specific implementation, and neither the ISSO nor the inheriting program manager realizes the gap until assessment.

Consider how this plays out for SC-8. A tactical 5G system deployed on a vehicle platform might inherit SC-8 from the vehicle platform authorization. The platform authorization covers encryption for data stored on and transmitted by the vehicle’s mission computers. But the 5G core running on a separate compute node on that same platform, communicating with radio heads via fronthaul interfaces, involves communication paths that the platform authorization almost certainly did not contemplate. The inherited control does not cover those paths. An assessor who asks to see the encryption implementation on the 5G-specific interfaces and gets pointed to the platform authorization will note a finding.

The same dynamic applies to access control inheritance. An enclave authorization may provide inherited coverage for AC-2 account management for the enclave’s active directory environment. The 5G core network functions typically have their own administrative interfaces, their own local accounts or API authentication mechanisms, and their own session management behavior. None of that is covered by the enclave’s directory service authorization. If the program has not documented and assessed the 5G-specific administrative access controls as system-specific controls, the inherited control is not providing the coverage the program assumes.

The fix is not to abandon inheritance. The fix is to treat inherited controls as a starting point for analysis rather than a conclusion. For each inherited control in the SC and AC families, the ISSO should ask explicitly: does the providing system’s implementation statement actually cover the interfaces and functions specific to the 5G deployment? If the answer is anything other than a clear yes, the control needs a system-specific implementation statement that addresses the gap.

This is particularly important for programs that sit under a common control provider such as a tactical network enclave or a theater information management system. Those common control authorizations were typically written before tactical 5G was part of the mission architecture. Their control implementations were not designed with 5G-specific interfaces in mind, and the common control provider’s ISSO is not responsible for closing gaps created by a new system that was layered on top of the enclave after the enclave authorization was completed.

Sustainment, Configuration Management, and Field Realities

One of the most honest conversations you can have about tactical 5G RMF is about what happens after the ATO is issued. The authorization represents a point-in-time assessment of the system as configured at that moment. In a tactical environment, that configuration will drift from the authorized baseline faster than in almost any other context. Firmware updates get pushed in the field. Radio parameters get adjusted for spectrum availability in theater. Network slices get added or modified for a specific operation. New user equipment types get attached without going through a formal device approval process.

Configuration management controls, particularly CM-2 through CM-6, are technically straightforward in their requirements. Document the baseline. Control changes. Implement settings based on security configuration guides. Review and update the baseline when changes occur. In a fixed facility with a mature change management process, these controls are achievable. In a forward-deployed tactical environment, the friction is real.

The practical challenge is that the technical staff maintaining the 5G system in the field are often not the same people who built the authorization package. They may not have access to the SSP. They may not know that the specific configuration they are changing was part of the authorized baseline. They are focused on keeping the system operational for the mission, which is the right priority operationally but creates compliance risk if the configuration management process breaks down.

Programs that handle this well establish a small set of configuration parameters that are treated as authorization-affecting and require formal change notification, and distinguish those from routine operational adjustments that fall within the scope of pre-approved configuration ranges. That approach requires defining the pre-approved ranges explicitly in the SSP and the configuration management plan, which most programs do not do at a level of specificity that actually helps the field maintainer understand what requires escalation.

Sustainment planning for tactical 5G also requires thought about software and firmware currency. 5G core software is updated frequently, and vulnerabilities in 5G implementations are actively tracked by adversaries. A program that fields a system with a clean authorization and then runs the same software versions for eighteen months without patching is accumulating risk that the original ATO did not account for. The continuous monitoring strategy needs to address how software updates are evaluated, approved, and applied within the tactical environment, including the case where connectivity to the patch management infrastructure is unavailable.

Common Mistakes in Tactical 5G RMF Efforts

The same patterns appear repeatedly in tactical 5G authorization efforts that run into problems. Recognizing them early in the program saves significant time and reduces the risk of authorization delays that push against operational fielding timelines.

Treating 5G as a network upgrade rather than a new system is the most common framing error. Programs that have managed a tactical wired or Wi-Fi network under an existing authorization sometimes attempt to extend that authorization to cover a 5G deployment by treating the 5G infrastructure as a network component addition rather than a new system requiring its own boundary definition and control assessment. The 5G core introduces new software, new protocols, new management interfaces, and new attack surfaces that the existing authorization did not contemplate. Extending an existing ATO without a formal significant change review is a risk acceptance decision that the authorizing official needs to make explicitly, not a procedural shortcut that the program can take unilaterally.

Starting the SSP from a generic control template rather than the system architecture is another persistent problem. A 5G system has a specific architecture with specific interfaces and specific data flows. Writing control implementation statements from a generic template produces generic answers that an assessor cannot validate against the actual system. Writing implementation statements from the architecture diagram produces specific, testable claims that map directly to the evidence the assessor will collect.

Underestimating the assessment preparation burden is common in programs where the engineering team built a technically sound system but did not document implementation decisions as they made them. By the time authorization prep begins, the engineers who made the configuration decisions may have moved to other programs, and reconstructing the rationale for specific settings from the deployed configuration is time-consuming and often incomplete.

Assuming that 5G’s built-in security features satisfy RMF control requirements without additional documentation is a mistake that comes up frequently in discussions with program teams. 5G as a standard includes significant security improvements over previous generations, including mutual authentication, subscriber identity protection, and enhanced encryption. But RMF does not give credit for standard-defined security features that have not been implemented and documented in the specific deployment. The presence of a capability in the 5G specification does not mean it is enabled and configured correctly in the fielded system.

Failing to address the spectrum management dimension of the authorization is a less obvious but operationally significant gap. Tactical 5G systems operating in specific frequency bands, particularly those that require coordination with military spectrum management authorities, have additional authorization dependencies that can affect deployment timelines independently of the RMF process. Programs that run the RMF effort in parallel with spectrum coordination without accounting for the possibility that spectrum approval may impose technical constraints on the deployed configuration sometimes find that the authorized configuration does not match the operationally approved spectrum usage.

Recommended Federal Approach

Programs that navigate tactical 5G RMF successfully share a few common practices. They are not complicated, but they require discipline and early investment in documentation that most programs are tempted to defer.

Engage the ISSO and security architect at system design, not at fielding. The most effective tactical 5G security documentation starts when the architecture is being drawn, not when the system is already deployed and the authorization package deadline is approaching. ISSOs who are involved in architecture reviews can identify control gaps before they become implementation problems, flag interface documentation requirements, and ensure that configuration decisions are captured in a form that will support assessment. Programs that treat security as a phase that happens after engineering consistently produce authorization packages that require multiple revision cycles.

Build control traceability into the engineering artifacts. Architecture diagrams, interface control documents, and configuration management records should be created with explicit cross-references to the RMF controls they support. When an engineer documents the encryption configuration for the fronthaul interface, that document should note its relevance to SC-8. When a network slice policy is defined, the policy document should reference its relationship to AC-4. This practice takes minimal additional effort during system development and saves substantial time during authorization package assembly.

Define the disconnected operating mode explicitly. Tactical systems are designed to operate without continuous connectivity to garrison infrastructure. The RMF implications of disconnected operation need to be addressed in the SSP rather than left as an unstated assumption. For AC controls specifically, how does the system handle authentication when the identity provider is unreachable? For SC controls, how is key management handled when central key distribution infrastructure is unavailable? These are not hypothetical scenarios in a tactical environment. They are planned operating conditions, and the authorization needs to address them.

Programs working through tactical 5G and WWAN authorization challenges benefit from having security practitioners who understand both the RMF process and the 5G technical architecture, because the control implementation questions are genuinely technical and cannot be answered correctly by someone who only understands one side of that equation.

Plan the continuous monitoring strategy before the ATO is issued. Tactical 5G systems will change after fielding. The continuous monitoring plan needs to account for how configuration changes are tracked in a field environment, how software updates are managed without disrupting operations, how security-relevant events are collected and reviewed from a system that may not have persistent connectivity to a SIEM, and how the program will demonstrate ongoing compliance to the authorizing official between formal reassessment cycles. A continuous monitoring plan that was clearly written for a fixed facility environment will not survive contact with the operational reality of a forward-deployed 5G system.

Finally, invest in training the field sustainment team on the security requirements that apply to their day-to-day work. The ISSO cannot be physically present at every site where a tactical 5G system is deployed. The engineers and technicians who are present need to understand which configuration parameters are authorization-affecting, what the process is for requesting changes, and how to identify and report security anomalies. Programs that brief the field team once during system integration and never revisit security training are accepting continuous monitoring risk that is entirely avoidable.