US defense suppliers may have established access controls, configuration management, vulnerability scanning and incident-response processes through CMMC and DFARS work. Some of that work can support EU Cyber Resilience Act (CRA) preparation when it covers the development or support of a commercial product sold in the EU.
The scope matters. CMMC concerns the protection of specified government information in contractor systems. A CRA assessment concerns the product with digital elements and the manufacturer’s relevant processes. The evidence must be connected to the product before it can support a CRA conclusion.
First check the defense exclusion
CRA Article 2(7) excludes products developed or modified exclusively for national security or defense purposes, and products specifically designed to process classified information.
Selling to a defense customer does not by itself establish that exclusion. A commercial product also sold into civilian markets needs its own scope assessment. Record the actual product, intended purpose and any dedicated variant. Check the remaining Article 2 conditions and exclusions before undertaking the mapping below.
This guide is intended for suppliers whose commercial products are in CRA scope. It does not determine export-control permissions or authorize sharing controlled information with an EU customer or conformity-assessment body.
Current CMMC status and the edition used here
Status reviewed October 1, 2026: a July 13, 2026 memorandum from the Under Secretary of War for Acquisition and Sustainment implements the Department of War CIO’s pause of the CMMC rollout and suspension of Phase 2, pending a CIO review. Its Attachment 1, pages 1–2 limits the designations in procurement requirements during the suspension to Level 1 (Self) and Level 2 (Self), retains select government-led assessments, and states that DFARS 252.204-7012 requirements remain in effect. It also says further guidance will follow the conclusion of the CIO’s 60-day review. When this guide was reviewed, the CIO’s CMMC page showed no later guidance. This is an interim position: recheck current official notices before relying on it.
It also directs amendments to active solicitations containing Level 2 (C3PAO) or Level 3 (DIBCAC) requirements. Existing contracts containing those requirements are to be modified before the next option period or during the next scheduled administrative modification. Confirm the actual solicitation or contract change with the contracting officer. Do not assume that an unchanged contract document has already been amended.
Attachment 1 distinguishes Level 1’s FAR 52.204-21 basic safeguarding requirements for Federal Contract Information from Level 2’s NIST SP 800-171 Revision 2 requirements for Controlled Unclassified Information. The control references below use Revision 2. NIST’s publication record marks that edition withdrawn and superseded by Revision 3, but the July memo expressly retains Revision 2 for this CMMC context. A newer NIST publication does not automatically change the edition incorporated into a contract.
Establish what the existing evidence covers
Start with the system boundary and the product’s development and support environments. Under NIST SP 800-171 Rev. 2, requirement 3.12.4, the system security plan describes the boundary, operating environment, implementation of requirements and connections with other systems.
Determine whether the product’s repositories, build services, release systems and vulnerability-handling tools fall within that boundary. An assessment of a separate contract-administration environment provides little evidence about the product’s development. Equally, a development environment within the boundary still needs records demonstrating the product’s own security behavior.
Where the evidence may help
All US requirement numbers in this table refer to NIST SP 800-171 Revision 2, section 3. The proposed reuse is conditional on the records covering the relevant product work. Similar control names are insufficient to establish equivalent coverage.
| Existing requirement and evidence | Possible contribution to CRA work | Limitation to address |
|---|---|---|
| 3.4.1 and 3.4.3: baseline configurations, inventories and change-control records | Annex VII(2): understanding development and production, and tracing relevant product changes | An organizational system inventory does not necessarily identify the shipped product’s software dependencies. Check the product SBOM separately under Annex I Part II(1). |
| 3.11.1: periodic risk assessments | Article 13(2)–(4): an established assessment method and relevant development-environment risks | The NIST requirement addresses organizational operations, assets, individuals and CUI processing. Extend the assessment to the product’s intended and foreseeable use, users and applicable Annex I requirements. |
| 3.11.2 and 3.14.1: vulnerability scans and flaw-remediation records | Annex I Part II(2)–(3): relevant findings and remediation or testing evidence, where the actual product is covered | Scanning internal endpoints does not demonstrate product testing, field remediation or secure delivery of updates to users. |
| 3.6.1: operational incident-handling capability | Article 14: personnel, investigation and escalation capabilities that can support reporting | Add the CRA triggers, recipients, platform and deadlines. The NIST capability does not specify them. |
| 3.12.4: documented system boundaries and connections | Annex VII(2): relevant development and support environment documentation | Prepare the product description, architecture, vulnerability-handling information, risk assessment and test evidence that Annex VII separately requires. |
For secure-development tasks and product-level records, the SSDF guide provides a closer mapping. Using both sets of evidence can help identify which processes already operate and where product engineering or documentation work remains.
DFARS and Cyber Resilience Act reporting run on different triggers
DFARS 252.204-7012(c)(1) addresses discovery of a cyber incident affecting a covered contractor information system, the covered defense information residing in it, or the ability to provide designated operationally critical support. Paragraph (a) defines rapid reporting as within 72 hours of discovery. Apply the clause and reporting arrangements incorporated into the contract.
CRA Article 14 concerns the manufacturer’s awareness of actively exploited vulnerabilities contained in the product and severe incidents impacting its security. The two timelines must be assessed independently:
| CRA event | Initial stages | Final report, unless the relevant information has already been provided |
|---|---|---|
| Actively exploited vulnerability, Article 14(1)–(2) | Without undue delay: early warning within 24 hours of awareness; vulnerability notification within 72 hours, unless the relevant information has already been provided | No later than 14 days after a corrective or mitigating measure is available |
| Severe incident, Article 14(3)–(5) | Without undue delay: early warning within 24 hours of awareness; incident notification within 72 hours, unless the relevant information has already been provided | Within one month after the incident notification |
CRA notifications go through the Single Reporting Platform to the CSIRT designated as coordinator and ENISA. Article 14(7) determines the Member State, including an ordered set of criteria for manufacturers without an EU main establishment. Article 14(8) separately covers information to impacted users and, where appropriate, all users. A DFARS report does not submit any of those CRA notifications.
CRA reporting has applied since September 11, 2026, under Article 71. Article 69(3) also applies it to in-scope products placed on the market before December 11, 2027.
Keep product obligations visible in the gap assessment
The remaining CRA work can include secure product defaults and update behavior, component due diligence, the SBOM, coordinated vulnerability disclosure and a support period based on expected use. Review Article 13 and Annex I against the actual product.
Conformity preparation also requires product classification, the applicable Article 32 procedure, technical documentation, the EU declaration of conformity and CE marking. CMMC assessment results do not determine the CRA product category or perform that conformity procedure.
A practical starting package
For a supplier selling a commercial network product to both US defense and EU customers, start with the relevant system boundary, product release records, security tests and vulnerability-handling records. Identify which CMMC evidence actually covers the product’s engineering and support. Maintain a separate assessment of each reporting obligation when a security event occurs.
This is an implementation example based on NIST SP 800-171, DFARS 252.204-7012 and CRA Articles 13–14 and Annex VII. The CRA does not mandate this package or review format. Existing information-handling and disclosure restrictions still apply to the records.
In the regulation
Related guides
- US Federal Software and IoT Procurement Evidence for the EU Cyber Resilience Act Use evidence from US federal software and IoT contracts for the EU Cyber Resilience Act, with current OMB policy, NIST guidance and product gap checks.
- From NIST SSDF to EU Cyber Resilience Act Compliance Use your NIST SSDF practices and evidence to prepare for EU Cyber Resilience Act compliance. Identify reusable work, product-specific gaps and remaining obligations.
Sources
- Defense CIO, current CMMC program notices
- Implementing suspension of CMMC Phase II, memorandum of July 13, 2026, Attachment 1
- DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting
- NIST SP 800-171 Revision 2, February 2020, updated January 2021 (edition used by the cited CMMC memo)
- NIST SP 800-171 Revision 2, publication and supersession record
- Regulation (EU) 2024/2847, Cyber Resilience Act