COMMERCIAL SOLUTIONS for CLASSIFIED 

(CSfC) 

Enterprise Gray Implementation Requirements

Annex v1.1.1

Version 1.1.1

23 January 2023
 

i

CHANGE HISTORY

Title Version Date Change Summary

Enterprise Gray 

Implementation 

Requirements 

Annex

0.8 12 July 2018  Initial draft of CSfC Enterprise Gray Implementation 

Requirements Annex. Posted for customer review and 

comments.

Enterprise Gray 

Implementation 

Requirements 

Annex

1.0 2 April 2019  Final approved version.

 Reorganized and added new figures for clarity.

 Added Capability Package (CP) requirements to the 

multiple capability package sections.

 Added sections clearly describing the Gray 

Management and Gray Data Virtual Private Network 

(VPN) tunnels.

 Added sections expanding dynamic routing and Virtual 

Routing and Forwarding (VRF).

 Added a general Enterprise Gray (EG) requirements 

section and re-ordered the EG requirements. 

 Added additional requirements to Centralized 

Management Requirements and Scalability 

Requirements.

Enterprise Gray 

Implementation 

Requirements 

Annex

1.1 19 May 2022  Product Selection Requirements added for the Gray 

Encryption Component and Gray Firewall

 Updated reference from CSfC Key Management 

Requirements Annex to CSfC Symmetric Key 

Management Requirements Annex and CSfC Key 

Management Requirements Annex

 Clarified use of PSKs within dynamic routing

 Updated format
 

ii

Enterprise Gray 

Implementation 

Requirements 

Annex

1.1.1 23 January 

2023

Corrected EG-DR-6 to have the alternative requirement 

of EG-DR-5
 

iii

Table of Contents

1 INTRODUCTION.....................................................................................................................................1

2 MULTIPLE CAPABILITY PACKAGES.........................................................................................................2

2.1 CAPABILITY PACKAGE REQUIREMENTS...................................................................................................2

3 CENTRALIZED MANAGEMENT...............................................................................................................3

3.1 ENTERPRISE GRAY IMPLEMENTATION GUIDE COMPONENTS .....................................................................5

3.1.1 OUTER FIREWALL.......................................................................................................................5

3.1.2 OUTER ENCRYPTION COMPONENT................................................................................................5

3.1.3 GRAY FIREWALL/ENCRYPTION COMPONENT ..................................................................................6

3.1.4 GRAY FIREWALL/ENCRYPTION COMPONENT – GRAY MANAGEMENT VPN..........................................7

3.1.5 GRAY FIREWALL/ENCRYPTION COMPONENT – GRAY DATA VPN.......................................................7

3.1.6 GRAY ADMINISTRATION WORKSTATION ........................................................................................7

3.1.7 GRAY SECURITY INFORMATION AND EVENT MANAGEMENT ..............................................................7

3.1.8 GRAY AUTHENTICATION SERVER ..................................................................................................8

3.1.9 GRAY DOMAIN NAME SYSTEM.....................................................................................................9

3.1.10 GRAY NETWORK TIME PROTOCOL ................................................................................................9

4 SCALABILITY ..........................................................................................................................................9

4.1 DYNAMIC ROUTING ...........................................................................................................................9

4.1.1 DYNAMIC ROUTING PROTOCOL SECURITY....................................................................................10

4.2 VIRTUAL ROUTING AND FORWARDING (VRF).......................................................................................11

4.3 AUTHORIZED PORTS, PROTOCOLS, AND INTERNET PROTOCOL ADDRESSES ................................................12

4.3.1 BLACK NETWORK.....................................................................................................................12

4.3.2 GRAY NETWORK......................................................................................................................13

5 SITE SURVIVABILITY.............................................................................................................................14

6 REQUIREMENTS OVERVIEW................................................................................................................15

6.1 THRESHOLD AND OBJECTIVE REQUIREMENTS .......................................................................................16

6.2 REQUIREMENTS DESIGNATORS...........................................................................................................17

6.3 GRAY FIREWALL/ENCRYPTION COMPONENT AND ADDITIONAL REQUIREMENTS .........................................17

Appendix A. Acronyms ............................................................................................................................27
 

iv

Appendix B. References ..........................................................................................................................29

Table of Figures

Figure 1. Deploying Multiple CPs Using the Same Components ..................................................................3

Figure 2. Two Sites (“A” and “B”) Using Gray Services Hosted at a Main Site..............................................4

Figure 3. Multiple Inner Classification Prohibited Traffic .............................................................................7

Figure 4. Gray Management and Data Services............................................................................................8

Figure 5. Dynamic Routing..........................................................................................................................12

Figure 6. Authorized Protocols on Black Network ......................................................................................13

Figure 7. Authorized Protocols on Gray Network.......................................................................................14

Figure 8. Minimum Services Needed for Site Survivability.........................................................................15

List of Tables

Table 1. Capability Designators...................................................................................................................16

Table 2. Requirements Digraph ..................................................................................................................17

Table 3. Gray Firewall/Encryption Component IPsec Encryption (Approved Algorithms for Classified)....17

Table 4. MACsec Encryption (Approved Algorithms)..................................................................................18

Table 5. General Enterprise Gray Requirements........................................................................................18

Table 6. Multiple CP Requirements ............................................................................................................20

Table 7. Centralized Management Requirements......................................................................................21

Table 8. Scalability Requirements...............................................................................................................23

Table 9. Site Survivability Requirements ....................................................................................................26
 

1

1 INTRODUCTION

Cybersecurity Solutions delivers the Enterprise Gray (EG) Implementation Requirements in this 

document to address increasing demands from customers who desire to implement a Commercial 

Solutions for Classified (CSfC) deployment with one or more of the following characteristics:

 Ability to implement multiple Capability Packages (CPs) simultaneously

 Centralized management

 Enhanced scalability 

 Enhanced site survivability

This EG Implementation Requirements Annex introduces guidance to help CSfC customers sustainably 

expand their networks across large geographic distances by leveraging their existing infrastructure and 

services. This annex references the CSfC Campus Wireless Area Network (WLAN), Mobile Access (MA), 

and Multi-Site Connectivity (MSC) Data-in-Transit CPs using approved cryptographic algorithms and 

National Information Assurance Partnership evaluated components. These algorithms, known as the 

Commercial National Security Algorithm (CNSA) suite, protect classified data using layers of Commercialoff-the-Shelf products. The EG Implementation Requirements Annex, Version 1.1.1, incorporates lessons 

learned from proof-of-concept demonstrations built by the National Security Agency (NSA) Information 

System Security Engineers (ISSEs) in a CSfC network development environment.

This EG Annex, similar to the CSfC CPs, defines areas of a given network solution in terms of Black, Gray, 

and Red Network segments commensurate to the level of protection applied to the data in each 

respective area. Specific guidance for the CPs and these defined areas can be found at: 

https://www.nsa.gov/resources/everyone/csfc/capability-packages/. Customers who want to use this 

documentation to register two or more interconnecting CSfC Solutions must do so with NSA. 

Additional information about the CSfC process is available on the CSfC web page at: 

https://www.nsa.gov/resources/everyone/csfc/. 

