SA-4(6): Use of Information Assurance Products

SA-4(6) is a supply chain and architecture requirement disguised as a contracting detail. If your environment ever transmits classified information across networks that are classified lower than the data itself, you cannot treat encryption, cross-domain mechanisms, or “secure transport” as an engineering preference. You must constrain the allowable products to GOTS/COTS information assurance (IA) and IA-enabled IT products that collectively form an NSA-approved solution. ¹

For a CCO or GRC lead, the fastest path to operationalizing SA-4(6) is to translate it into: (1) a clear applicability trigger (“classified over lower-class network”), (2) an approved product/solution list controlled by governance, and (3) repeatable control points across procurement, system design, and change management that prevent non-approved substitutions. Your auditors will not accept “we intended to” or “engineering chose a secure product.” They will ask what is allowed, who approves, what stops unapproved products, and what you can show for a specific implementation.

This page gives requirement-level steps, evidence expectations, and audit-ready framing aligned to NIST SP 800-53 Rev. 5. ²

Regulatory text

Control requirement (excerpt). “Employ only government off-the-shelf or commercial off-the-shelf information assurance and information assurance-enabled information technology products that compose an NSA-approved solution to protect classified information when the networks used to transmit the information are at a lower classification level than the information being transmitted; and” ¹

Operator interpretation. If you transmit classified information over a network segment that is classified lower than the data, you must:

1. identify the IA “solution” that protects that transmission (not just a single product),
2. ensure every product in that solution is GOTS or COTS IA / IA-enabled IT, and
3. ensure the solution is NSA-approved, then enforce “approved only” through procurement and engineering controls. ¹

Plain-English interpretation (what this really means)

• This is a “no bespoke crypto / no random security stack” requirement for specific classified-data transmission scenarios. The organization is not free to assemble an ad hoc mix of tools if the scenario matches the trigger condition.
• “NSA-approved solution” is the center of gravity. The requirement is not satisfied by saying “we use encryption.” You need to show the end-to-end protective approach is an approved solution and that only constituent products are deployed for that use case. ¹
• The trigger is contextual. The requirement activates when the network used to transmit the information is at a lower classification than the information being transmitted. You need a way to detect and govern that condition, not rely on tribal knowledge.

Who it applies to (entity and operational context)

Applies to:

• Federal information systems and contractor systems handling federal data where classified information transmission over lower-classification networks is in scope for the system boundary. ¹

Operational contexts where it commonly shows up:

• Classified data moving between enclaves, sites, mission partners, or hosted environments where the transport network is not classified to the same level as the data.
• Boundary protection and secure communications designs, including encryption devices, network security stacks, and any “solution” intended to protect classified data in transit over lower-classification networks.

Practical scoping questions (use these to decide if SA-4(6) applies):

• Do we ever transmit classified information outside a like-classified enclave?
• Are there any links, circuits, transport networks, or intermediary systems at a lower classification than the data being carried?
• Do third parties (carriers, managed service providers, cloud providers, mission partners) provide any segment of the transmission path?

If the answer is “yes” or “unknown,” treat SA-4(6) as in scope until you can prove otherwise.

What you actually need to do (step-by-step)

1) Create a one-page “requirement control card” (so ownership and gates are explicit)

Minimum fields:

• Objective: Only deploy GOTS/COTS IA products that make up an NSA-approved solution for the defined transmission scenario. ¹
• Control owner: Usually Security Architecture or ISSO/ISSM for classified programs; Compliance owns oversight.
• Trigger events: new system design; new circuit/link; product substitution; major version upgrade; new third party involved in transport.
• Decision rights: who can approve the NSA solution list; who can approve exceptions (ideally no technical exceptions without formal risk acceptance).

This prevents the most common failure: no one can explain “who runs SA-4(6).”

2) Define the applicability boundary in engineering terms (make the trigger testable)

Create a short standard:

• “Classified transmission over lower-classification network” definition (your program’s classification handling rules apply).
• In-scope transmission patterns (site-to-site, enclave-to-enclave, partner-to-partner).
• Out-of-scope conditions (only if you can defend them).

Output: SA-4(6) applicability statement tied to your system boundary and data flows.

3) Build and maintain an “NSA-approved solution” allowlist (solution-level, not just product-level)

Create two artifacts:

• Approved Solution Register: each entry includes purpose, scope, constituent products, versions, and where it is approved for use (system types, enclaves, links).
• Approved Product List (APL): the specific GOTS/COTS IA and IA-enabled products allowed to be used as part of those solutions.

Operational rule: engineering can only select from the register/APL for the in-scope scenario. Any deviation triggers formal review.

4) Wire it into procurement and third-party onboarding

Add contract/procurement gates:

• Purchase requests for in-scope environments must reference an Approved Solution Register entry (or request evaluation).
• Third party statements of work must require the third party to deploy only the approved solution/products for the in-scope transmissions, and to provide configuration/version evidence.

This is where third-party risk management intersects SA-4(6): you must stop non-approved product introduction by service providers.

5) Wire it into architecture review and change control (this is where control effectiveness is proven)

Minimum workflow changes:

• Architecture review checklist includes: “Does any classified data traverse a lower-classification network? If yes, map to Approved Solution Register entry.”
• Change tickets involving in-scope components must record: solution ID, product/version, and approval reference.
• CI/CD and infrastructure-as-code repositories should tag relevant components to the approved solution entry where possible (even a simple metadata file helps).

6) Run control health checks (prevent drift)

