On July 13, 2026, the Department of War (DoD) suspended the transition to CMMC Phase 2, the milestone that would have made Level 2 certification by a third-party assessment organization (C3PAO) a condition of award for most contracts involving Controlled Unclassified Information beginning November 10, 2026. Phases 3 and 4 were frozen with it, and a CMMC Reform Task Force was stood up to review the program. In September, a DFARS class deviation made the suspension binding on contracting officers.
Headlines compressed that into “CMMC is paused.” The more accurate version: third-party verification is paused. The security requirements, and your obligation to attest to them, are not.
That distinction matters whether your organization is still pursuing C3PAO certification (many are, and many primes still require it of their suppliers) or relying on self-assessment for now. Either way, the same 110 NIST SP 800-171 requirements apply to every system in your CUI boundary, and your organization signs for them.
What Is Still in Force Today
- DFARS 252.204-7021 in new contracts. Phase 1 of the CMMC rollout began November 10, 2025. Since then, applicable new DoD solicitations and contracts involving CUI have included DFARS 252.204-7021 and 252.204-7025, making a current CMMC Level 2 status (self-assessed, unless the contract or a prime requires more) a condition of award.
- DFARS 252.204-7012. The obligation to safeguard covered defense information using NIST SP 800-171 has been in contracts since 2017 and is unchanged.
- Self-assessment and SPRS. Contractors must assess against all 110 requirements and post their score to the Supplier Performance Risk System. CMMC Level 2 (Self) requires a minimum score of 88 out of 110.
- Annual affirmation. A senior official at your company affirms continuing compliance every year. That applies whether you hold a C3PAO certificate or a self-assessment.
- Government-led assessments. During the suspension, DoD has said it will enforce NIST SP 800-171 through self-assessments and select government-led assessments.
Why the Suspension Raises the Stakes for Self-Attestation
With no third-party assessor in the loop, your organization’s own signature carries the full weight of verification, and the Department of Justice is enforcing it.
In September 2026, a major aerospace manufacturer agreed to pay $2.04 million to resolve False Claims Act allegations that it failed to meet NIST SP 800-171 requirements on a DoD contract. Two details stand out. The alleged failures involved a single network, not an enterprise-wide posture. And the conduct predated CMMC entirely; DOJ enforced the requirements through DFARS 252.204-7012 alone.
Earlier, in June 2026, LOGZONE, a Huntsville defense contractor, agreed to pay $507,144 to resolve similar allegations. It had self-reported a perfect SPRS score of 110. When the Defense Contract Management Agency’s DIBCAC assessed the company in 2024, the score came back at negative 170. SPRS scoring starts at 110 and subtracts 1, 3, or 5 points for each requirement not fully implemented, so scores can fall as low as negative 203. A negative 170 means the large majority of required controls were found not implemented, the opposite of what the company had reported.
The lesson for any contractor: one in-scope system that does not meet the requirements can undermine the accuracy of a score, and an affirmation, that covers everything.
Why Your Government Property System Is in Scope
Government property records tie specific items to specific contracts and programs: contract numbers, item identification data, acquisition costs, custodial and location history, and disposition records. For many programs, that information is CUI or travels with workflows that handle CUI. If your property system is inside your CUI boundary, every applicable NIST SP 800-171 requirement applies to it, including authentication and access control.
Four Gaps Standalone Authentication Creates
Gap 1: Multi-factor authentication
NIST SP 800-171 requirement 3.5.3 requires multi-factor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. Under the DoD Assessment Methodology used for SPRS scoring, MFA is a 5-point requirement, among the most heavily weighted of the 110. Partial implementation (MFA for remote and privileged access but not general users) still deducts 3 points, and the requirement must be met on every in-scope system.
Many organizations enforce MFA rigorously through their identity provider. But an application with its own standalone login sits outside that enforcement. Even where an application offers native MFA, it is a second policy to configure, maintain, and evidence, and in practice it is often left switched off.
Gap 2: Access that outlives employment
This is the gap we see most often. When an employee leaves, your IT or security team disables their network account, usually through your central identity provider. That does nothing to an account in a standalone application. Someone has to remember the person also had access to the property system and remove them there too. Too often, no one does, and former employees retain access to CUI long after they have left the company.
Several NIST SP 800-171 requirements speak directly to this:
- 3.1.1: Limit system access to authorized users.
- 3.5.6: Disable identifiers after a defined period of inactivity.
- 3.9.2: Ensure systems containing CUI are protected during and after personnel actions such as terminations and transfers.
An orphaned account belonging to a former employee is a straightforward finding under any of them, whether the assessor is a C3PAO, a government team, or your own staff completing the self-assessment.
Gap 3: Password and sign-in policies that drift
A standalone login means a second set of authentication rules, separate from your enterprise standard. NIST SP 800-171 requires password complexity and change rules (3.5.7), a prohibition on password reuse (3.5.8), immediate change of temporary passwords (3.5.9), cryptographically protected passwords (3.5.10), limits on unsuccessful logon attempts (3.1.8), and session lock and termination (3.1.10, 3.1.11).
Every one of those must be configured, maintained, and evidenced separately in a standalone application. When your security team tightens the enterprise standard, the standalone application does not follow unless someone updates it by hand. Over time, the two drift apart.
Gap 4: Sign-in activity outside your central monitoring
Your security team likely watches sign-in activity through your identity provider and central logging: failed attempts, unusual locations, access at odd hours. Requirements such as 3.3.1 (create and retain audit records), 3.3.5 (correlate audit review and analysis to investigate suspicious activity), and 3.14.7 (identify unauthorized use of organizational systems) depend on that visibility.
Sign-ins to a standalone application are recorded inside that application, not alongside the rest of your authentication activity. A suspicious login to your property system can go unnoticed simply because no one is looking there.
Why SSO Integration Is the Cleanest Fix
Single sign-on connects an application’s authentication to your enterprise identity provider using an industry-standard federation protocol, most commonly SAML 2.0 or OpenID Connect. Once integrated:
- MFA is enforced automatically. Every sign-in passes through your identity provider, so your existing MFA policy applies without separate configuration.
- Deprovisioning happens once. Disable the account centrally, and access to the integrated application ends with it. No second list to remember.
- One policy, one control. Password complexity, lockout, session rules, and conditional access are governed centrally, giving you one consistent authentication control across systems.
- Sign-ins are visible. Authentication events flow through your identity provider, where your security team already monitors them.
- Cleaner evidence. Your System Security Plan describes a single authentication architecture, which simplifies both your self-assessment and any certification or government assessment.
To be precise: CMMC does not name SSO as a requirement. It requires the NIST SP 800-171 controls above, met and verifiable on every in-scope system. SSO is simply the most direct way to bring an application under controls you have already built.
Where CMMC Goes From Here
The Task Force delivered its recommendations to the DoD CIO in September; as of late October 2026 they had not been published and no new Phase 2 date had been set. Possible outcomes range from a rescheduled Phase 2 to a narrower certification requirement to a longer reliance on self-assessment with government spot-checks. Structural changes to 32 CFR Part 170 or the DFARS clauses require rulemaking, which takes time.
History is instructive: the original CMMC program was paused for review in 2021 and returned as CMMC 2.0, streamlined but intact. Every plausible outcome still rests on NIST SP 800-171. It’s prudent for all contractors to continue work to close authentication and access gaps to comply with NIST SP 800-171.
Next Steps
If you manage government property in any system
Whatever system holds your government property records, sit down with your IT, information security, or CMMC compliance lead and ask four questions:
- Does the system enforce your organization’s multi-factor authentication?
- When an employee leaves, does disabling their central account end their access to it?
- Do its password, lockout, and session rules match your enterprise standard?
- Are its sign-in events part of your central monitoring?
If any answer is no, that system deserves a closer look before your next affirmation. We’re glad to talk through SSO and whether your present system supports CMMC compliance, whether or not it’s eQuip. For a broader look at where general-purpose tools fall short of NIST SP 800-171, see our article [Will Your Property Management System Survive a CMMC Assessment?].
Schedule a call to discuss SSO and CMMC compliance
If you’re an eQuip customer
eQuip was built for government property management and supports many NIST SP 800-171 requirements natively, including:
- Role-based access control and granular user permissions
- A system-enforced audit trail attributing changes to individual users
- Electronic approval chains supporting separation of duties
- Native multi-factor authentication
- Hosting in a government cloud environment with FIPS-validated cryptography
Authentication is the piece that depends on how your instance is configured. If your eQuip instance uses standalone authentication, it’s prudent to review it internally and talk with us to confirm your method of authentication into eQuip is compliant with CMMC. Schedule a 30-minute scoping call and include your IT, information security, or CMMC compliance lead. We’ll review your environment and identity provider and provide a firm fixed proposal for SSO integration.
Schedule your SSO scoping call
Primary Sources
- Department of War release, CMMC Phase II suspension (July 13, 2026): https://www.war.gov/News/Releases/Release/Article/4542329/forging-the-arsenal-of-freedom-department-of-war-suspends-cmmc-phase-ii-require/
- DoD CIO CMMC Program page: https://dodcio.defense.gov/cmmc/
- 32 CFR Part 170 (CMMC Program Rule): https://www.ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-D/part-170
- DFARS 252.204-7021: https://www.acquisition.gov/dfars/252.204-7021-contractor-compliance-cybersecurity-maturity-model-certification-level-requirements.
- NIST SP 800-171 Rev. 2: https://csrc.nist.gov/pubs/sp/800/171/r2/upd1/final
- DOJ press release, LOGZONE settlement (June 18, 2026): https://www.justice.gov/opa/pr/alabama-defense-contractor-agrees-pay-507144-resolve-false-claims-act-liability-relating