Both the Registration Form and Compliance Checklist are available online at: 

https://www.nsa.gov/resources/everyone/csfc/solution-registration.shtml. 

Please provide comments on the usability, applicability, and any shortcomings of this guidance to your 

NSA Client Advocate and the EG Annex maintenance team (via email) at: 

Enterprise_Gray_team@nsa.gov. 

Solutions adhering to this guidance must also comply with the Committee on National Security Systems 

policies and instructions.
 

2

2 MULTIPLE CAPABILITY PACKAGES

The CSfC EG Annex provides cost effective techniques to deploy all three Data-in-Transit CPs at the same 

time by using centralized certificate and Virtual Private Network (VPN) management. Selecting 

equipment with the ability to collapse into components for multi-use allows customers to deploy 

multiple CPs simultaneously. For instance, a customer might use their Outer Encryption Component as 

both the WLAN Access System as described in the Campus WLAN CP and the Outer VPN Gateway as 

allowed by the Mobile Access CP, provided the network device is on the CSfC components list to serve 

both functions. Note that the additional requirement for a multi-use Outer Encryption Component 

within the MA, MSC, and WLAN CPs drastically reduces the number of potential Outer VPN Components 

that can be used and must be considered during design of the system. EG Solution Networks must be 

controlled and managed as classified and all Gray Network Components must be physically protected at 

the same level as the highest classification level of a connected Red Network Enclave. Each of these 

components are described in more detail in Section 3.

2.1 CAPABILITY PACKAGE REQUIREMENTS

The CSfC EG Annex allows for multiple CP instances to coexist on the same equipment. For such 

deployments the highest level of protection must be applied to the Solution Network(s). If a CSfC 

customer plans to combine WLAN and MA Solutions into a single EG Network, then a Black Firewall must 

be used outside of the Outer Encryption Component, as required by the MA CP. Figure 1 shows an 

example of a single EG Solution, designed around the requirements of the MA, MSC, and WLAN CPs, 

using the same equipment to secure two separate sites.

All risks associated with the CPs being integrated together applies to the EG Solution and must be 

considered by the Authorizing Official (AO) for their decision on the acceptable amount of risk. 

Architecture changes may be used to aid in mitigating the risk of integrating CPs together. For example, 

customers may deploy logically separate MA and WLAN instances on the Outer Encryption Component, 

provided they use separate interfaces to connect to the Inner Encryption Component.
 

3

Black Network

AP

WLAN EUD

Outer Tunnel Inner Tunnel

AP AP

AP AP AP

WLAN EUD

Outer Firewall Outer Firewall Outer Encryption Component Gray Firewall Gray Firewall Outer Encryption Component Inner Encryption Component Inner Encryption Component Inner Firewall Inner Firewall

MA

EUD MA

EUD

WLAN EUD: Connects to Government- managed campus-area wireless network MA EUD: Connects to Outer Encryption Device via Public Internet, Government Private Wireless or Retransmission Device Figure 1. Deploying Multiple CPs Using the Same Components

3 CENTRALIZED MANAGEMENT 

The administration of components is key to providing centralized Gray Management Services. Although 

Gray Management Services are composed of several components, those described below have specific 

roles essential to the security of the solution. Each component is accessible only through the Gray 

Firewall/Encryption Component and is physically protected as a classified device. Interconnecting two 

or more solutions using EG, allows flexibility in the placement of some components. EG allows the Gray 

Firewall to also serve as the Gray Encryption Component, and in doing so, extends the Gray 

Management and Gray Data Networks between multiple sites. This configuration allows for remote 

administration of Gray Management Services from a centralized location.
 

4

HUB and Spoke Example

Site A

Gray Services Main Site

Inner Encryption Components Gray Firewall/Encryption Components Outer Encryption Components Outer Firewalls

Management(M) Data(D)

AP

M

M M

M D D

D D

Inner VPN Gray VPN Outer VPN

Site B

Figure 2. Two Sites (“A” and “B”) Using Gray Services Hosted at a Main Site

Generally, the Gray Services area of a CSfC Solution is singly encrypted and under the control of the 

solution owner or a trusted third party; however, when extending Gray Services to another site over an 

untrusted network, two independent layers of encryption must be used to protect both Management 

and Data traffic. The Gray Firewall/Encryption Component at each site provides an inner layer of 

encryption and the Outer Encryption Component provides a second, outer layer of encryption to protect 

traffic between sites. As shown in Figure 2, a hypothetical Main Site’s Gray Firewall/Encryption 

Component can operate four VPN tunnels simultaneously: Management and Data tunnels to Site A, and 

Management and Data tunnels servicing Site B. The Management tunnels create a single Management 

plane for EG. The Data tunnels create a single Data plane for EG. 

Both the Outer Encryption Component and Gray Firewall/Encryption Components must use digital 

certificates issued by the same Outer Certificate Authority (CA) for authentication; however, if the AO 

desires additional security they should create a separate CA or use Pre-Shared Key (PSK) authentication 
 

5

for the Gray Firewall/Encryption Components. For more information on the usage of certificates see 

CSfC Key Management Requirements Annex and for the usage of PSKs see CSfC Symmetric Key 

Management Requirements Annex. The implementing AO may require additional components for 

encryption separate from the Gray Firewall to reduce risk to the Solution Network(s). EG Solutions can 

connect the Gray Management Networks of different sites to each other, allowing for remote 

management, monitoring, and configuration of Gray Management Components. End User Devices 

(EUDs) are prohibited from connecting to the Gray Management Network to service the network as 

administration workstations.

3.1 ENTERPRISE GRAY IMPLEMENTATION GUIDE COMPONENTS

3.1.1 OUTER FIREWALL

An approved Outer Firewall must be incorporated into most CSfC Solutions designed to send 

Management and Data traffic over an untrusted network. For customers deploying only a Campus 

WLAN CP Solution, an Outer Firewall is not required. The Outer Firewall must be located at the edge of 

all CSfC Solution infrastructures implementing the EG guidance. Both the internal and external 

interfaces of the Outer Firewall must only permit Internet Protocol security (IPsec), Internet Key 

Exchange (IKE), Transport Layer Security (TLS), Media Access Control Security (MACsec), and/or 

Encapsulating Security Payload (ESP) traffic, depending on the encryption method of the Outer 

Encryption Component, with a destination address of the Outer Encryption Component. As shown in 

Figure 6, the Outer Firewall and Outer Encryption Component must be physically separate devices.

3.1.2 OUTER ENCRYPTION COMPONENT

The Outer Encryption Component, located between the Outer Firewall and Gray Firewall, is capable of 

establishing encrypted tunnels using IPsec, or MACsec,. When used in an EG Solution, this Component 

serves as a peer gateway to other Outer Encryption Components of CSfC Solutions while also providing 

device authentication, and ensuring the confidentiality and integrity of data transiting untrusted 

networks. If the Outer Encryption Component is used for Campus WLAN, then it is considered part of 

the WLAN Access System, which is composed of Access Point(s) and a WLAN Controller capable of 

initiating and terminating multiple cryptographic tunnels to and from numerous Access Points. For 

Campus WLAN Solutions, it is important to note that depending on the vendor, the Black/Gray boundary 