Set an operational cadence that matches your environment’s rate of change:

• Reconcile deployed products/versions against the APL.
• Verify in-scope links/routes still map to an approved solution.
• Track exceptions to closure with due dates and evidence.

Daydream (as a GRC system of record) fits naturally here: you can manage the requirement control card, map systems and third parties to the Approved Solution Register, and generate an audit-ready evidence bundle without hunting across tickets and shared drives.

Required evidence and artifacts to retain

Auditors typically want proof across design, approval, implementation, and operation. Keep:

• Requirement control card: owner, triggers, steps, exception rules.
• Applicability statement and data flow diagrams showing where classified data transits and which network segments are lower classification.
• Approved Solution Register and Approved Product List with version control and approval history.
• Architecture review records showing selection of an approved solution for each in-scope design.
• Procurement records tying purchases and third-party contracts to the approved solution/products.
• Change management tickets for installs/upgrades/config changes for in-scope components (with references to the allowlist entry).
• Periodic reconciliation results (deployed vs approved) and remediation tracking to closure.

Keep these in a single, named evidence package per system or enclave. Fragmented evidence is a repeat audit failure.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where SA-4(6) is implemented for this system boundary.” (They want scoping plus evidence.)
• “Which networks are lower classification than the data they transmit?” (They want a defensible mapping, not a guess.)
• “What is your NSA-approved solution, and where is it documented?” (They want a stable register.)
• “How do you prevent engineers or third parties from substituting non-approved products during upgrades?” (They want gating in change/procurement.)
• “Show me the last time you reconciled deployed products/versions to the approved list.” (They want operational proof.)

Hangup: teams often present a product datasheet or internal “approved crypto” email thread. That rarely demonstrates “compose an NSA-approved solution” across all constituent products and the specific transmission context. ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating this as a policy-only requirement.
   Fix: create enforceable allowlists plus mandatory workflow fields in procurement/change tickets.

2. Listing products but not the solution composition.
   Fix: model the “solution” as an assembly (e.g., endpoint, key management, network device, management plane) and approve that package for specific scenarios. ¹

3. No trigger definition, so teams miss applicability.
   Fix: hardcode a scoping question into architecture review: “Does classified transit over lower-classification network exist?”

4. Exceptions without discipline.
   Fix: require documented risk acceptance, defined compensating controls, and an expiration date tied to a remediation plan.

5. Third-party blind spot.
   Fix: flow down requirements into third-party statements of work and require evidence (versions/configs) during onboarding and periodic reviews.

Risk implications (why operators care)

SA-4(6) concentrates on a high-impact failure mode: misaligned protection for classified data in transit when the transport network is not equivalently classified. If you cannot prove that only NSA-approved solutions are used, your organization can face loss of authorization, contract impacts, and forced re-architecture. Even absent public enforcement in the provided source set, the operational risk is straightforward: a single non-approved component in the chain can invalidate the intended assurance claim for that transmission path. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and governance)

• Assign a single control owner and backup; publish the SA-4(6) control card.
• Identify in-scope systems/enclaves and list all transmission paths where classified data may traverse a lower-classification network.
• Stand up an initial Approved Solution Register and Approved Product List, even if it starts small.
• Add a mandatory scoping question to architecture review and a mandatory “approved solution ID” field to change requests for in-scope components.

By 60 days (make it enforceable across procurement and change)

• Update procurement intake so requests tied to in-scope environments must reference an approved solution/product.
• Add third-party contract language or onboarding checks that restrict in-scope deployments to approved solutions/products.
• Begin reconciliations between deployed components and the APL; open remediation items for gaps.

By 90 days (prove ongoing operation)

• Complete at least one full control health check cycle: scope review, reconciliation, issue closure evidence.
• Perform a tabletop audit: pick one in-scope link and assemble the entire evidence trail from design decision through deployment and verification.
• Move evidence bundling into your GRC workflow (Daydream or your existing platform) so the next audit is a retrieval exercise, not an investigation.

Frequently Asked Questions

Does SA-4(6) apply to all encrypted network traffic in our enterprise?

No. It applies to the scenario where classified information is transmitted over a network at a lower classification than the data. Confirm applicability by mapping data classification to each network segment in the transmission path. ¹

What counts as an “NSA-approved solution” for SA-4(6)?

The control requires that the IA/IA-enabled products “compose an NSA-approved solution” for the defined transmission scenario. Treat this as a governed, documented solution package with named constituent products, versions, and approval records. ¹

Can we use open-source security tools as part of the SA-4(6) protection stack?

The excerpt specifies only GOTS or COTS IA and IA-enabled IT products for the NSA-approved solution in this scenario. If open-source is proposed, route it through formal evaluation and document why it fits within an approved solution or keep it out of the in-scope path. ¹

How do we operationalize this if a third party provides part of the network transport?

Treat the third party as in scope for SA-4(6) where they influence the transmission solution. Flow the allowlist requirement into contracts and require configuration/version evidence that what they deployed matches the approved solution. ¹

What evidence do auditors usually reject for SA-4(6)?

Single-product datasheets, informal emails claiming approval, and policy excerpts without proof of deployment gating commonly fail. Auditors expect traceability from an approved solution register to architecture decisions, change tickets, and reconciliations. ¹

We have an approved solution, but teams keep upgrading versions. How strict should we be?

Be strict enough to preserve the approval basis. If versions matter to the approval boundary, capture approved versions in the APL and require a change record plus re-approval decision when versions change for in-scope components.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5 DOI