CMMC control families
CMMC System & Communications Protection (3.13 SC): 16 requirements and FIPS-validated crypto
Sixteen requirements covering the boundary, the internal separations and the cryptography. This is where 3.13.11 lives — the requirement that turns "we use AES-256" into a question about a CMVP certificate — and the family where the appliance, the subscription term and the deployment work all belong on the same quote.
- Family
- 3.13 — System & Communications Protection
- Requirements
- 16 of the 110 Level 2 requirements
- Level 1
- In scope — basic requirements from this family
- Boundary
- The capability behind the control — never a certification we hold
The boundary, the separations inside it, and the cryptography over both
System and communications protection is the second-largest family in the standard: sixteen of the 110 Level 2 requirements. It starts at the edge — monitor, control and protect communications at external boundaries and at key internal boundaries (3.13.1) — and works inward through separating user functionality from system management functionality (3.13.3), isolating publicly accessible components in a separated subnetwork (3.13.5), denying network traffic by default and allowing by exception (3.13.6), protecting CUI in transmission (3.13.8) and at rest (3.13.16), and the one every procurement conversation eventually reaches: employ FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI (3.13.11).
What each level asks of this family
System and communications protection is one of the six families Level 1 touches. The FAR 52.204-21 basics that land here are about monitoring, controlling and protecting communications at the external boundary and at key internal boundaries, and about separating publicly accessible system components from internal networks.
Level 2 brings all sixteen, and 3.13.11 is the one with a product-level answer. It asks for FIPS-validated cryptography — validation being a fact about a module, evidenced by a CMVP listing, rather than a claim about an algorithm. "AES-256" on a datasheet is not a validation. The certificate is.
Level 3 layers enhanced requirements from NIST SP 800-172 onto a Final Level 2, assessed by DIBCAC.
What you can actually quote against this family
Each card names the requirement the line serves — hardware, software licensing or the integration work that puts either into service. Naming a control is not a coverage claim: the configuration, the procedure and the evidence stay inside your program, and no purchase — hardware, license or service — confers certification on its own. Naming a manufacturer describes the market, not a Uniqcli partnership or endorsement.
Boundary protection (3.13.1, 3.13.5, 3.13.6)
The external boundary and the key internal ones are where firewalls earn their line item. SonicWall and WatchGuard appliances are genuinely stocked and quoted with the subscription services they need. Palo Alto Networks, Sophos, Check Point and Barracuda are priced and quotable but not stocked, so treat those as lead-time lines — the quote states which is which rather than leaving you to find out.
The subscription half of the boundary
An appliance without its term is an unenforced boundary. Sophos Firewall and Zero Trust Network Access, Citrix NetScaler and its SD-WAN line, Palo Alto Networks and Check Point subscription families and the SonicWall, WatchGuard and Barracuda service bundles are all priced in our licensing catalog. Software is sourced through authorized US distribution rather than held on a shelf, so availability language does not apply to it. Naming a manufacturer describes the market, not a Uniqcli partnership or endorsement.
Deployed and hardened, not just delivered
Through our cyber lane a boundary order can carry the deployment as well as the boxes: NGFW policy build-out, segmentation and identity-services integration, then a hardening pass against CIS benchmarks or your program's STIG baseline before the system goes live, with configuration baselines and change records captured as the work happens rather than reconstructed afterwards.
FIPS-validated cryptography (3.13.11, 3.13.16)
Where cryptography is what protects CUI, the module has to be validated. Hardware-encrypted media from iStorage and Kanguru, Apricorn, Rocstor and Kingston is the clearest place to answer that on the product, and a run of Lantronix console rows carries FIPS titling too, though those are not stocked. Our stock spans BOTH 140-2 and 140-3 wording, so we write FIPS-validated (CMVP-listed) and confirm the certificate on request — never a version claimed across a brand list, never a certificate number printed per line.
Segmentation (3.13.1 internal boundaries)
Key internal boundaries are usually VLANs and separate switching before they are anything else. Managed switches are one of the deepest genuinely stocked lines we carry, with Netgear the largest in-stock managed line on the hub; the quote pairs them with the optics, stacking and licensing the design calls for.
Separating management from user functionality (3.13.3)
Where one operator administers systems across separated networks, NIAP Peripheral Sharing Device secure KVM is the ordinary route — ATEN rows state PSD PP v4.0 compliance in the title, and Vertiv's Cybex line is NIAP-titled and well stocked. That separates the desk; separating the functions inside the systems themselves is architecture and configuration.
Where the line falls
Buying a validated module is not the same as using it in a validated mode, and a firewall in the rack is not boundary protection until the rule set says so. Session authenticity under 3.13.15, transmission confidentiality under 3.13.8, key management and the deny-by-default posture at 3.13.6 are architecture and configuration decisions. Where we build a policy or run a hardening pass, we do it inside your program's own governance and against the baseline your program set — we supply the capability behind the control, never a certification we hold, and we make no claim about what a device inspects, terminates or decrypts in your environment.
One dated fact worth planning around: every remaining FIPS 140-2 certificate moves to the CMVP Historical list on September 21, 2026, with FIPS 140-3 as the successor program. Devices keep working; the evidentiary value of the certificate changes. If a refresh is coming anyway, ask which certificate the line actually holds before you buy it — we confirm that on request.
We are not an assessor, a C3PAO or an RPO, and we hold no CMMC level. We quote against the SSP you already have — hardware, licensing and the integration work around them — not a generic bundle assembled around a level number.
Encryption and boundary questions
Does CMMC require FIPS-validated encryption?
3.13.11 requires FIPS-validated cryptography to be employed when cryptography is used to protect the confidentiality of CUI. That is narrower than "everything must be FIPS" and broader than most people assume, because it follows the data rather than the device. Where the module is the point, ask for the CMVP certificate — we confirm it on request before you commit.
What is the difference between FIPS 140-2 and FIPS 140-3?
140-3 is the successor validation program to 140-2. The practical date is September 21, 2026, when every remaining FIPS 140-2 certificate moves to the CMVP Historical list. A device with a Historical certificate does not stop working, but it is weaker ground when an assessor asks how 3.13.11 is being met, and some programs will not accept it for new deployments. Our stock spans both wordings today, which is why we confirm per line rather than claiming a version across a brand.
What does 3.13.11 actually require?
A validated cryptographic module, not a strong-sounding algorithm. Validation is issued by the Cryptographic Module Validation Program and evidenced by a certificate against a specific module, version and operational configuration — which is why "AES-256" on a datasheet answers nothing. Using a validated module outside its validated configuration is the other common gap.
Do internal servers need FIPS-validated cryptography?
It depends on whether cryptography is what protects CUI on those systems, which is a scoping question about your architecture rather than a rule with a yes or no answer. That call belongs to your program and, where relevant, your assessor — we can tell you what a given product's CMVP position is, but we cannot scope your boundary for you.
Related families and background
Get a CMMC estimate — CMMC System & Communications Protection (3.13 SC)
Tell us where to reach you and a Uniqcli specialist follows up by email to scope what you need across hardware, software licensing and integration, then comes back with pricing and availability — quoted against the SSP you already have, not a generic bundle.
An estimate for the capability behind the control — never a certification we hold. No purchase — hardware, license or service — confers a CMMC level on its own; what you buy makes the controls implementable.
The solutions atlas
Every solution, one accountable partner.
UniQ platforms
By technology
By customer
- TAA & NDAA-889 Compliance Screening
- CMMC & CUI Solutions
- Federal & DoD
- State, Local & Education
- Healthcare
- Enterprise
- Rapid Procurement & GPC Buys
- Multi-Vendor Integration Projects
- eProcurement & Custom Catalogs
- FISMA Modernization
- CJIS-Compliant Justice Cloud & Local AI
- Federal Storage Modernization
- Government ERP & Business Systems Infrastructure
- Managed Procurement
- Secure AV & Conferencing
- Fiber Network Infrastructure
- Satellite & Resilient Connectivity
- Wavelength & Optical Transport
- Decentralized Data Centers
- Data Center Design & Build
Talk to us about the boundary build
Send the boundary design, the refresh list or the SSP section. A Uniqcli specialist replies with an estimate covering the appliances, the subscription terms and any deployment or hardening work the design calls for — FIPS-validated (CMVP-listed) options confirmed on request where the module is the point, availability stated per line, TAA and §889 screening performed before it goes out.