may either be at the Access Point or the WLAN Controller. The Outer Encryption Component also 

provides the outer layer of encryption protecting Gray and Red Services as they traverse untrusted 

networks. The Outer Encryption Component must not perform dynamic routing. The Outer Encryption 

Component reduces the risk of exposure of information in transit across a Black Network, since the data 

is placed in a secure tunnel that provides an authenticated and encrypted path between two or more 

sites.

If the Outer Encryption Component is considered a shared outer device, it also has the responsibility of 

filtering traffic on its Gray Network interface to prohibit Inner Encryption Components of different levels 

of classification from sending traffic between different levels. 
 

6

3.1.3 GRAY FIREWALL/ENCRYPTION COMPONENT

This annex introduces two new functions to the CSfC Program:

 The use of dynamic routing in a Solution Network (discussed in Section 4)

 A security component serving as a firewall and encryption component simultaneously

The Gray Firewall/Encryption Component is located between the Outer and Inner Encryption 

Components and provides packet filtering for, and access to, Gray Management and Data Services. The 

Gray Firewall/Encryption Component is needed for centralized management when sharing Gray Services 

between sites over an untrusted network. As shown in Figure 3, the Gray Firewall/Encryption 

Component must filter all traffic routed to two or more Inner Encryption Components of different 

classification ensuring that the separate Inner Encryption Component cannot communicate with each 

other. The Gray Firewall/Encryption Component provides the inner layer of encryption for the 

protection of Gray Services as their Management and Data traffic traverses the Black Network. As 

shown in Figure 2, the Gray Management and Data traffic must be encrypted using IPsec, or MACsec 

before being routed through the Outer Encryption Component to another site’s Gray 

Firewall/Encryption Components. When the Gray Firewall is used as the Gray Encryption Component it 

must be chosen from the CSfC Components list for Traffic Filtering Firewalls, and either MACsec Device 

or IPsec VPN Gateway. The Outer Certificate Authority digitally signs the Gray Firewall’s certificate. The 

implementing AO may select an additional component from the CSfC components list to serve as an 

Encryption Component for Gray Management and Data traffic, or use a Type 1 Encryption Device.
 

7

Figure 3. Multiple Inner Classification Prohibited Traffic

3.1.4 GRAY FIREWALL/ENCRYPTION COMPONENT – GRAY MANAGEMENT VPN

The tunnel referred to as the Gray Management VPN connects multiple Gray Management Networks 

together to create the Enterprise Gray Network. This Gray Management VPN is located between two or 

more Gray Firewalls/Encryption Components in either a star or mesh network configuration (see Section 

4). The Gray Management VPN allows for remote management of Gray Management Networks, other 

Gray Components, and resources shared between local and remote Gray Management Networks. The 

Gray Management VPN uses the same CA as the Outer Encryption Component and Gray Management 

Network, but if the AO desires to have more security they can either create a separate CA, or they can 

implement PSK authentication. 

3.1.5 GRAY FIREWALL/ENCRYPTION COMPONENT – GRAY DATA VPN

The tunnel that connects the Gray Data Networks together in order for client devices to connect through 

the Outer Encryption Component to the Inner Encryption Component can connect to another site’s 

Inner Encryption Component. This follows the same requirements as the Gray Management VPN and 

has the same options. It is most useful for a multi-site enterprise with multiple inner enclaves so that all 

such enclaves can be reached from any site in the enterprise. This is an optional capability of Enterprise 

Gray and should only be implemented if needed. The Gray Data VPN uses the same CA as the Outer 

Encryption Component and Gray Management Network, but if the AO desires to have more security 

they can either create a separate CA, or they can implement PSK authentication. 

3.1.6 GRAY ADMINISTRATION WORKSTATION

The Gray Administration workstation maintains, monitors, and controls all security functionality of the 

Gray Network Components across one or more CSfC Solutions. This workstation must only be used for 

logging, configuration, and management of Gray Network Components. The Gray Administration 

workstation must not be used to provision solution components, or as an enrollment or registration 

authority for a CA. The Gray Administration workstation must not be used to administer the Inner VPN 

Gateway or any Red Management Services.

3.1.7 GRAY SECURITY INFORMATION AND EVENT MANAGEMENT

The Gray Security Information and Event Management (SIEM) server collects and analyzes log data from 

all Gray Components. Log data must be encrypted between the originating components and the Gray 

SIEM with Secure Shell version 2 (SSHv2), TLS, or IPsec to maintain confidentiality and integrity of this 

data.

The EG Annex provides guidance to customers deploying multiple CP solutions physically located outside 

of a secure government facility in tactical environments. Given an increase in accessibility, potential 

threats cause a need to continuously monitor network traffic and system log data within the solution 

infrastructure. This monitoring allows customers to detect, react to, and report any attacks against their 

solution in addition to detecting any configuration errors within infrastructure components. At a 
 

8

minimum, this annex requires alerts, events, and system logs to be sent back to a SIEM at a centralized 

operations center to facilitate continuous monitoring of the solution on a daily basis. This minimum 

review period allows customers in tactical environments to implement solutions in situations where it 

may not be feasible to perform real-time local monitoring and analysis. For more information and 

requirements for deploying continuous monitoring into a CSfC solutions see the relevant CP(s) being 

implemented.

3.1.8 GRAY AUTHENTICATION SERVER

Two separate Gray authentication servers are required for Solution Networks. The authentication 

system used to connect EUDs and client devices must use a separate authentication system, different 

from the authentication system used for EG administrator workstation authentication.

The authentication server for the EUDs must perform mutual authentication with EUDs by using the 

Outer Encryption Component as an Extensible Authentication Protocol (EAP) pass-through device. As 

shown in Figure 4, the Gray Management authentication server is also required for the centralized 

management of Gray Services between the Management Site and Remote Sites. 

NTP

Gray Firewall

DNS

Authentication Server SIEM Gray

CA

To Inner Encryption Component

Update Server

Gray Management Services

CDP/OCSP DNS

Gray Data Services

Update Server

Outer Encryption Component Admin Workstation

Figure 4. Gray Management and Data Services
 

9

3.1.9 GRAY DOMAIN NAME SYSTEM

The Gray Domain Name System (DNS) is a control plane service responsible for name resolution to 

Internet Protocol (IP) addresses within the Gray Network for both management and data. The DNS 

servers for the Data and Management Networks must be separate systems. The Gray Management DNS 

servers can be connected to each other in a hierarchical structure with the main site hosting the root 

(authoritative) DNS zone, which updates the other DNS servers throughout the EG Network. The use of 

Domain Name System Security (DNSSEC) is recommended to ensure the integrity of DNS query 

responses.

If static IP addresses are not used to connect to an Inner Encryption Component, the Data DNS is 

required to perform name resolution for both EUDs and site-to-site connection to ensure the correct 

Inner Encryption Component is connected. The Gray Data DNS server should not communicate with any 

other DNS servers and, therefore, must be an authoritative DNS repository.

3.1.10 GRAY NETWORK TIME PROTOCOL

Gray Network Time Protocol (NTP) being deployed within the Gray Management network performs all 

time synchronization, which is important for timestamps used for certificates and event logging within 

