Not Every Device Needs to Be FIPS Validated
A position paper for CMMC assessors, compliance professionals, and the IT engineers who support them
Sweeping Every Device Into Scope Is a Scoping Error
Pass-through network devices that carry encrypted CUI traffic are not CUI Assets, do not need to be FIPS validated, and do not belong in your SSP. The OSI model explains why, the common carrier analogy makes it practical, and DoD's own FAQ guidance confirms it.
The scoping error is common and costly. Firewalls, routers, and switches get swept into scope, FIPS mode gets toggled on everything in the rack, and a compliance project triples in complexity.
The instinct behind this is understandable. "Encrypted CUI is still CUI" (confirmed in DoD CIO CMMC FAQ B-Q8), so a firewall carrying encrypted CUI traffic looks like a CUI Asset (an asset that processes, stores, or transmits CUI), which means it must meet all applicable NIST SP 800-171 requirements, including 3.13.11, which mandates FIPS-validated cryptography.
That chain of logic is wrong.
Encryption Applied at the Application Layer Does Not Need Repeating Below
Every network layer treats the layers above it as payload it cannot read. That principle is why FIPS-validated protection established at the point of encryption does not need to be re-established by every downstream device.
The Open Systems Interconnection (OSI) model describes network communication as seven conceptual layers, from the physical medium up to the application. Every piece of data flowing through a network breaks into one or more packets represented by this model. The TCP/IP model collapses these into four layers:
As data travels from an application down to the physical medium, each layer adds its own header and treats everything above it as an opaque payload. A router at Layer 3 sees IP headers and forwards packets. It does not see, process, or understand the TLS-encrypted payload inside. A switch at Layer 2 sees MAC addresses and moves frames. It is even further removed from the application data.
This layered separation is not just a technical detail. It is the foundation of the FIPS scoping argument, and the way the internet has been designed to work since its earliest standards. Each layer trusts that the layers above it have handled their own concerns. Security applied at the application layer does not need to be re-applied by every device below it.
3.13.11 Follows Function, Not Location
NIST SP 800-171 Requirement 3.13.11 applies to the device providing cryptographic confidentiality for CUI, not to every device the resulting ciphertext passes through.
The requirement states:
"Employ FIPS-validated cryptography when used to protect the confidentiality of CUI."
The operative phrase is "when used to protect the confidentiality of CUI." This is a function-based requirement. It applies to the cryptographic mechanism actually providing confidentiality, not to every device the resulting ciphertext happens to pass through.
Consider a practical example. A user in a defense contractor's enclave accesses Microsoft GCCH (Government Community Cloud High) SharePoint. The connection uses TLS 1.2 (or 1.3) with FIPS 140-validated cipher suites on both ends. On the Microsoft side, this is implemented as part of their FedRAMP Authorization. On the contractor side, the workstation or server initiating the connection must also use a FIPS-validated cryptographic module. From the moment that TLS session is established with both endpoints using validated modules, the CUI payload is encrypted with FIPS-validated cryptography.
That encrypted payload then travels down through the stack:
It becomes a TCP segment at Layer 4, handed off from the application to the OS for delivery
It becomes an IP packet at Layer 3, forwarded by routers
It becomes an Ethernet or Wi-Fi frame at Layer 2, transmitted toward its destination before being passed to the physical medium
At no point do the firewalls, routers, switches, or access points in that path decrypt, inspect, or re-encrypt the CUI payload. Once the browser hands the encrypted data to the operating system, the OS and every device downstream forward opaque ciphertext. The protection is established by a FIPS-validated cryptographic module at the point of encryption, and it travels with the resulting ciphertext through every subsequent hop. Network devices downstream do not need to provide cryptographic coverage because that coverage is already in place.
Pass-Through Devices Are No Different From Common Carriers
DoD's own guidance treats encrypted CUI traversing common carrier networks as an accepted risk. The same logic applies to pass-through network devices that carry encrypted traffic without accessing it.
DoD FAQ B-Q8 acknowledges this directly, noting that "certain risks (e.g., transmission across unsecured, 'common carrier' networks) are accepted for cipher text that would not be accepted for plain text." ISPs are common carriers: they transmit data without accessing it, they are not assets the contractor owns or controls, and they provide no security functions for the CUI environment. No assessor would bring an ISP into an OSA's assessment boundary for those reasons, regardless of whether encrypted CUI traverses its infrastructure.
A pass-through network device operates on the same principle. If a device performs basic transport functions, addressing, routing, and forwarding, with no ability to decrypt or store the data passing through it, it is functionally equivalent to a common carrier. It does not own the data, cannot read it, and provides nothing the CUI environment depends on. The same logic that scopes out the ISP applies.
Four Conditions Define an Out-of-Scope Network Device
A network device is out of scope when it meets all four conditions below. If it fails any one of them, it is in scope to some degree. The conditions map directly to NIST SP 800-171 / CMMC requirements and together define what it means for a device to have no meaningful relationship to CUI confidentiality.
1. Data Encryption (3.13.11, 3.13.8) CUI must be encrypted using FIPS-validated cryptography before transmission through the network device. The device cannot be responsible for performing this function. It carries already-encrypted data from the CUI Assets in the enclave.
2. No Decryption (3.13.10) The network device must not decrypt previously encrypted data packets or files. It must not have access to decryption keys and must not be configured to inspect encrypted traffic.
3. No CUI Packet Capture (3.13.2, 3.4.6) The network device must not intercept and store network packets in a way that leaves them susceptible to future decryption.
4. No Security Functions for CUI Assets (3.1.5, CMMC L2 Scoping Guide) The network device must not provide security functions that CUI Assets inherit, that appear in the SSP, and that satisfy NIST SP 800-171 assessment objectives. If the device's security role is documented in the SSP as supporting the assessment boundary, it is no longer out of scope.
A device that fails condition four because it provides a security function the assessment boundary relies on is not a compliance problem, provided it is documented in the SSP as a Security Protection Asset (an asset that provides security functions on behalf of the CUI environment). The next section covers what that means in practice.
A Firewall's Category Follows Its Function
A firewall is not automatically a CUI Asset, a Security Protection Asset, or an out-of-scope asset. Its category depends entirely on what function it performs relative to the assessment boundary. The same model of firewall, sitting in two different positions in the same network, lands in two different categories.
CUI Asset
A firewall is a CUI Asset when it processes CUI, meaning it can read, inspect, or act on the content of that data. Two clear examples:
A VPN concentrator that terminates an encrypted tunnel decrypts traffic, exposing the CUI payload, then re-encrypts it for onward transmission. This type of VPN termination directly provides confidentiality for CUI, making it a CUI Asset where 3.13.11 applies. Not all VPN concentrators work this way. A device that re-encapsulates packets without breaking the underlying encryption, such as a site-to-site IPsec tunnel in transport mode, may not access the CUI payload at all and is evaluated differently.
A next-generation firewall performing SSL/TLS inspection acts as a man-in-the-middle, decrypting traffic for inspection. It processes CUI in plaintext and is a CUI Asset.
Security Protection Asset
A firewall is a Security Protection Asset when it provides a security function the assessment boundary relies on, and that function is documented in the SSP. A perimeter firewall configured as default-deny, enforcing network segmentation, or controlling access to the CUI enclave is a practical example. If you need to reference that firewall in your SSP to explain how your internal or external boundaries are protected, it is in scope as an SPA.
SPAs are assessed, but the scope of assessable requirements is narrower than for CUI Assets. An assessor evaluates whether the asset properly performs its defined security functions. 3.13.11 does not apply to an SPA that does not itself provide cryptographic protection for CUI. An SPA firewall does not need to run in FIPS mode to enforce its relevant requirements.
The devices most likely to qualify as SPAs, such as firewalls, routers and VPNs, are also the devices that create the logical separation DoD CIO CMMC FAQ F-Q4 requires. If those devices do their job and are documented in your SSP, they make the out-of-scope determination for your enterprise networking components defensible.
Out-of-Scope Asset
A firewall is out of scope when it meets all four conditions: CUI arrives already encrypted, the device cannot decrypt it, the device does not capture and store packets, and the device provides no security functions the assessment boundary relies on. If you do not need to reference that firewall in your SSP to explain how your scope is protected, and it is not decrypting or storing anything, it is out of scope.
The practical question: does this device appear in your SSP because it does something for your assessment boundary? If yes, it is at minimum an SPA. If no, and it meets the four conditions, it is out of scope.
Summary by Asset Category
F-Q4 Confirms Enterprise Networking Components Are Out of Scope
DoD CIO CMMC FAQ F-Q4 closes this argument with direct guidance:
"Q: Our enclave does not have a direct internet connection. Instead, it relies on enterprise networking components residing outside of the enclave. All CUI data is properly encrypted before leaving our enclave. Must the enterprise networking components be brought into our enclave's CMMC Assessment Scope?
A: No. So long as the enclave is otherwise logically separated from the greater enterprise network, the transmission of properly encrypted CUI data does not incur an extension of the CMMC Assessment Scope to include the enterprise networking components."
Enterprise networking components, which explicitly include firewalls and routers, stay outside CMMC assessment scope when CUI is properly encrypted before it reaches them and the enclave is logically separated from the broader network. This maps directly to the four conditions above. The CUI arrives already encrypted, the enterprise networking components do not decrypt it, they do not capture and store packets, and they provide no security functions the SSP describes on behalf of the assessment boundary. Because they do not appear in the SSP in a security role, they are out of scope entirely, failing the test for both Security Protection Asset and CUI Asset.
This determination applies to networking components outside the assessed enclave boundary. It does not extend inward: devices inside the boundary are subject to standard asset categorization regardless of whether the traffic they carry is encrypted.
One important clarification before relying on F-Q4: DoD FAQ F-Q3 confirms that encryption alone does not create logical separation. As the FAQ states, "logical separation occurs when data transfer between physically connected assets is prevented by non-physical means such as software or network assets, e.g., firewalls, routers, Virtual Private Networks, Virtual Local Area Networks." Encrypting CUI before it leaves your enclave satisfies the encryption condition for F-Q4, but logical separation requires something more: an enforced boundary that prevents unauthorized data transfer. F-Q4 only applies when both are genuinely in place.
A skeptical assessor might argue that F-Q4 describes a narrow topology, specifically an enclave that routes through enterprise networking components to reach the internet, and does not generalize to every pass-through device in every network configuration. That reading is too narrow. F-Q4 does not create a new scoping rule. It confirms the application of an existing one: a device that carries encrypted CUI without decrypting it, storing it, or providing security functions for the assessment boundary has no meaningful relationship to CUI confidentiality. The enclave topology in F-Q4 is an example of that principle, not the boundary of it. The four conditions in the previous section define where the principle applies, and F-Q4 confirms the outcome when all four are met.
Out-of-Scope Devices Do Not Appear in the SSP
If a network device is fully out of scope, it does not belong in your SSP. The documentation work happens within your assessable boundary, not at the device itself.
Your SSP should clearly establish three things:
1. Where encryption occurs. Identify the CUI Assets that encrypt data using FIPS-validated cryptography before it leaves the enclave. For example, workstations and servers accessing GCCH SharePoint via TLS 1.2 with FIPS 140-validated cipher suites. This is where 3.13.11 is satisfied. Every CUI data flow needs the same answer: where does FIPS-validated encryption occur, and who is responsible for it. See the Defensible Scoping section below if you are uncertain about your data flows.
2. How the enclave is logically separated. Document the boundary between your CUI environment and the broader enterprise network. This supports the F-Q4 determination. Without documented logical separation, the out-of-scope argument for enterprise networking components does not hold.
3. What is not in scope and why. Your network diagram should show that enterprise networking components outside the enclave carry only encrypted traffic and perform no security functions on behalf of the boundary. Their absence from the SSP asset inventory is itself the documentation. If an assessor asks, the answer is that these devices do not meet the criteria for any in-scope asset category under 32 CFR 170.19.
Cloud Storage Is Different: FedRAMP Still Required
This reasoning applies to transit scenarios: devices forwarding data that is already encrypted. It does not apply to storage scenarios.
A cloud service provider storing encrypted CUI is still storing CUI (B-Q8). A contractor's obligation under DFARS 252.204-7012 to use a FedRAMP Moderate-authorized (or equivalent) provider is not satisfied by encryption alone (FAQ E-Q2). The FedRAMP authorization requirement is a contractual and regulatory obligation that exists regardless of whether 3.13.11 is satisfied by encryption in transit. Encryption of data at rest does not substitute for FedRAMP authorization of the cloud environment.
Pass-Through Devices Do Not Need to Be FIPS Validated
The case rests on three independent supports. The OSI model establishes that encryption applied at the application layer does not need repeating by downstream devices: each layer treats the layers above it as payload it cannot read, and a device forwarding ciphertext has no more access to CUI than an ISP forwarding encrypted internet traffic. DoD's own guidance in B-Q8 accepts the risk of encrypted CUI traversing common carrier networks, and a pass-through network device that meets the four conditions is functionally equivalent to a common carrier. DoD FAQ F-Q4 confirms the outcome directly: enterprise networking components outside an encrypted, logically separated enclave do not extend the CMMC Assessment Scope.
A device that does not decrypt CUI, does not capture packets, and provides no security function the assessment boundary relies on is not a CUI Asset, does not need to be FIPS validated, and does not appear in your SSP. What changes if this analysis is accepted: firewalls and routers that carry encrypted CUI without inspecting it come out of scope, FIPS mode requirements concentrate where they belong (on the devices actually providing cryptographic protection), and assessment boundaries shrink to reflect actual risk rather than network proximity.
As covered above, this reasoning stops at cloud storage. FedRAMP authorization is a separate obligation that encryption in transit does not satisfy.
Defensible Scoping Starts With Knowing What Is Actually CUI
Everything in this post depends on one prerequisite: understanding exactly where CUI enters your environment, where it travels, and where it leaves. Before you can draw a boundary, write an SSP, or make a defensible out-of-scope determination, you need to know your data flows.
That means knowing which applications handle CUI, which users access it, how it moves across your network, and where it is encrypted. Without that foundation, even the most well-reasoned scoping argument falls apart under assessment.
It also means knowing what actually qualifies as CUI in the first place. Most companies operate on assumptions. Some over-scope, treating data as CUI when it is not. Others under-scope, missing data elements that genuinely require protection. The answer lives in your contracts, your deliverables, applicable export control requirements, and the CUI Registry. Working through all of those together produces decisions that are defensible, not just plausible.
If you want help resolving those assumptions, reach out using the Contact form. DEFCERT digs into the data elements, the contracts, and the registry so you can draw your boundary with confidence.
References
NIST SP 800-171 Rev. 2, Requirements 3.1.5, 3.4.6, 3.13.2, 3.13.8, 3.13.10, 3.13.11
DoD CIO CMMC FAQ v2.3 (May 2026), B-Q8, E-Q2, F-Q3, F-Q4