Technical guides
Written to be used rather than to rank. Where a fact is contested we say so instead of picking the version that reads better.
What CMMC actually requires right now
Two rules matter. The CMMC Program rule at 32 CFR Part 170 took effect on 16 December 2024 and establishes the levels, the assessment types, and the assessor ecosystem. The acquisition rule — the DFARS change that lets the Department of Defense actually place CMMC requirements into contracts — took effect on 10 November 2025. That start date began Phase 1.
Under Phase 1, Level 1 and Level 2 self-assessment requirements appear in new solicitations that carry the clause. If your contract does not carry it yet, the obligation has not attached to you yet, though a prime can and frequently does flow equivalent requirements down contractually ahead of that.
For scoring, NIST SP 800-171 Revision 2 remains the operative baseline. Revision 3 was finalized in May 2024 and reorganizes the requirements into 17 families with organization-defined parameters, but it is not the CMMC assessment baseline.
We do not publish a date for CMMC phases after Phase 1. Reporting on later-phase timing traces to trade press rather than to a confirmable Department of Defense source, and a readiness partner who guesses at regulatory dates is not a readiness partner. Nor will we give you a hard "Revision 2 is deprecated on this date" claim: the sources conflict and the CMMC program continues to use Revision 2 for scoring.
What to do now: find out whether your current contracts carry the clause, determine where CUI actually lives, and get an evidence-based score. In that order. CMMC readiness assessment.
Scoping a CUI enclave
This is the most expensive decision in a compliance program and it is usually made by accident.
If Controlled Unclassified Information is allowed to exist anywhere on your corporate network, then your corporate network is in scope. Every workstation, every server, every SaaS application, every employee laptop. The assessment is larger, the remediation is larger, and the ongoing cost of staying compliant is larger, permanently.
If instead you define a bounded enclave — a specific set of systems where CUI is permitted, with controlled flows in and out — then that enclave is what you assess and harden. Everything else drops to a much lighter standard.
How to decide
- Map the real flows first. Where does CUI arrive, who touches it, where does it rest, and where does it leave? Interview the people who actually handle it rather than reading the policy.
- Count the humans. If four people in one department handle CUI, an enclave is almost certainly right. If two hundred people across every function do, the enclave may need to be the whole estate, and pretending otherwise produces a boundary nobody respects.
- Decide the enforcement mechanism. A boundary that depends on employees remembering a policy is not a boundary. It needs technical controls on the flows.
- Check the exceptions early. The engineer who takes drawings home, the shared mailbox, the supplier portal. Exceptions discovered during an assessment are expensive; exceptions discovered during scoping are a design input.
The enclave decision is worth more than any individual control you could implement afterwards. We run this as a workshop.
Why your MFA did not stop that phish
Multi-factor authentication defeats password reuse and credential stuffing. It does not, on its own, defeat a modern phishing kit, and the reason is worth understanding because it changes what you should do about it.
An adversary-in-the-middle kit proxies the real login page. The victim sees the genuine sign-in, enters the genuine password, and completes the genuine MFA prompt. The proxy passes all of it through to the real service and captures the session token that comes back. The attacker then replays that token. From the service's point of view, authentication already succeeded.
What actually helps
- Phishing-resistant authentication. FIDO2 security keys and passkeys bind the credential to the real origin, so a proxy on a different domain cannot complete the exchange. This is the only item on this list that addresses the root cause.
- Device compliance as a condition of access. A stolen token replayed from an unmanaged machine fails if managed-device state is actually required rather than merely logged.
- Short token lifetimes with continuous evaluation. Re-evaluate risk during the session and revoke on signal change, rather than trusting a token until it expires.
- Detection for the replay itself. The same token appearing from a new location, a new device, or an unusual user agent is a strong signal — if someone is watching for it.
If your conditional access policies are in report-only mode, you have a report, not a control. Identity and Zero Trust work is where this gets closed.
How to read a penetration test report
Most buyers cannot tell a real engagement from a scanner export with a cover page until after they have paid for it. These are the tells.
Signs of real work
- An attack-path narrative. A real report tells a story: this led to that, which allowed this. A list of findings sorted by CVSS with no chaining means nobody tried to chain them.
- Evidence of exploitation, not just detection. "Port 445 open, SMB signing disabled" is a scanner observation. "Relayed authentication from host A to host B and obtained local administrator" is a test.
- Findings that are specific to you. If every description could appear verbatim in another client's report, it probably did.
- Negative results. Good reports record what was attempted and failed. That is how you learn your controls worked.
- Remediation an engineer can act on. "Implement defense in depth" is not remediation. "Set this registry value on these hosts" is.
Warning signs
- Raw scanner output pasted into an appendix and counted as findings
- Severity ratings with no exploitability analysis behind them
- No rules of engagement or scope statement in the document
- No named tester or stated certification
- Retesting quoted as a separate engagement
Ask for a redacted sample report before you commit. Any firm doing real work will have one. Ours is available on request.
Finding the AI already in your organization
Shadow AI is less about staff signing up for tools than about vendors switching features on inside products you already license. Both matter, and the second is harder to see.
Where to look
- Expense and procurement data. Individual subscriptions on corporate cards, and SaaS renewals whose terms changed to include AI processing.
- Identity logs. OAuth consent grants and application registrations are the clearest signal of a third-party service connected to your data. Review what each one can actually reach.
- Network and proxy telemetry. Traffic to known AI service endpoints, including from unmanaged devices on your network.
- Vendor release notes. Tedious, and the only reliable way to catch AI features enabled by default in a product you already run.
- Ask, without consequences. An amnesty produces better data than an investigation. People who fear a disciplinary outcome do not disclose.
Once you have the inventory, the question for each entry is narrow: what data can this reach, what can it do on its own, and who approved it? Governance work follows the NIST AI Risk Management Framework; where a system is deployed with retrieval or tool access, test it adversarially.
Questions these did not answer?
Ask an engineer directly. We would rather have the conversation than publish another guide.