the Gray Network. NTP uses a hierarchical ranking of time sources for synchronization called strata. For 

example, stratum zero (0) devices are high-precision time sources such as atomic clocks. Stratum one 

(1) are computers that have been synchronized within microseconds to a directly connected stratum 0 

time source. Stratum two (2) are computers synchronized and directly connected to a stratum 1 time 

source, and so on. NTPv3 is recommended to ensure that the time service of the Enterprise Gray 

network is secure.

4 SCALABILITY

When deploying a CSfC EG Solution, the scaling of the central management and shared data planes for a 

large enterprise requires constant work to maintain and update static routing tables. To mitigate this 

situation, dynamic routing protocols are allowed, but only between the Gray Firewall/Encryption 

Component. Dynamic routing is only allowed on Gray Data VPN interfaces, and Gray Management VPN 

interfaces, to allow the shared data plane and EG Network to expand. To help isolate Gray Management 

VPNs, and Gray Data VPNs, Virtual Routing and Forwarding (VRF) must be used on the Gray Firewall to 

ensure the use of two, logically separate, routing tables along with the firewall filtering. VRFs may also 

be deployed on a Gray Firewall servicing a traditional statically routed network for additional protection 

and security of the Gray Management and Data networks.

4.1 DYNAMIC ROUTING

The ability to scale to multiple centrally managed sites, and use dynamic routing, allows customers more 

flexibility in how they plan for continuity of operations. This annex introduces dynamic routing for the 

first time in a CSfC Solution. If the AO decides to use a separate Gray Encryption Component, then 
 

10

dynamic routing must be implemented on it instead of the Gray Firewall. Dynamic routing must only be 

used on the Gray Firewall/Encryption Component to propagate routing information through the Gray 

Firewall/Encryption Component to share Gray Management and Gray Data services at multiple sites. If 

dynamic routing protocols are used, mutual authentication must occur between a solution network’s 

Gray Firewalls/Encryption Components at all sites, separate from the authentication for the VPN 

tunnels. 

The following dynamic routing protocols may be used by the Gray Firewall/Encryption Component to 

support Enterprise Gray VPNs:

 Border Gateway Protocol (BGP)

 Enhanced Interior Gateway Routing Protocol (EIGRP)

 Intermediate System to Intermediate System (IS-IS)

 Open Shortest Path First (OSPF)

 Routing Information Protocol, version 2 (RIPv2)

4.1.1 DYNAMIC ROUTING PROTOCOL SECURITY

Dynamic routing protocol security is dependent on both the protocol itself, and the different 

implementations by vendors; thus care must be taken when selecting a device to perform dynamic 

routing. Dynamic routing protocols are powerful tools for network administration, and are vulnerable to 

attacks, misconfiguration, and misuse by administrators. Care and consideration must be used when 

implementing dynamic routing into a CSfC Solution. 

Dynamic routing protocols support peer authentication, which allows for all unauthenticated messages 

to be dropped. This ensures all devices performing dynamic routing are mutually authenticated and 

routing updates can be trusted. The dynamic routing protocols authenticate each peer with either a PSK 

that may be specific to each set of network device peers, or across the entire routing domain. Different 

network device vendors support different levels of security within each routing protocol. Network 

devices are required to use the peer message authentication feature within the Enterprise Gray 

Firewall/Encryption Component when performing dynamic routing. Furthermore, the implementation 

of dynamic routing protocols must support peer authentication using at a minimum, a network PSK or 

ideally, a PSK per each device with a key length of at least 256 bits. A hashing based verification must be 

used for this peer authentication and at minimum must support MD5 and should support SHA-256 or 

better.

Dynamic routing protocol implementations also support a form of route filtering which may be used to 

deny a subset of routes from being advertised to other devices on the network and prevent the devices 

from accepting unauthorized routes. Within the CSfC Solution the Gray Firewall/Encryption Component 

must use route filtering to only accept the minimum routes necessary for the Enterprise Gray Network. 
 

11

All other routes must be rejected. The route filtering policies must not use overly large subnets or route 

summarization and should be limited to allowing the smallest subset of networks. In addition, the routes 

being advertised over the Gray Management VPN tunnels must be limited to routes about the local Gray 

Management Network and known remote Gray Management Networks. Also, the same is true for 

advertisements on the Gray Data VPN tunnels with the advertisements only sharing the local Gray Data 

network and other Gray Data Networks. The routes for the Gray Data Networks must not be advertised 

to the Gray Management Networks and Gray Management routes must not be advertised to the Gray 

Data Networks. The devices performing dynamic routing must disable dynamic routing on all other 

interfaces of the router and ensure that routes not part of the Gray Management or Data networks are 

not being advertised. 

4.2 VIRTUAL ROUTING AND FORWARDING (VRF)

When using dynamic routing protocols, data and management traffic must be separated using VRF on 

the Gray Firewall to further enhance the security beyond firewall filtering. VRFs are not required outside 

of dynamic routing but can greatly increase the security posture within traditional static routing 

networks. Each interface will be assigned to a VRF that is specifically allowed to interact with its 

respective network plane (Data Plane or Management Plane). In some cases, the implementer may 

need to import or export routes to establish a VPN tunnel on an interface outside of its respective VRF. 

The primary use case of importing and exporting routes between VRFs is to allow for the importing of 

the routes destined for the Outer Encryption Component. The Data and Management VRF would send 

IPsec or MACsec traffic to the Outer Encryption Component to travel over its encrypted tunnel. Figure 5 

shows how Data and Management VRFs interact with the Outer Encryption Component. A single VRF 

may be used to allow routing between Data lines and Gray Data VPN allowing for routing between the 

sites if the Gray Data VPN is used. A separate VRF should be used for the local Gray Management 

Network allowing for separation and for connecting the Gray Firewall/Encryption Component to the 

local Gray Management Network.
 

12

Figure 5. Dynamic Routing

4.3 AUTHORIZED PORTS, PROTOCOLS, AND INTERNET PROTOCOL ADDRESSES

4.3.1 BLACK NETWORK

As shown in Figure 6, IKE and IPsec are the only protocols authorized for bi-directional traffic flow 

between the Outer Encryption Component and the Outer Firewall. A default route may be used at the 

Outer Firewall and the Outer Encryption Component for egress traffic to the Internet. Hypertext 

Transfer Protocol Secure (HTTPS) is not authorized for profile download on the Black Network.
 

13

Figure 6. Authorized Protocols on Black Network

4.3.2 GRAY NETWORK

Between the Outer Encryption Component and the Gray Firewall/Encryption Component, traffic must be 

separated into Data Line, Gray Data VPN, and Gray Management VPN (see Figure 7). Authorized 

Management traffic includes Hypertext Transfer Protocol (HTTP), HTTPS, DNS, Secure Shell (SSH), and 

authentication, accounting, and update services. Management traffic is designed to control networking 

and server services. Authorized Data traffic includes DNS, IKE, IPsec, TLS, MACsec, and update services. 

The Outer Encryption Component and Gray Firewall/Encryption Component may only receive Data 

traffic for the purpose of domain name resolution and security updates, then traverse to any Inner 

Encryption Component of the same classification level. Authorized VPN traffic is IKE and IPsec and it 

