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

SA-4(6) requires you to restrict solutions that protect classified information on lower-classification networks to NSA-approved combinations of information assurance (IA) and IA-enabled COTS/GOTS products, and to prove that restriction is built into acquisition and engineering decisions. Operationalize it by defining scope, enforcing an approved-product gate in procurement, and retaining objective evidence for every affected system. ¹

Key takeaways:

• Scope is narrow but high-impact: classified information traversing networks at a lower classification level. ¹
• The control is an acquisition and architecture gate, not a general “buy secure tools” statement. ²
• Audit readiness depends on traceability: requirement → approved solution → purchase/implementation records → system boundary. ¹

The sa-4(6): use of information assurance products requirement sits in the System and Services Acquisition family because it is meant to shape what gets bought, integrated, and authorized before a system ever transmits sensitive data. Your job as a Compliance Officer, CCO, or GRC lead is to translate a short requirement into an enforceable rule that engineering and procurement cannot bypass.

SA-4(6) is triggered when classified information is transmitted on networks that are at a lower classification level than the information being transmitted. In that scenario, the requirement is explicit: use only government off-the-shelf (GOTS) or commercial off-the-shelf (COTS) IA and IA-enabled IT products that make up an NSA-approved solution. ¹

Practically, this becomes (1) a scoping decision about where “classified over lower” exists, (2) a controlled list of NSA-approved solutions and component products for those paths, (3) procurement and architecture checks that block non-approved components, and (4) evidence packages that show the rule was followed. If you don’t build the gate, teams will “equivalency” their way around it, and you will have no defensible compliance story.

Regulatory text

Excerpt (requirement): “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” ¹

What the operator must do:

• Identify any system, enclave, cross-domain path, remote access path, or communication channel where classified information is transmitted over a network of lower classification. ¹
• For those scoped paths, constrain product selection to COTS/GOTS IA and IA-enabled IT products that collectively form an NSA-approved solution (not “security products we like,” and not “meets our internal standard”). ¹
• Embed this constraint into acquisition requirements and technical architecture approvals so it is enforced before purchase and deployment. ²

Plain-English interpretation (what SA-4(6) really means)

If you allow “higher sensitivity data over a lower environment,” you must use an NSA-approved set of assurance components for that situation. SA-4(6) is less about tuning controls after deployment and more about preventing non-conforming designs from entering production.

A useful way to explain it to engineering:

• “For these specific data paths, we are not accepting ‘equivalent’ cryptography or ‘similar’ security appliances. The solution must match an NSA-approved solution definition, and we must be able to prove that the exact products deployed match that solution.”

Who it applies to (entity and operational context)

Entity types (typical):

• Federal information systems and programs implementing NIST SP 800-53 controls. ²
• Contractors operating systems handling federal data where SA-4(6) is in the applicable control baseline or contract security requirements. ¹

Operational contexts that commonly trigger SA-4(6):

• Any architecture where classified information traverses a network segment, transport, or service with a lower classification level than the data itself. ¹
• Programs that rely on boundary devices, encryptors, cross-domain mechanisms, or secure gateways to move data between different classification contexts.

Who owns execution:

• Control owner (GRC/ISSO/ISSM): defines scope, sets the acquisition rule, maintains evidence.
• Enterprise architecture / security engineering: defines reference architectures and approved component patterns.
• Procurement / supply chain: enforces purchasing restrictions and collects vendor/product evidence.
• System owners / PMO: ensure implementations match approved designs and changes are controlled.

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

1) Confirm applicability and scope boundaries

Create a short “SA-4(6) applicability memo” for each program/system:

• Where does classified information exist, and what are the transmission paths?
• Which networks in those paths are at a lower classification level than the information transmitted? ¹
• What system boundary and interfaces are in scope (diagrams required).

Deliverable: Scoped inventory of affected data flows and interfaces, with an owner per flow.

2) Define what “NSA-approved solution” means for your environment

SA-4(6) hinges on “compose an NSA-approved solution.” ¹ Convert that into an internal standard your teams can execute:

• A controlled list of approved solution profiles (solution name, intended use, constraints, required components).
• For each profile, the list of allowed COTS/GOTS IA and IA-enabled products and required configuration baselines.

If your organization already has an “approved products list,” tighten it:

• Make it path-specific (approved for “classified over lower” is stricter than general enterprise use).
• Require a traceable mapping: product → role in NSA-approved solution → where deployed.

3) Build an acquisition gate (the control’s center of gravity)

Operationalize SA-4(6) in procurement and contracting:

• Add SA-4(6) language into purchase requests, SOWs, and design specs for in-scope solutions. ²
• Require engineering to cite the approved solution profile ID in every request.
• Block purchases that lack the citation or propose non-listed products.

Practical gate design:

• Intake form fields: “Is this for classified over lower transmission?” “Which approved NSA solution profile?” “Which components?”
• Approval workflow: security engineering + compliance sign-off for any exceptions (ideally, no exceptions; if allowed, they must be documented and time-bound).

4) Engineer the implementation to match the approved solution

Require your system teams to produce:

• Network and data flow diagrams showing where the NSA-approved solution sits.
• Configuration baselines for the selected IA/IA-enabled components.
• Build/implementation records tied to specific asset IDs/serials/licenses.

This is where most programs fail: they can show a purchase, but not that the deployed devices/software match the approved solution definition across the entire path.

5) Establish change control triggers

SA-4(6) is fragile under routine change. Define “SA-4(6)-significant changes” that force review:

• Swapping encryption components, gateways, boundary devices, or “security appliance” equivalents.
• Major version upgrades that invalidate the approved solution composition.
• Moving workloads or routing traffic such that the “classified over lower” condition changes.

Tie the triggers to your change management process and architecture review board.

6) Set recurring evidence collection (audit-ready by default)

SA-4(6) assessments often turn into evidence hunts. Avoid that by scheduling a recurring evidence pull:

• Approved solution profile register export
• Procurement records for in-scope components
• CMDB/asset inventory showing deployed components by system
• Current diagrams and last architecture approval

Daydream tip: Many teams track control implementation in spreadsheets that never match what procurement and engineering actually did. Daydream works well as the “single narrative” layer: control requirement, owner, procedure, and a standing evidence checklist that each system must satisfy before an ATO or assessment.

Required evidence and artifacts to retain

Keep artifacts in a system-specific package so you can answer “show me for System X” without assembling it live.

Minimum evidence set (operator-grade):

• SA-4(6) applicability memo and scoping rationale (why in scope / out of scope). ¹
• Data flow + network diagrams marking the “classified over lower” transmission segments. ¹
• Approved solution profile showing the NSA-approved solution composition and allowed IA/IA-enabled products. ¹
• Procurement records (POs, invoices, license confirmations) tied to the approved component list.
• Build/config evidence (baseline configs, deployment manifests, screenshots/exports) proving the deployed components match the approved solution.
• Change records for any modifications to in-scope paths/components and the associated re-approval.

Common exam/audit questions and hangups

Auditors and assessors tend to press on a few predictable points:

1. “Show me the specific transmissions where classified goes over lower.”
   Hangup: teams describe it verbally but cannot show diagrams. Bring diagrams with labeled trust boundaries.

2. “How do you know these exact products compose an NSA-approved solution?”
   Hangup: “approved vendor” is not the same as “NSA-approved solution composition.” Keep a controlled solution profile artifact for each allowed pattern. ¹

3. “How does procurement prevent a bypass?”
   Hangup: policy exists, but PRs/POs do not require the SA-4(6) gate fields. Fix the workflow, not the slide deck. ²

4. “What happens when engineering upgrades or swaps components?”
   Hangup: no change triggers tied to SA-4(6) scope. Define the triggers and show change tickets.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating SA-4(6) as a generic encryption requirement.
  Fix: scope it to “classified over lower” transmissions and enforce NSA-approved solution composition. ¹

• Mistake: relying on vendor attestations without internal traceability.
  Fix: require internal mapping from each deployed component to the approved solution profile, plus asset-level proof.

• Mistake: evidence scattered across teams.
  Fix: maintain a per-system evidence packet with a stable index. Daydream can store the control procedure and evidence checklist so teams collect the same artifacts each cycle.

• Mistake: exception process that becomes the normal process.
  Fix: if exceptions exist, force explicit risk acceptance, a remediation plan, and re-approval gates before renewal.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Treat SA-4(6) as an assessment and authorization risk: if you cannot demonstrate NSA-approved solution use for in-scope transmissions, you risk failing security assessments, delaying an ATO, or triggering contract non-compliance discussions. ²

Practical 30/60/90-day execution plan

Your timeline will depend on system complexity and procurement cycles, so use phases instead of calendar-day promises.

Immediate (stabilize and scope)

• Assign a control owner and RACI for SA-4(6). ²
• Perform scoping: identify “classified over lower” transmissions and document them. ¹
• Freeze ad hoc purchasing for in-scope paths until the gate is in place.

Near-term (build the gate and evidence backbone)

• Publish approved solution profiles and the allowable component list for each profile. ¹
• Update procurement intake and approval workflow to require an approved profile reference.
• Create the evidence packet template and require system owners to populate it.

Ongoing (operate and prove)

• Tie SA-4(6) triggers into change management and architecture review.
• Run periodic evidence checks: confirm deployed components still match approved solution profiles.
• Use Daydream (or your GRC system) to map SA-4(6) to a named owner, an implementation procedure, and recurring evidence artifacts so audits become retrieval, not reconstruction. ¹

Frequently Asked Questions

Does SA-4(6) apply to all systems in my environment?

No. It applies when classified information is transmitted on networks at a lower classification level than the information being transmitted. Document why each system is in scope or out of scope. ¹

What counts as an “information assurance” or “IA-enabled” product for SA-4(6)?

Treat this as the set of security-relevant products that are components of the NSA-approved solution used to protect the transmission path. Your internal approved solution profile should name the specific products and roles. ¹

Can we use an equivalent product if it meets our internal crypto standards?

SA-4(6) is written as a restriction to products that compose an NSA-approved solution for this scenario. If you allow exceptions, document risk acceptance and the rationale, and expect scrutiny during assessment. ¹

What evidence do assessors usually ask for first?

They start with diagrams that show the “classified over lower” transmission segments, then they ask you to prove the deployed components match an approved solution composition. Keep purchase and build records tied to the same component list. ¹

How do we operationalize SA-4(6) across third parties and integrators?

Put the approved solution profiles and component restrictions into SOWs and acceptance criteria, and require integrators to deliver the evidence packet as part of system delivery. Then enforce the same change triggers post-go-live. ²

Where does SA-4(6) live in our control documentation?

Place it in your acquisition/security engineering standards, then cross-reference it in architecture review and change management procedures so it becomes a build-and-buy gate. Track ownership, procedure, and evidence centrally in your GRC workflow. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5