Get tomorrow's brief in your inbox
Today: Defense contractors on Reddit are navigating CAD outsourcing proof points for CUI projects, debating FIPS requirements for physical access control, and asking whether to scope entire companies or carve out enclaves for CMMC Level 2. CISA's quantum crypto lead warned civilian agencies are behind on PQC inventories and lack budget for the 2030 transition, a timeline that will eventually cascade to DIB suppliers.
Reddit marketplace questions show contractors wrestling with proof and scope during the CMMC suspension. On Oct 9, a machine shop holding its first defense subcontract asked what credentials to verify before sending CUI drawings to a CAD outsourcing firm (source). The contract includes export-control notices. AS9100, CMMC, and ITAR registration answer different questions: AS9100 is quality management, CMMC (currently self-attested Level 2) governs CUI handling, and ITAR registration addresses export-controlled technical data (ITAR is separate from CMMC; some CUI is not ITAR-controlled, some ITAR data is CUI). Check the contract's DFARS 252.204-7012 clause and any ITAR provisions. If the drawings are marked CUI and covered by an export-control notice, the vendor must handle CUI per NIST 800-171 (self-attested today) and comply with ITAR if the data qualifies. Ask for evidence of both: a current NIST 800-171 self-assessment score in SPRS and ITAR registration if export control applies. Do not accept a "we're working on CMMC" statement; DFARS 7012 is in force now.
On Oct 11, a general contractor floated the idea of a directory matching CMMC-compliant subs with CUI projects (source). The post was thin on detail. During the suspension, only self-attestation applies unless a prime contractually flows down a future C3PAO requirement. A matchmaking list would need to verify current SPRS scores and clarify whether listings mean "NIST 800-171 compliant today" or "planning future certification." Primes should validate subcontractor SPRS entries directly rather than rely on third-party rosters.
FIPS requirements for physical access control and workstations remain a point of confusion. On Oct 9, a contractor asked whether door access systems (badge readers, controllers, smartcards) for a CUI enclave must be FIPS 140-validated and NDAA Section 889 compliant (source). NIST 800-171 control 3.1.13 requires FIPS-validated cryptography to protect CUI confidentiality; physical access readers and badges that store or transmit cryptographic keys (e.g., encrypted card credentials) fall under this requirement if the encryption protects CUI. NDAA Section 889 prohibits certain Chinese telecom and video surveillance vendors (Huawei, ZTE, Hikvision, Dahua, Hytera); it does not broadly mandate NDAA compliance for all access hardware unless the hardware also performs covered telecom or video functions. Door controllers that are standalone and not tied to covered functions are not subject to Section 889, but if the vendor's parent company is on the prohibited list or the system includes video surveillance integration, Section 889 applies. Mercury systems claim both FIPS 140 validation and NDAA compliance; Ubiquiti claims NDAA compliance but not FIPS. If the access system uses cryptography to protect CUI (encrypted credentials, network-attached controllers transmitting keys), FIPS validation is required. If it does not handle CUI cryptographic material, FIPS is not required for the lock itself. Check your SSP's cryptographic module inventory (800-171 control 3.13.11) and map each component.
Another Oct 9 thread asked what breaks when enabling FIPS mode on Windows 11 workstations and Server 2025 (source). Enabling the FIPS policy (Security Settings > Local Policies > Security Options > "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing") forces Windows to reject non-FIPS crypto. Known breakage includes older RDP clients, some VPN software (check vendor FIPS certification), .NET Framework applications using non-validated providers, and certain PowerShell scripts. Test FIPS mode in a lab environment before deployment. If third-party software does not support FIPS mode, evaluate whether the software is necessary for CUI processing or can be removed from the enclave. The "boogeyman" perception exists because legacy apps written before FIPS requirements may fail; modern enterprise software usually supports FIPS mode. Windows 11 and Server 2025 core components are FIPS 140-2 validated (check NIST's CMVP database for certificate numbers), but application compatibility is the real risk.
A mid-sized architecture and engineering firm questioned whether to keep the entire company in scope for Level 2. On Oct 9, a 200-person AE firm with >75% of employees touching DoD projects at some point reported that scoping the entire enterprise has "stifle[d] innovation and creativity" for employees who rarely handle CUI (source). The firm's C3PAO assessment is scheduled for next month. During the suspension, C3PAO assessments are voluntary; the assessment can proceed but will not generate an official Level 2 certification recognized in SAM.gov or contract awards (only self-attestation is allowed). If the firm proceeds anyway (some do for readiness or competitive signaling), the scope question remains: NIST 800-171 and CMMC require scoping the "CUI environment," not the entire company. The CUI environment includes systems that process, store, or transmit CUI and the boundary protections around them. Employees who never touch CUI and whose systems never connect to CUI networks can be excluded. If 25% of employees never access DoD projects and their workstations are on a separate network segment with no CUI data flow, carve them out. The firm's assumption that >75% touch a DoD project "at some point" suggests role-based access and project-based CUI handling, not blanket CUI access. Revisit the asset inventory and data flow map. Scope only the systems and users that handle CUI, then enforce boundary controls (separate VLANs, access controls, CUI labeling) to keep non-CUI users out of the environment. This reduces cost and friction. If the C3PAO disagrees, document the rationale and challenge it. The "whole company" approach is often a CYA move by assessors or consultants who don't want to map data flows; it is not a regulatory requirement.
On Oct 11, a brief post asked about RMM tools (Ninja One vs. N-Able N-central) for CMMC environments (source). NIST 800-171 does not specify RMM vendors; it requires control over remote access (3.1.12), audit logging (3.3.1-3.3.9), and configuration management (3.4.1-3.4.9). Both Ninja and N-Able can support these controls if configured correctly. Key questions: Does the RMM vendor's cloud backend meet FedRAMP Moderate or equivalent? Does the tool support FIPS-mode endpoints? Can you disable unattended access or require MFA for every session? Can you scope the tool to the CUI enclave only, or does it require agents on all corporate endpoints? Check the vendor's compliance documentation and ensure the RMM's data-at-rest and data-in-transit encryption meets 800-171 3.13.11 and 3.13.8. Do not assume "CMMC-ready" marketing means compliant; verify specific controls.
Federal PQC migration deadlines will eventually affect DIB contractors through updated cryptographic requirements. On Oct 9, CISA's quantum security lead told an AFCEA audience that civilian agencies are behind on post-quantum cryptography inventories and lack budget for the 2030 transition (source). OMB's June guidance (not linked) set a phased approach: 2026-2027 for inventory and planning, 2027-2028 for pilots and early migrations. Agencies submitted initial plans to OMB and the Office of the National Cyber Director by end of October (this deadline just passed). DoD's PQC director noted that mission-system prioritization is complex; different organizations within DoD have different urgencies. CISA's lead criticized current cryptographic asset inventories as "clunky" spreadsheet exercises treated as compliance checkboxes rather than true visibility.
For DIB contractors: NIST 800-171 control 3.13.11 requires identifying and documenting cryptographic mechanisms. When NIST finalizes post-quantum algorithms (FIPS 203, 204, 205 standards are published; agencies are now planning migrations), expect NIST 800-171 Revision 3 or a future update to reference quantum-resistant cryptography. This will eventually flow into DFARS 7012 and CMMC requirements. Contractors handling CUI should start inventorying where cryptographic keys are used (VPNs, TLS certificates, encrypted storage, code-signing, PIV/CAC card authentication) and identify systems that will need PQC-compatible replacements. The 2030 deadline is federal; DIB timelines will lag, but planning now avoids scrambling when NIST updates the standard. Watch NIST's National Cybersecurity Center of Excellence (NCCoE) PQC migration guidance for implementation playbooks. If your SSP's cryptographic inventory is incomplete, update it before the next assessment cycle.