traverses to the Gray Firewall/Encryption Component to provide Gray VPN services and to Inner VPN 

Gateways that support MSC. From the Gray Firewall/Encryption Component to the Inner Encryption 

Component, traffic is separated into Data and VPN (see Figure 7).
 

14

Figure 7. Authorized Protocols on Gray Network

5 SITE SURVIVABILITY

AOs implementing Enterprise Gray Solution guidance may deem site survivability optional for some 

remote sites depending on the mission of the organization. If site survivability is not a requirement and 

there is a loss of connectivity, then the remote site will fail closed. In the event of loss of connectivity, 

Campus WLAN, MA, and MSC solutions will not have access to offsite classified resources.

If the implementing organization requires site survivability, then redundant equipment is required for 

remote sites to maintain connectivity, thereby ensuring access to classified resources. Should a loss of 

connectivity to the centrally managed site occur, then access to resources will be impacted. However, 

to survive such an event, the remote site requires resources to authenticate users, provide name 

resolution, certificate revocation list lookups, time synchronization, and centralized log collection. Site 

survivability only applies to the Gray Management Services, it does not include any Inner Services, or

data. An AO or Security Officer may deem that redundancy is required in the Red Data plane, but such a 

scenario is outside the scope of this annex.
 

15

NTP

Gray Firewall

DNS

Authentication SIEM Server

Gray Management Services

Outer VPN Gateway

DNS

Gray Data Services

Outer Firewall Inner VPN Gateway

CDP/OCSP

Figure 8. Minimum Services Needed for Site Survivability

6 REQUIREMENTS OVERVIEW

Sections 6.1 through 6.3, specify requirements necessary for the implementation of an EG Solution 

compliant with this annex. Interconnecting CSfC Solutions must also follow the requirements of the CPs 

being implemented, (e.g., MA, MSC, and WLAN).

Guidance provided in this annex allows solution owners the flexibility to implement a variety of designs 

for interconnecting two or more CPs that share a common Gray Network. Although most requirements 

apply to all CSfC Solutions, some requirements only apply to implementations whose high-level designs 

incorporate certain features, as noted in Table 1.
 

16

Table 1. Capability Designators

6.1 THRESHOLD AND OBJECTIVE REQUIREMENTS

In some cases, multiple versions of a requirement may exist within this annex. Such alternative versions 

of a requirement are designated as being either a Threshold requirement, or an Objective requirement: 

 A Threshold (T) requirement specifies a feature or function that provides the minimally 

acceptable capability for the security of the solution.

 An Objective (O) requirement specifies a feature or function that provides the preferred 

capability for the security of the solution.

When separate Threshold and Objective versions of a requirement exist, the Objective requirement 

provides more security for the solution than the corresponding Threshold requirement. However, in 

these cases meeting the Objective requirement may not be feasible in some environments or may 

require components to implement features that are not yet widely available. Solution owners are 

encouraged to implement the Objective version of a requirement, but in cases where this is not feasible, 

owners may implement the Threshold version of the requirement instead. These Threshold and 

Objective versions are mapped to each other in the “Alternatives” column. Objective requirements that 

have no related Threshold requirement are marked as “Optional” in the “Alternatives” column.

Capability Package Designator Description

Multiple CPs All Requirements pertinent to all CPs. This CSfC Annex 

comprises all three data-in-transit CPs and describes 

how to protect classified data in transit while 

interconnecting scalable and centrally manageable 

solutions simultaneously across geographically large 

distances by leveraging existing infrastructure and

services.

Mobile Access MA Requirements pertinent to the MA CP only. This CP 

describes how to protect classified data (including voice 

and video traffic) in MA solutions transiting Private 

Cellular Networks and Government Private Wi-Fi 

networks.

Multi-Site Connectivity MSC Requirements pertinent to the MSC CP only. This CP 

describes how to protect classified data in transit across 

an untrusted network using multiple encrypted tunnels 

implemented with IPsec.

Campus WLAN WLAN Requirements pertinent to the Campus WLAN CP only. 

This CP describes how to protect classified data 

(including voice and video traffic) in a WLAN solution 

transiting Government Private Wi-Fi networks.
 

17

In most cases, there is no distinction between the Threshold and Objective versions of a requirement. In 

these cases, the “Threshold/Objective” column indicates that the Threshold equals the Objective (T=O).

Requirements listed as Objective in this annex may become Threshold requirements in future guidance. 

Solution owners are encouraged to implement Objective requirements whenever possible to facilitate 

compliance with future guidance.

6.2 REQUIREMENTS DESIGNATORS

Each requirement in this annex is identified by a label consisting of the prefix “EG”, a two-letter 

category, and a sequence number (e.g., EG-FW-7). The Gray Firewall/Encryption Component and 

General Requirements are listed together in Tables 4 through 8. Each table represents a core capability 

of the Enterprise Gray Implementation Requirements Annex.

Table 2. Requirements Digraph

6.3 GRAY FIREWALL/ENCRYPTION COMPONENT AND ADDITIONAL REQUIREMENTS

Table 3. Gray Firewall/Encryption Component IPsec Encryption (Approved Algorithms 

for Classified)

Security Service Algorithm Suite Specifications

Confidentiality (Encryption) Advanced Encryption Standard 

(AES)-256

FIPS PUB 197

IETF RFC 6379

IETF RFC 6380

Authentication (Digital 

Signature)

RSA 3072

or

ECDSA over the curve P-384 

with SHA-384

FIPS PUB 186-4

IETF RFC 4754

IETF RFC 6380

IETF RFC 7427

Key Exchange/Establishment ECDH over the curve P-384 

Diffie Hellman (DH) Group 20

Or 

DH 3072

NIST SP 800-56A

IETF RFC 3526

IETF RFC 5903

IETF RFC 6379

IETF RFC 6380

IETF RFC 7296

Integrity (Hashing) SHA-384 FIPS PUB 180-4

IETF RFC 6379

IETF RFC 6380

Digraph Description Section Table

FW Gray Firewall/Encryption Components Requirements 6.3 Tables 4-8

DR Dynamic Routing 6.3 Tables 4-8

AR Additional Requirements 6.3 Tables 4-8

PS Product Selection Requirements 6.3 Tables 4-8
 

18

Table 4. MACsec Encryption (Approved Algorithms)

Security Service Algorithm Suite Specifications 

Confidentiality 

(Encryption) 

Galois Counter Mode (GCM)- AES-256 GCM-AESXPN-256FIPS PUB 197 

IEEE 802.1AEbn2018 IEEE 

Key Wrap AES Key Wrap IETF RFC 3394

Table 5. General Enterprise Gray Requirements 

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package 

EG-FW-1 The Gray Firewall must only accept 

management traffic on the physical ports 

connected to the Gray Management 

Network and/or EG Network.

T=O All

EG-FW-2 The Gray Firewall must only permit 

packets whose source and destination IP 

addresses match the external interfaces of 

the Encryption Components supporting 

the Red Network and EG Network of the 

same classification level and internal 

interface of the Encryption Components 

CSfC Solution.

T=O All

EG-FW-3 The Gray Firewall’s outward interface 

must block all packets whose source 

address does not match a list of addresses 

