A technical guide for cybersecurity and compliance professionals in the Defense Industrial Base
For defense manufacturers, CMMC readiness is no longer just about having MFA or written policies. It is about proving that every user is verified, every access path to FCI/CUI is controlled, and every critical action is logged. The biggest risk is usually not the cloud apps that are already protected by SSO, it is legacy systems, shop-floor workstations, VPN/RDP/SSH access, shared accounts, and privileged workflows where identity controls are inconsistent, password-dependent, or hard to prove.
What Is CMMC, and How Did We Get Here?
If you work in cybersecurity or compliance at a defense or aerospace contractor, CMMC is no longer a future concern – it is an active requirement shaping which organizations can bid on Department of Defense contracts today.
The Cybersecurity Maturity Model Certification (CMMC) is the DoD’s mandatory framework for verifying that contractors and subcontractors have the cybersecurity controls in place to protect sensitive federal information. Its core premise is straightforward: the DoD needs assurance that the companies it works with are actually protecting the data they handle – not just claiming to.
The origins of CMMC trace back to 2016, when the DoD amended the Defense Federal Acquisition Regulation Supplement (DFARS) to require contractors to protect Covered Defense Information (CDI) and comply with NIST SP 800-171. That framework relied entirely on self-attestation – contractors assessed themselves and reported their own compliance scores to the DoD’s Supplier Performance Risk System (SPRS). The results were predictable: research consistently showed that the gap between perceived and actual compliance was enormous, with one CyberSheath study finding that only 4% of contractors were actually prepared for formal assessment while 75% believed they were compliant.
The DoD’s response was CMMC, first introduced in 2020 as a five-level model (CMMC 1.0). After significant feedback from the Defense Industrial Base (DIB), the DoD revised the framework in 2021 into the three-level CMMC 2.0 – streamlined, directly aligned to established NIST standards, and formally codified in regulation. The final policy rule (32 CFR Part 170) took effect in December 2024. The final acquisition rule (48 CFR) was published September 10, 2025, and enforcement began November 10, 2025. Phase 1 is now live.
The defining change from the DFARS era: CMMC requires verified compliance, not just claimed compliance. Third-party certification, not self-attestation, is now the standard for most CUI-handling contractors.
Key Control Areas
CMMC 2.0 organizes its requirements into 14 control domains drawn directly from NIST SP 800-171. Each domain addresses a distinct aspect of cybersecurity hygiene. Understanding the full landscape helps compliance teams scope their programs correctly and prioritize effort.
Table 1
CMMC 2.0 — The 14 control domains
|
AC
Access Control Covers who can reach what. Governs user account management, least-privilege principles, remote access policies, and the boundaries around systems that handle sensitive information. Access control gaps — over-privileged accounts, shared credentials, uncontrolled remote access — are among the most common findings in formal assessments. |
IA
Identification & Authentication Determines how users prove who they are before gaining access. Includes password policies, multi-factor authentication, and replay-resistant authentication mechanisms. The domain at the center of this post, and one of the most heavily scrutinized during C3PAO assessments. |
|
AU
Audit & Accountability Requires that all significant system events — logins, access to CUI, configuration changes — are logged, protected, and reviewed. Audit logs are the evidence trail that makes other controls verifiable. |
CM
Configuration Management Governs baseline configurations for systems, software, and devices. Includes patch management, change control, and restrictions on user-installed software. |
|
IR
Incident Response Requires documented and tested plans for detecting, containing, reporting, and recovering from cybersecurity incidents. |
SC
System & Communications Protection Covers network architecture, segmentation, encryption in transit, and controls at system boundaries. This is where CUI system segmentation strategy is defined and documented. |
|
SI
System & Information Integrity Malware protection, security alerting, flaw remediation, and endpoint monitoring — the operational layer that detects and responds to threats in real time. |
+7
Remaining domains Risk Assessment (RA), Security Assessment (CA), Awareness & Training (AT), Maintenance (MA), Media Protection (MP), Personnel Security (PS), and Physical Protection (PE) round out the framework — together ensuring cybersecurity is embedded in organizational operations rather than treated as a standalone IT concern. |
For Level 2 compliance, all 110 requirements across these 14 domains must be implemented, documented in a System Security Plan (SSP), and verifiable by an assessor. Incomplete implementation is not a minor issue – each unimplemented high-weight control (like MFA, which carries a 5-point value) directly degrades your SPRS score and can derail a formal assessment.
The Three Levels: Foundational, Advanced, and Expert
CMMC’s three levels are cumulative – each builds on the requirements of the level below – and they are tied to the type and sensitivity of information a contractor handles. The level required in a contract is not chosen by the contractor; it is determined by the DoD program manager overseeing the acquisition, based on a formal assessment of what information the contractor will access.
Table 2
CMMC 2.0 — Levels, requirements, and assessment cadence
| Level | Requirements | Assessment |
|---|---|---|
|
Level 3
Expert |
134requirements
110 from NIST SP 800-171 R2 + 24 from NIST SP 800-172. |
|
|
Level 2
Advanced |
110requirements
Aligned with NIST SP 800-171 R2. |
|
|
Level 1
Foundational |
17requirements
Aligned with FAR clause 52.204-21. |
|
Level 1 – Foundational
Level 1 applies to organizations that handle Federal Contract Information (FCI) – non-public information generated under a government contract, such as delivery schedules, pricing, and contract terms – but do not handle Controlled Unclassified Information (CUI). Approximately 63% of DIB contractors fall into this category.
Level 1 requires implementation of 17 practices drawn from FAR 52.204-21. These are basic cyber hygiene measures: access controls, user identification, malware protection, media sanitization, physical security, and system integrity. The assessment mechanism is an annual self-assessment, affirmed by a senior company official, with results submitted to the SPRS database.
Level 2 – Advanced
Level 2 applies to organizations handling Controlled Unclassified Information (CUI) – sensitive but unclassified information such as technical drawings, engineering specifications, and program details that could affect national security if exposed. This level covers the majority of meaningful DoD supply chain work and applies to approximately 80,000 organizations in the DIB.
Level 2 requires implementation of all 110 security controls from NIST SP 800-171 Rev. 2, organized across the 14 domains described above. For most contracts, compliance must be verified by a Certified Third-Party Assessment Organization (C3PAO) every three years, with annual affirmations by a senior official in the intervening years. For lower-risk acquisitions, a self-assessment may be accepted, but C3PAO certification is becoming the standard expectation.
Level 2 is where the compliance burden becomes substantial. A formal C3PAO assessment requires not just implementation of controls, but documented, auditable evidence that those controls operate in day-to-day practice. The difference between, for example, having MFA deployed and being able to demonstrate to an assessor that MFA is enforced for all relevant accounts is significant – and organizations that conflate the two tend to be surprised during assessment.
Level 3 – Expert
Level 3 applies to a small subset of contractors – fewer than 5% – who work on the DoD’s most sensitive and strategically critical programs, where advanced persistent threats (APTs) from nation-state actors represent a realistic and targeted risk.
Level 3 requires all 110 Level 2 controls plus a DoD-selected subset of 24 enhanced requirements from NIST SP 800-172, for a total of 134 controls. These additions focus specifically on APT resilience: continuous system monitoring, proactive threat hunting, supply chain risk management, strengthened identity controls including dual authorization, and advanced incident response capabilities. Achieving Level 3 requires a government-led assessment by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) every three years – and a passing Level 2 C3PAO certification is a prerequisite before a DIBCAC assessment can begin.
Who Decides the Required Level?
The level specified in a contract solicitation is not negotiable and is not chosen by the contractor. DoD program managers are responsible for evaluating each acquisition and determining the appropriate CMMC level based on the type of information involved, the mission sensitivity, and threat profile. The requirement is written into solicitation language via DFARS clause 252.204-7021. If that clause appears in a contract you are pursuing, the specified level is the threshold for bid eligibility – no certification means no award.
Authentication, Access Control, and Auditability: The Identity Triad
While CMMC’s 14 control domains each address important aspects of cybersecurity, three of them are particularly tightly coupled when it comes to protecting against identity-based attacks: Identification and Authentication (IA), Access Control (AC), and Audit and Accountability (AU). Taken together, they form a mutually reinforcing defense – IA authenticates the user, AC determines what that user can reach, and AU records everything they do. Weakness in any one of the three undermines the others.
Identity Is the Primary Attack Vector
Defense contractors are high-value targets. State-sponsored threat actors – particularly those associated with China, Russia, Iran, and North Korea – systematically target the DIB to exfiltrate technical data, intellectual property, and program information. Their primary method is not brute-force exploitation of technical vulnerabilities. It is credential compromise – specifically, phishing and social engineering attacks designed to steal usernames and passwords.
Phishing campaigns targeting defense companies have grown significantly more sophisticated. Modern attacks impersonate DoD portals, cleared facility access systems, Microsoft 365 login pages, and supplier onboarding platforms. Spear-phishing campaigns targeting specific individuals – a contracts manager, a cleared engineer – use publicly available information to craft convincing pretexts. Once a credential is captured, an attacker operating with a legitimate username and password is effectively invisible to systems that rely on passwords alone.
The numbers are stark: the CyberSheath 2025 State of the DIB Report found that only 27% of defense contractors have implemented MFA, despite it being a clear NIST 800-171 requirement since 2017. That means nearly three-quarters of the DIB remains vulnerable to a category of attack that MFA is explicitly designed to defeat.
But MFA alone is not sufficient. An attacker who compromises valid credentials and bypasses MFA through a phishing proxy still has to go somewhere – and what they can reach, and whether anyone notices, depends entirely on how well Access Control and Audit and Accountability are implemented alongside authentication.
Level 1: The Baseline Across All Three Domains
At Level 1, the requirements across the identity triad are foundational but meaningful.
Identification and Authentication at Level 1 does not require MFA, but it does require that organizations verify the identities of users and devices before granting access. This means enforcing password practices that prevent default or easily guessable credentials, and ensuring every account is tied to a specific, accountable individual.
Access Control at Level 1 introduces several baseline requirements that directly relate to identity risk. Contractors must limit system access to authorized users and the transactions they are permitted to perform. Critically for identity security, Level 1 prohibits the routine use of shared accounts – a pervasive problem in small and mid-size DIB organizations where team members frequently share login credentials for convenience. Each user must have a unique, identifiable account. Remote access – where credential theft most often translates into unauthorized entry – must be managed and controlled. Access by external users must be authorized before it is granted.
Audit and Accountability at Level 1 requires that system access and activity can be traced to individual users. While the logging requirements at this level are basic compared to Level 2, the principle is the same: if an account is compromised and used maliciously, you must be able to determine what happened.
Together, these Level 1 requirements ensure that even contractors handling only FCI have a credible baseline: known users, unique credentials, controlled remote access, and a minimal audit trail.
Level 2: The Full Identity Triad Becomes Mandatory
Level 2 is where all three domains sharpen considerably and the requirements become specific, verifiable, and heavily weighted in assessment.
Identification and Authentication (IA) – MFA Is Non-Negotiable
The controlling standard is IA.L2-3.5.3 from NIST SP 800-171:
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
This means MFA is required for:
- All privileged accounts (domain administrators, IT staff, anyone with elevated access) – for both local and network access
- All standard user accounts – for network access, including remote access via VPN, cloud platforms, and remote desktop
- All cloud services that touch CUI environments – Microsoft 365, AWS, Azure, and similar platforms
MFA at Level 2 must also be replay-resistant (IA.L2-3.5.4). This requirement rules out authentication methods that can be captured and replayed by an attacker – which includes SMS-based one-time codes, which are vulnerable to SIM-swapping and SS7 protocol attacks. While SMS-based MFA is widely deployed and is better than no MFA, it does not satisfy the replay-resistance requirement on its own. Authenticator apps, hardware tokens, and FIDO2/WebAuthn keys all meet the standard.
Level 2 also includes password-specific controls:
- IA.L2-3.5.7: Enforce password complexity
- IA.L2-3.5.9: Require changing temporary passwords after first use
- IA.L2-3.5.10: Prohibit password reuse within a defined history
MFA carries a 5-point weight in the NIST 800-171 assessment methodology – among the highest of any individual control. Failing to implement it fully is not a minor finding.
Access Control (AC) – Containing What a Compromised Identity Can Reach
Even with MFA in place, Access Control determines what damage a compromised account can actually do. Level 2 AC requirements directly address the remote access and shared-account risks that are most commonly exploited in identity attacks.
Remote access is a primary attack surface for credential theft. AC.L2-3.1.12 requires that all remote access sessions are monitored and controlled. AC.L2-3.1.14 mandates that remote access is routed through managed access control points – preventing ad hoc, unmonitored remote connections. AC.L2-3.1.13 prohibits split tunneling unless explicitly authorized, closing the gap where a remote user might simultaneously access the internet and the CUI environment without all traffic flowing through enterprise controls.
Shared accounts are effectively prohibited at Level 2. AC.L2-3.1.1 requires that system access be limited to authorized users and to transactions and functions each user is authorized to perform. Account sharing destroys accountability – if five engineers share a login, there is no way to trace an intrusion to a specific compromised credential, no way to scope the incident, and no way to pass an assessment that requires demonstrating user-level accountability.
Least privilege is another core AC requirement at Level 2. AC.L2-3.1.5 mandates that users operate with only the minimum permissions necessary to perform their functions. AC.L2-3.1.6 requires that privileged accounts not be used for non-administrative tasks. These controls limit lateral movement – the ability of an attacker who compromises a standard user account to escalate privileges and access more sensitive systems.
Wireless access must be explicitly authorized before it is permitted (AC.L2-3.1.16), and mobile device connections must be controlled (AC.L2-3.1.18). Any network that carries CUI requires enterprise-grade authentication – consumer-grade shared WiFi passwords do not meet this standard.
Audit and Accountability (AU) – Detecting What You Cannot Prevent
The AU domain provides the detection and forensic capability that makes the other two domains meaningful. Even a well-configured identity and access control environment will occasionally be breached – and without audit logs, there is no way to know when, by whom, or how far an attacker got.
Level 2 requires comprehensive audit logging under AU.L2-3.3.1: the creation, modification, and deletion of accounts; successful and failed login attempts; changes to authentication configurations; and access to CUI. Audit records must capture enough detail – who, what, when, from where – to reconstruct an incident.
Login failure monitoring is a direct identity-threat detection capability. Repeated failed authentication attempts – especially against privileged accounts – are a strong indicator of a credential-stuffing or brute-force attack in progress. CMMC requires that these events are logged, reviewed, and acted upon.
Critically, audit logs themselves must be protected from modification or deletion (AU.L2-3.3.2). An attacker who compromises an account and also has the ability to delete or modify logs can erase their tracks – rendering the entire audit capability useless. Log integrity must be technically enforced, not just policy-mandated.
AU.L2-3.3.5 requires that audit processes and audit tools are protected. AU.L2-3.3.6 requires the ability to reduce and review audit records – in practice, this means having a log management capability (SIEM or equivalent) that can surface relevant events without requiring security staff to manually review raw logs.
The connection to incident response is direct: audit logs are the primary evidence source for CMMC’s incident response requirements. An organization that cannot produce audit trail evidence during a C3PAO assessment will find itself unable to demonstrate multiple controls simultaneously.
MFA implementation at Level 2 must be documented in your System Security Plan (SSP) – as must AC and AU configurations. Assessors will want to see not just that these controls are deployed, but that they cover all required accounts and access paths, are technically enforced, and have been tested.
Level 3: Phishing-Resistant Authentication and Advanced Identity Controls
Level 3 tightens all three domains further, specifically targeting the risk posed by sophisticated nation-state actors who have the capability to defeat standard Level 2 controls.
Identification and Authentication – Eliminating the Human in the Loop
Standard MFA methods – including authenticator app codes – can be defeated by real-time phishing proxies. In a sophisticated attack, a threat actor can stand up a proxy site that captures both a user’s password and their one-time MFA code in real time, using them immediately before they expire. Level 3 addresses this by requiring phishing-resistant authentication, which removes the human-relayed secret from the authentication flow entirely.
FIDO2 / WebAuthn: Authentication uses a cryptographic key pair bound to a specific domain. The private key never leaves the user’s device, and authentication is cryptographically tied to the correct origin URL – making it impossible for a proxy site to capture and replay. Hardware security keys (YubiKey, Google Titan) and device-bound passkeys (Windows Hello, Apple Face ID/Touch ID) both implement FIDO2.
PIV / Smart Card authentication: Public Key Infrastructure (PKI)-based smart cards, including the DoD’s own Common Access Card (CAC), use certificate-based authentication that is similarly phishing-resistant. For contractors already operating in cleared environments, smart card infrastructure may already be partially in place.
Access Control – Dual Authorization and Tighter Boundaries
At Level 3, the AC domain introduces dual authorization requirements for high-risk operations. Certain sensitive actions – such as modifying security configurations, exporting large volumes of CUI, or making privileged system changes – must require two separately authenticated and authorized individuals to approve and execute them. This addresses both external compromise (a single captured credential cannot complete the action alone) and insider threat scenarios.
Access control boundaries are also tightened at Level 3 to assume that external networks are hostile. Network architectures must enforce strict segmentation around the most sensitive CUI, and access policy must reflect a zero-trust posture for the highest-risk systems.
Audit and Accountability – From Logging to Active Monitoring
At Level 3, the AU requirements evolve from passive logging to active, continuous monitoring. It is not sufficient to have logs that could be reviewed after an incident – the organization must have the capability to detect and respond to anomalies in near-real time.
This means having a functioning Security Operations Center capability (whether in-house or managed), with alerting on authentication anomalies: unusual login times, access from unexpected geographies, privilege escalation events, and high-volume data access patterns that could indicate exfiltration in progress. The integration of identity data with security monitoring is fundamental at Level 3 – audit logs become an active threat detection feed, not just a forensic archive.
The practical implication for organizations pursuing Level 3: evaluate phishing resistant authentication deployment across your authentication infrastructure, implement a mature SIEM or managed SOC with identity-specific alerting, and ensure your AC policies explicitly address dual authorization for your highest-sensitivity operations.
Implementation Timeline: Phases, Milestones, and Accountability
Understanding the rollout structure is critical for compliance planning. The DoD is not implementing CMMC all at once – it is following a four-phase schedule designed to give the DIB time to prepare, while progressively tightening requirements.
Table 3
CMMC 2.0 — Phased rollout schedule
| Phase 1Self-assessment | Phase 2Level 2 certification | Phase 3Level 3 certification | Phase 4Full implementation |
|---|---|---|---|
| Begins10 Nov 2025 | Begins10 Nov 2026 | Begins10 Nov 2027 | Begins10 Nov 2028 |
Contract requirement
|
Contract requirement
|
Contract requirement
|
Contract requirement
|
Phase 1 – Now (November 10, 2025 onward)
Phase 1 is live. New DoD solicitations now include CMMC requirements. Most contracts specify Level 1 or Level 2 self-assessments as a condition of award. During Phase 1, the DoD also has discretion to require C3PAO third-party assessments for high-priority acquisitions.
Who is responsible: Organizations self-assess their compliance, submit scores to SPRS, and have a senior company official provide a formal affirmation. For contracts that specify a C3PAO assessment, the organization engages a CyberAB-authorized C3PAO independently.
What this means now: If you are bidding on new DoD contracts, you need a current CMMC status. “We are working on compliance” is not a valid response to a contract solicitation that requires a certification at award.
Phase 2 – November 10, 2026
One year after Phase 1, mandatory Level 2 C3PAO third-party assessments become standard for contracts involving CUI. Self-assessment is no longer sufficient for most Level 2 requirements. The clock is running – C3PAO schedules are already experiencing backlogs, and organizations that begin preparation in late 2026 will be competing for assessment slots with thousands of other contractors.
Who is responsible: Organizations must engage a CyberAB-authorized C3PAO. The C3PAO conducts a formal, evidence-based assessment and submits results to the CMMC database (eMASS). Contracting officers verify CMMC status as a condition of award.
Preparation timeline: Most organizations in a mature but partially compliant state need 6–12 months to prepare for a formal C3PAO assessment. Organizations starting from an immature posture should plan for 12–18 months. That means serious preparation needs to begin now.
Phase 3 – November 10, 2027
Level 3 DIBCAC assessments begin for contracts identified as requiring expert-level certification. Level 2 C3PAO requirements expand to cover more contract types, including option periods on existing contracts.
Who is responsible: Level 3 assessment is conducted by DCMA’s Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) – a government-led, not third-party, process. Organizations must already hold a valid Level 2 C3PAO certification before a DIBCAC assessment can be scheduled.
Phase 4 – November 10, 2028
Full implementation. All applicable DoD contracts and solicitations include CMMC requirements. No grace periods, no exceptions for existing contracts at renewal. Organizations that have not achieved the required certification level are not eligible to bid or to exercise contract options.
A note on continuous compliance: CMMC certification is not a one-time achievement. Level 2 certifications are valid for three years, but organizations must provide annual affirmations from senior officials confirming continued compliance. Any system changes that affect the CUI environment must be evaluated for their impact on certification status. Compliance is an operational practice, not a project with a finish line.
Call to Action: Start Now, Start with Identity
The organizations that will navigate CMMC successfully are those that treat it as a program, not a project – a sustained operational commitment to maintaining the controls, documentation, and culture that certification requires.
For cybersecurity and compliance teams at defense and aerospace contractors, the priorities are clear.
Start with a gap assessment. Map your current security posture against NIST SP 800-171 Rev. 2. Identify which of the 110 controls are fully implemented, partially implemented, or not in place. Document your findings honestly. An SPRS score that overstates your compliance creates legal exposure – the False Claims Act has been applied to contractors who misrepresented their cybersecurity posture to obtain government contracts.
Determine your required level. Review your current and anticipated contracts for DFARS clause 252.204-7021. Talk to your prime contractors if you are a subcontractor – CMMC requirements flow down, and 47% of contractors have already received flow-down requests. If your contract involves CUI, assume Level 2.
Get your SSP and POA&M in order. Your System Security Plan is the documentation backbone of your compliance program. Every control must be documented – not just implemented. Your Plan of Action and Milestones must be specific, dated, and actively maintained.
Prioritize the identity triad – IA, AC, and AU – together. Of all the control areas in CMMC 2.0, these three have the most direct bearing on the attack vectors actively targeting defense contractors today. They are also among the most commonly deficient and the most heavily weighted in assessment.
For authentication (IA):
- Enforce MFA on all cloud platforms (Microsoft 365, Google Workspace, AWS, Azure) that touch or support CUI environments – immediately
- Enforce MFA on all on-prem applications and legacy systems.
- Deploy MFA for all VPN, remote desktop, and privileged access pathways
- Move away from SMS-based OTP toward TOTP authenticator apps or hardware tokens to satisfy replay-resistance requirements
- Evaluate phishing-resistant authentication deployment for privileged accounts and high-sensitivity users
- Document all MFA configurations in your SSP with evidence of technical enforcement
- Train employees on MFA use, including recovery procedures, to prevent lockouts and workarounds
For access control (AC):
- Eliminate shared accounts – every user must have a unique, accountable identity
- Audit remote access paths: VPN, RDP, and cloud access must all route through managed, monitored control points
- Enforce least privilege across all accounts; privileged accounts must not be used for day-to-day non-admin work
- Ensure wireless networks carrying CUI use WPA2-Enterprise or equivalent, not shared-key authentication
For audit and accountability (AU):
- Verify that login success and failure events are captured for all systems in scope – including legacy apps and cloud platforms
- Ensure logs are protected from modification or deletion – log integrity is a technical requirement, not a policy one
- Implement a log aggregation and review capability (SIEM or equivalent) that can surface authentication anomalies
- Test your ability to reconstruct a login event from logs – if you cannot trace a specific user’s access to a specific system at a specific time, your AU implementation is incomplete for assessment purposes
Get on a C3PAO schedule. If you handle CUI and will be subject to Phase 2 requirements, begin engaging authorized C3PAOs now. Assessment slots for late 2026 will fill up. Organizations that delay will face a choice between a last-minute scramble or sitting out of contract competitions.
Understand the consequences of non-compliance. Without the required CMMC certification at the time of contract award, an organization cannot bid. This is not a penalty – it is a hard eligibility threshold. Existing contract holders who fail to maintain their certification risk losing the ability to exercise option periods. Subcontractors who cannot demonstrate compliance will be replaced by primes who need to protect their own certification status. The DoD has been explicit: national security concerns make delay unacceptable, and no broad grace period extensions are planned.
See how ZeroPassword™ helps turn IA, AC, and AU from a risk into audit-ready identity control
Useful Resources
The following official and authoritative sources are essential references for any CMMC compliance program.
Department of Defense – CMMC Program
- CMMC Program overview and official documentation
- CMMC model documentation (32 CFR Part 170)
- DFARS clause 252.204-7021 (contract language)
NIST – Core Standards
- NIST SP 800-171 Rev. 2 (the Level 2 control set)
- NIST SP 800-171A (assessment procedures for 800-171)
- NIST SP 800-172 (enhanced requirements for Level 3)
- NIST SP 800-63B (digital identity and authentication guidelines)
CyberAB – Assessors and Marketplace
- CyberAB (CMMC Accreditation Body) – find authorized C3PAOs and RPOs
- CMMC Marketplace (search certified assessors)
DoD SPRS – Compliance Reporting
- Supplier Performance Risk System (submit self-assessment scores)
Additional Guidance
- NIST Cybersecurity Framework (supplemental)
This post reflects the CMMC regulatory framework as of May 2026. Compliance requirements are evolving – you should verify current requirements against official DoD and NIST sources and consult with a qualified CMMC Registered Practitioner Organization (RPO) or C3PAO for assessment-specific guidance.