or address ranges known to be reachable 

from the interface on which the packet 

was received.

T=O All

EG-FW-4 The Gray Firewall must deny all traffic on 

the outward interface that is not explicitly 

allowed.

T=O All
 

19

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package 

EG-FW-5 The Gray Firewall must block all traffic 

routed to and between two or more Inner 

VPN Gateways of different classification 

levels.

T=O All

EG-FW-6 Remote administration of the Gray 

Firewall from the Gray Management 

Network and EG Networks is authorized to 

only use SSHv2, IPsec, or TLS.

T=O All

EG-FW-7 The Gray Firewall must permit IKE, IPsec, 

or TLS traffic between EUDs and 

Encryption Components protecting 

networks of the same classification level.

T=O All

EG-FW-8 The Gray Firewall must allow HTTP traffic 

between the Authentication Server and 

the Gray CDP or OCSP Responder.

T EG-FW-9

and

EG-FW-10

All

EG-FW-9 The Gray Firewall/Encryption Component 

must allow HTTP traffic between the 

Authentication Server and the Gray CDP 

or OCSP Responder.

O EG-FW-8 All

EG-FW-10 The Gray Firewall must allow HTTP 

responses from the Gray CDP or OCSP 

Responder to the Authentication Server 

that contains a well-formed CRL per IETF 

RFC 5280 or OCSP Response per RFC 6960 

and block all other HTTP responses.

O EG-FW-8 All

EG-FW-11 The Gray Firewall’s inward interface must 

block all packets whose source address 

does not match a list of addresses or 

address ranges known to be reachable 

from the interface on which the packet 

was received.

T=O All

EG-FW-12 The Gray Firewall’s inward interface must 

deny all traffic that is not explicitly 

allowed.

T=O All

EG-FW-13 The Gray Firewall must allow control 

plane traffic between the Outer 

Encryption Component, Gray Firewall, 

Gray Management Network, and EG 

Network (e.g., NTP, Dynamic Host 

Configuration Protocol, and DNS).

T=O All
 

20

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package 

EG-FW-14 A Gray Firewall, Outer Encryption 

Component, and Gray Encryption 

Component must be administered from a 

workstation designated for managing Gray 

Components which resides on the local 

Gray Management or EG Network. 

T=O All

EG-FW-15 Remote administration of all Gray 

components must be done using SSHv2, 

IPsec, or TLS with the appropriate CNSA 

suite for the highest classification of the 

solution. Encryption provided by the EG 

Network does not fulfill this requirement.

T=O All

EG-AR-1 All Gray Management Services and 

Enterprise Gray Services must go through 

a firewall to access and communicate with 

the Outer Encryption Component, Gray 

Firewall, and Gray Encryption Component.

T=O All

EG-AR-2 The time servers that serve network time 

to Gray Management and Red 

Management must use a secure protocol 

to maintain the authenticity and integrity 

of the network time to clients.

O All

EG-AR-3 The DNS servers used on the Gray Data, 

Gray Management, and Red Management 

Networks must use DNSSEC to secure and 

maintain the authenticity and integrity of 

the domain record to clients.

O All

EG-AR-4 The Outer Encryption Component must be 

configured to not route between the inner 

interfaces if there is more than one.

T=O All

EG-AR-5 The authentication service that 

authenticates EG and/or Gray 

Management administrators must be 

separate from the EUD and Encryption 

Components.

T=O All

EG-PS-1 The Gray Firewall must be chosen from 

the list of Traffic Filtering Firewalls on the 

CSfC Components List. 

T=O 

Table 6. Multiple CP Requirements 
 

21

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

EG-AR-6 Inherit all security requirements of the 

CPs that are being integrated together. 

If the CPs have different requirements 

accept the one with the higher security 

posture.

T=O All

EG-AR-7 An Outer Firewall is required between 

the Outer Encryption Component and 

the Black Network.

T=O MA/MSC 

EG-AR-8 The Outer Firewall must not have a 

physical or logical connection to the Gray 

Management Network or EG 

Management Network.

T=O MA/MSC 

EG-AR-9 EUDs provisioned for an MA solution 

must only be used for an MA solution, 

and not used to access any resources 

other than the Red Network it 

communicates with via two layers of 

encryption.

T=O MA

EG-AR-10 EUDs provisioned for a Campus WLAN 

solution must only be used for a WLAN 

solution and not used to access any 

resources other than the Red Network it 

communicates with via two layers of 

encryption.

T=O WLAN

Table 7. Centralized Management Requirements

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

EG-FW-16 The Gray Firewall must be used as the 

Inner Encryption Component for the EG 

Network.

T EG-FW-17 All

EG-FW-17 If the AO deems it necessary, a separate 

Gray Encryption Component must be used 

to service the EG Network.

O All

EG-FW-18 The Gray Firewall/Encryption Component 

and the Outer Encryption Component 

must use different cryptographic libraries.

T=O All
 

22

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

EG-FW-19 The Gray Firewall/Encryption Component 

at each site provides the inner layer of 

encryption and the Outer Encryption 

Component provides the outer layer of 

encryption to protect Gray Management 

traffic between sites.

T=O All

EG-FW-20 The Gray Firewall/Encryption Component 

must not permit split-tunneling.

T=O All

EG-FW-21 The Gray Firewall/Encryption Component 

must use Tunnel mode IPsec or Transport 

mode IPsec with an associated IP 

tunneling protocol (e.g. Generic Routing 

Encapsulation), authorized TLS 

deployment, or MACsec.

T=O All

EG-FW-22 The Gray Firewall/Encryption Component 

must meet all CSfC requirements for an 

Encryption Component.

T=O All

EG-FW-23 The Gray Firewall/Encryption Component 

must form a Gray Management VPN 

tunnel with other Gray 

Firewall/Encryption Components that 

allows routing between their Gray 

Management Networks forming the EG 

Network.

T=O All

EG-FW-24 If the AO deems necessary, then the Gray 

Firewall/Encryption Component may form 

a Gray Data VPN tunnel between itself 

and other Gray Firewall/Encryption 

Components allowing for routing to 

happen between Gray Data Networks.

Optional All

EG-FW-25 The packet size for packets leaving the 

external interface of the Gray 

Firewall/Encryption Component must be 

configured to keep the packets from 

being fragmented and impacting 

performance. This requires proper 

configuration of the Maximum 

Transmission Unit (MTU) for IPv4 or Path 

MTU (PMTU) for IPv6 and should consider 

the Outer VPN Gateway MTU/PMTU 

values for achievement.

T=O All
 

23

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

EG-AR-11 Two independent layers of CSfC approved 

encryption must be used when extending 

Gray Services to other site(s) over an 

untrusted network.

T=O All

EG-AR-12 Requirement has been relocated to the 

CSfC Key Management Requirements 

Annex.

All

EG-AR-13 Requirement has been relocated to the 

CSfC Key Management Requirements 

Annex.

All

EG-AR-14 Requirement has been relocated to the 

CSfC Symmetric Key Management 

Requirements Annex.

All

EG-AR-15 EUDs provisioned for MA and Campus 

WLAN solutions must not be used to 

connect to the Gray Firewall/Encryption 

Component.

T=O MA, WLAN

EG-PS-2 The Gray Encryption Component must be 

chosen from the list of IPsec VPN 

Gateways on the CSfC Components List. 

T=O EG-PS-3 All

EG-PS-3 The Gray Encryption Component must be 

chosen from the list of MACsec Ethernet 

Encryptions on the CSfC Components List. 

T=O EG-PS-2 All

Table 8. Scalability Requirements

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

EG-DR-1 Dynamic routing is only allowed on the 

Gray Firewall/Encryption Component, no 

other devices on the network can 

perform dynamic routing.

T=O All

EG-DR-2 If dynamic routing protocols are used, 

then dynamic routing peer 

authentication must be performed 

T=O All 
 

24

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

between the Gray Firewalls/Encryption 

Components running dynamic routing.

EG-DR-3 If dynamic routing protocols are used, 

dynamic routing peer authentication 

used by the network devices must use an 

MD5 hashing algorithm.

T EG-DR-4 All

EG-DR-4 If dynamic routing protocols are used, 

dynamic routing peer authentication 

used by the network devices must use a 

SHA-256 hashing algorithm or greater.

O All

EG-DR-5 If dynamic routing protocols are used, all 

network devices participating in dynamic 

routing message authentication must use 

a strong PSK with at least 256-bits of 

entropy for the entire network (Group 

Keys).

T EG-DR-6 All

EG-DR-6 If dynamic routing protocols are used, all 

network devices participating in dynamic 

routing message authentication must use 

a strong PSK with at least 256-bits of 

entropy for every network device (PreShared Keys).

O EG-DR-5 All

EG-DR-7 If dynamic routing protocols are used, all 

network devices participating in dynamic 

routing must only share necessary 

routing information about the local Gray 

Management Network and other Gray 

Management Networks to devices 

servicing the Gray Management VPN 

tunnels. 

T=O All 

EG-DR-8 If dynamic routing protocols are used, all 

network devices participating in dynamic 

routing must only share necessary 

routing information about the local Gray 

Data Network and other Gray Data 

Networks to devices servicing the Gray 

Data VPN tunnels.

T=O All

EG-DR-9 If dynamic routing protocols are used, all 

network devices performing dynamic 

routing must use route filtering on both 

T=O All
 

25

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

inbound and outbound routes stopping 

unauthorized routes from being received 

or shared and by default all routes must 

be blocked.

EG-DR-10 If dynamic routing protocols are used, 

the network devices performing dynamic 

routing must disable dynamic routing on 

all interfaces except the interfaces 

serving the Gray Management VPN 

tunnel and the Gray Data VPN tunnel.

T=O All

EG-DR-11 If dynamic routing protocols are used, 

routes must not be shared between the 

Gray Management and Data Tunnels.

T=O All 

EG-DR-12 If dynamic routing protocols are used, 

routes being shared and filtered must be 

the most specific routes possible.

T=O All

EG-AR-16 If dynamic routing protocols are used, 

then two VRFs must be used to separate 

Data and Management traffic. 

T=O All 

EG-AR-17 Two VRFs must be used to separate Data 

and Management traffic.

O All

EG-AR-18 If VRFs are used, the Management VRFs 

must only contain routing information 

about the local Gray Management 

network and remote Gray Management 

networks.

T=O All

EG-AR-19 If VRFs are used, the Data VRFs must only 

contain routing information about the 

local Gray Data network and remote Gray 

Data networks.

T=O All

EG-AR-20 If VRFs are used, the routes cannot be 

exported or imported between the data 

and management routing instances.

T=O All 

EG-AR-21 If VRFs are used, they are allowed to 

import routes from an outside routing 

instance as long as they do not allow 

sharing of non-authorized routes.

T=O All

EG-AR-22 If dynamic routing protocols are used, 

implementers must use one of the 

T=O All 
 

26

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

following: Routing Information Protocol 

(RIPv2), OSPF, EIGRP, BGP, or IS-IS.

Table 9. Site Survivability Requirements

Req # Requirement Description Threshold/ 

Objective Alternative Capability Package

EG-AR-23 Should a loss of connection occur, a local 

implementer must use an authorized 

authentication service to authenticate 

EUDs and Encryption Components.

T=O All 

EG-AR-24 If the implementing organization requires 

site survivability, implementers must use 

a Gray Data DNS on the remote site(s) 

that mirrors the DNS on the main site. 

This allows for EUDs and site-to-site 

interfaces to connect to the proper Inner 

Encryption Component.

T=O All 
 

27

APPENDIX A. ACRONYMS

Acronym Meaning

AO Authorizing Official

AR Additional Requirements

BGP Border Gateway Protocol

CA Certificate Authority

CDP Certificate Revocation List (CRL) Distribution Point

CNSA Commercial National Security Algorithm

CP Capability Package

CRL Certificate Revocation List

CSfC Commercial Solutions for Classified

DNS Domain Name System

DNSSEC Domain Name System Security

DR Dynamic Routing

EG Enterprise Gray

EIGRP Enhanced Interior Gateway Routing Protocol

FW Firewall

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IKE Internet Key Exchange

IP Internet Protocol

IPsec Internet Protocol Security

IS-IS Intermediate System to Intermediate System

MA Mobile Access

MACsec Media Access Control Security

MSC Multi-Site Connectivity

MTU Maximum Transmission Unit

NSA National Security Agency

NTP Network Time Protocol

OCSP Online Certificate Status Protocol

OSPF Open Shortest Path First

PMTU Path Maximum Transmission Unit

PSK Pre-Shared Key

RIPv2 Routing Information Protocol, version 2

SIEM Security Information and Event Management

SSH Secure Shell

SSHv2 Secure Shell, version 2

TLS Transport Layer Security

VPN Virtual Private Network

VRF Virtual Routing and Forwarding

WLAN Wireless Local Area Network
 

28
 

29

APPENDIX B. REFERENCES

Document Title Date

CNSSP No. 7

CNSS Policy No. 7, Policy on the Use of Commercial 

Solutions to Protect National Security Systems, 

December 9, 2015.

9 December 2015

CNSSP No. 8

CNSS Policy No. 8, Policy Governing the Release and 

Transfer of U.S. Government Cryptologic National Security 

Systems Technical Security Material, Information, and 

Techniques to Foreign Governments and International 

Organizations, August 2012.

August 2012

CNSSD No. 500 CNSS Directive No. 500, Information Assurance (IA) 

Education, Training and Awareness, August 2006.

August 2006

CNSSD No. 502 CNSS Directive No. 502, National Directive on Security of 

National Security Systems, December 16, 2004.

16 December 2004

CNSSD No. 505 CNSS Directive No. 505, Supply Chain Risk Management 

(SCRM), July 26, 2017.

26 July 2017

CNSSI No. 1200

CNSS Instruction No. 1200, National Information Assurance 

Instruction for Space Systems Used to Support National 

Security Missions, May 7, 2014.

7 May 2014

CNSSI No. 1253

CNSS Instruction No. 1253, Security Categorization and 

Control Selection for National Security Systems, 

March 27, 2014.

27 March 2014

CNSSP No. 11

CNSS Policy No. 11, National Policy Governing the 

Acquisition of Information Assurance (IA) and IA-Enabled 

Technology Products, June 10, 2013.

19 July 2021

CNSSP No. 15 CNSS Policy No. 15, Use of Public Standards for Secure 

Information Sharing, October 20, 2016.

20 October 2016

CNSSP No. 22 CNSS Policy No. 22, Policy on Information Assurance Risk 

Management for National Security Systems, August 2016.

August 2016

CNSSP No. 24 CNSS Policy No. 24, Policy on Assured Information Sharing 

(AIS) for National Security Systems (NSS), July 2, 2010.

2 July 2021

CNSSP No. 7

CNSS Policy No. 7, Policy on the Use of Commercial 

Solutions to Protect National Security Systems, 

December 9, 2015.

9 December 2015

CNSSP No. 8

CNSS Policy No. 8, Policy Governing the Release and 

Transfer of U.S. Government Cryptologic National Security 

Systems Technical Security Material, Information, and 

Techniques to Foreign Governments and International 

Organizations, August 1, 2012.

1 August 2012
 

30

Document Title Date

CSfC Campus 

WLAN CP

Commercial Solutions for Classified (CSfC): Campus Wireless 

Local Area Network (WLAN) Capability Package (CP), v3.0, 

December 2021.

December 2021

CSfC Data-AtRest CPCommercial Solutions for Classified (CSfC): Data-at-Rest 

(DAR) Capability Package (CP), v5.0, November 2020.

November 2020

CSfC Key 

Management 

Requirements 

Annex

Commercial Solutions for Classified (CSfC): Key

Management Requirements Annex, v2.0, January 2021.

January 2021

CSfC Mobile 

Access MA CP

Commercial Solutions for Classified (CSfC): Mobile Access 

Capability Package (CP), v2.6, December 2021

December 2021

CSfC MSC Multi 

Site Connectivity 

CP

Commercial Solutions for Classified (CSfC): Multi-Site 

Connectivity (MSC) Capability Package (CP), v1.2, 

CSfC Symmetric 

Key 

Management 

Requirements 

Annex

Commercial Solutions for Classified (CSfC): Symmetric Key 

Management Requirements Annex, v2.0, January 2021.

January 2021

E.O. 12333 Executive Order 12333 (EO 12333), United States 

Intelligence Activities, as amended, July 30, 2008.

30 July 2008

FIPS 140 Federal Information Processing Standard 140, Security 

Requirements For Cryptographic Modules National Institute 

for Standards and Technology FIPS Publication

March 2019

FIPS 180 Federal Information Processing Standard 180-4, Secure 

Hash Standard (SHS)

August 2015

FIPS 186 Federal Information Processing Standard 186-4, Digital 

Signature Standard (DSS)

July 2013

FIPS 197 Federal Information Processing Standard 197, Advanced 

Encryption Standard (AES)

November 2001

NIST SP 800-111

National Institute of Standards Special Publication (NIST SP) 

800-111, Guide to Storage Encryption Technologies for End 

User Devices, November 2007.

November 2007

NIST SP 800-137

National Institute of Standards and Technology Special 

Publication (NIST SP) 800-137, Information Security 

Continuous Monitoring (ISCM) for Federal Information 

Systems and Organizations, September 2011.

September 2011

NIST SP 800-37 

Rev. 2

National Institute of Standards and Technology (NIST SP)

800-37 Rev. 2, Risk Management Framework for 

Information Systems and Organizations: A System Life Cycle 

Approach for Security and Privacy, December 2018.

December 2018
 

31

Document Title Date

NIST SP 800-53 National Institute of Standards and Technology (NIST SP)

800-53, Security Controls Section 8, controls 1 through 4

NSD-42

National Security Directive 42 (NSD-42), National Policy for 

the Security of National Security Telecommunications and 

Information Systems, July 5, 1990.

5 July 1990

P.L. 113-283 Public Law 113-283, Federal Information Security 

Modernization Act of 2014, December 18, 2014.

18 December 2014

RFC 4308 IETF RFC 4308 Cryptographic Suites for IPsec. P. Hoffman. December 2005

RFC 4754 IETF RFC 4754 IKE and IKEv2 Authentication Using the 

Elliptic Curve Digital Signature Algorithm (ECDSA). D. Fu and 

J. Solinas.

January 2007

RFC 7030 IETF RFC 7030 Enrollment over Secure Transport. M. 

Pritikin, P. Yee, and 

D. Harkins.

October 2013

RFC 7296 IETF RFC 7296 Internet Key Exchange Protocol Version 2 

(IKEv2). 

C. Kaufman, et. al.

October 2014

RFC 8247 IETF RFC 8247 Algorithm Implementation Requirements and 

Usage Guidance for the Internet Key Exchange Protocol 

Version 2 (IKEv2). Y. Nir, et. al.

September 2017

RFC 8295 IETF RFC 8295 EST (Enrollment over Secure Transport) 

Extensions S. Turner.

January 2018

RFC 8422 IETF RFC 8422 Elliptic Curve Cryptography (ECC) Cipher 

Suites for Transport Layer Security (TLS) Versions 1.2 and 

Earlier. Y. Nir, et. al.

August 2018

RFC 8446 IETF RFC 8446 The Transport Layer Security (TLS) Protocol 

Version 1.3. E. Rescorla.

August 2018

RFC 8603 IETF RFC 8603 Commercial National Security Algorithm 

(CNSA) Suite Certificate and Certificate Revocation List (CRL) 

Profile. M. Jenkins, and L. Zieglar.

May 2019

SP 800-131A NIST Special Publication 800-131A, Recommendation for 

Transitioning of Cryptographic Algorithms and Key Lengths. 

E. Barker.

March 2019

SP 800-53 NIST Special Publication 800-53 Rev. 4, Security and Privacy 

Controls for Federal Information Systems and 

Organizations. Joint Task Force Transformation Initiative.

April 2013

SP 800-56A NIST Special Publication 800-56A Rev. 3, Recommendation 

for Pair-Wise Key Establishment Schemes Using Discrete 

Logarithm Cryptography. E. Barker, et. al.

April 2018
 

32

Document Title Date

SP 800-56B NIST Special Publication 800-56B Rev. 2, Recommendation 

for Pair-Wise Key Establishment Schemes Using Integer 

Factorization Cryptography. E. Barker, et. al.

March 2019

SP 800-56C NIST Special Publication 800-56C Rev. 2, Recommendation 

for Key Derivation through Extraction-then-Expansion. E. 

Barker, et. al.

August 2020

SP 800-57-1 NIST Special Publication 800-57 Part 1 Rev. 5, 

Recommendation for Key Management - General. E. Barker. 

May 2020

SP 800-57-2 NIST Special Publication 800-57 Part 2 Rev. 1, 

Recommendation for Key Management – Best Practices for 

Key Management Organizations. E. Barker, et. al.

May 2019

SP 800-57-3 NIST Special Publication 800-57 Part 3 Rev. 1, 

Recommendation for Key Management – ApplicationSpecific Key Management Guidance. E. Barker, et. al.

Jan 2015

SP 800-77 NIST Special Publication 800-77 Rev. 1, Guide to IPsec VPNs. 

E. Barker, et. al.

June 2020