Insider Risk Monitoring in CMMC and Defense Industrial Base Environments

Cybersecurity Maturity Model Certification 2.0 is a contractual obligation that applies now, not a standard on the horizon. Enforcement started in November 2025, written into Department of Defense contracts through the 48 CFR DFARS acquisition rule and DFARS 252.204-7021, with 32 CFR Part 170 laying out the program's underlying requirements. That makes 2026 the first full calendar year in which compliance is mandatory, and the population affected is large: more than 220,000 contractors and subcontractors across the Defense Industrial Base now have to meet it, regardless of size.

The framework sorts organizations into three levels. It covers 17 basic practices, verified through annual self-assessment, and applies only to Federal Contract Information. Level 2 requires full implementation of NIST SP 800-171 and applies to any organization handling Controlled Unclassified Information, with assessment either done internally or by a certified third-party assessor organization depending on how the Department of Defense prioritizes the contract. Level 3 adds the enhanced controls of NIST SP 800-172, reserved for high-risk programs where exposure to advanced persistent threats is part of the operating reality, and it's assessed by the government directly.

One detail changes how contractors should plan: no organization gets to decide for itself whether its CUI counts as prioritized. That call belongs to the relevant defense authority, based on mission criticality, data sensitivity, and threat exposure. A contractor cannot read its own contract and conclude it qualifies for a lighter assessment path. The level a contractor must meet, and how that compliance gets verified, is a determination made above it. So you need to treat every control family in this piece seriously, because a modest CUI footprint does not buy you a modest compliance burden.

The specific NIST 800-171 controls that govern insider risk monitoring

NIST SP 800-171 organizes its requirements into control families, and a handful of them bear directly on how an organization is supposed to monitor the people and processes that touch CUI. Access Control (AC) sets the baseline: it requires limiting system access to authorized users, enforcing least privilege, and controlling how CUI moves through a system. AC sets the perimeter of what counts as authorized behavior, and a monitoring program measures every anomaly it later flags against that perimeter.

Audit and Accountability (AU) requires that organizations create and retain system audit logs sufficient to support monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity, and that those logged events get reviewed and updated. AU functions as the evidentiary backbone of any insider monitoring program. Without logs that can actually be reviewed and produced, a contractor has no way to show an assessor that suspicious access was ever examined.

Identification and Authentication (IA) requires that users, processes acting on behalf of users, and devices all be uniquely identified and authenticated. That requirement sounds mechanical, but it's the precondition for everything AU is trying to accomplish: a log entry is only useful if it can be tied to a specific person or account, and IA is what makes that attribution possible.

Personnel Security (PS) requires screening individuals before you grant them access to organizational systems, and it requires protecting CUI during and after personnel actions like terminations and transfers. The obligation to manage the off-boarding period is written into the control itself, not left as a best practice contractors adopt at their own discretion.

System and Information Integrity (SI) requires you to monitor organizational systems, including inbound and outbound communications traffic, so you can detect attacks and indicators of potential attacks. SI is the control family that turns behavioral monitoring into a compliance requirement rather than something a security vendor sells as an upgrade.

Incident Response (IR) requires you to establish and maintain an incident-handling capability, and to track, document, and report incidents as they occur. Detection on its own does not satisfy IR. A contractor needs the capacity to respond, and that capacity has to exist alongside whatever detection tools it runs.

Assessors expect evidence, not assertions: System Security Plans, access control and logging records, and incident response documentation all have to show alignment between what the controls require and what the organization actually does. Plans of Action and Milestones are only permitted for select controls at Level 2 and Level 3, and they come with Department of Defense-defined timelines for closure. You cannot let a gap in insider monitoring sit on a POA&M indefinitely. It has to close.

Cleared contractor environments make compliance harder than typical enterprises

Inside a cleared contractor environment, authorized access to CUI is just the normal condition of work, and that single fact changes what NIST 800-171's monitoring controls are actually up against. The behavior those controls are built to catch is, by design, hiding inside activity that looks entirely legitimate on its face.

Insiders in these settings already hold authorized access to the most sensitive material a program produces. That means the access control perimeter AC establishes is not a meaningful barrier against a malicious or compromised insider, because that insider has already cleared it through ordinary, approved means. The population that counts as "insider" has also grown well past the employee with a badge. Unmanaged service accounts, autonomous agents, contractors, and subcontractors all touch CUI in the course of routine operations, and each one represents a surface that the AU and IA control families are supposed to cover.

Shadow AI adds a newer complication. A developer importing a model, or a business unit standing up an AI service without going through established channels, can move CUI through a path that legacy logging infrastructure was never built to observe. The data moves, but the control environment has no record of it moving.

Physical bypass remains a live threat, and no amount of network monitoring touches it. In the case of the Department of Defense's Missile Defense Agency, a civilian employee named Ewa Maria Ciszak was arrested in June 2025 and charged with unauthorized removal and retention of classified documents, conduct that began around February 2025 and ran through June 18 of that year. Documents allegedly went to her personal residence and her vehicle. No digital exfiltration tool was involved, and perimeter data loss prevention had nothing to detect.

Air-gapped networks carry their own false sense of security. At L3Harris's Trenchant unit, former general manager Peter Williams moved between Trenchant's offices in Sydney and Washington, D.C., and in October 2025 he pleaded guilty to transferring eight highly classified zero-day exploits off secure networks on portable external hard drives. That is privileged-access misuse at the session and endpoint layer, and it's a pattern that network egress controls are not positioned to see.

Nation-state adversaries target DIB contractors precisely because their defenses tend to run weaker than those of prime contractors, while their access to program-sensitive CUI is just as valuable. China has combined cyber campaigns with direct human targeting of cleared personnel, so it treats the contractor workforce itself as an attack surface. Supply chain structure makes the exposure worse still: CMMC requirements flow down to subcontractors, and the prime contractor carries responsibility for vendor compliance even where a subcontractor handles only a limited slice of FCI. A monitoring gap at a tier-two subcontractor becomes a compliance gap that lands on the prime.

Four insider exfiltration archetypes mapped to CMMC's monitoring controls

Real insider incidents inside DIB environments tend to fall into recognizable patterns, and each one reveals a different blind spot in what static logging can surface on its own. These blind spots sit exactly where the AU and SI control families are supposed to deliver visibility, and they cannot deliver it without behavioral context layered on top of the raw log.

Privileged-access abuse is one archetype that merits close examination. It involves super-user or admin credentials used to copy material out of access-controlled repositories onto portable media. Williams at L3Harris Trenchant exploited his super-user access and, in a detail that illustrates how thin the line can be between oversight and the offense itself, took part in the internal investigation into the very leak he had created. You catch this pattern by monitoring at the session and endpoint layer, where the AU control family's logging requirements apply directly, as long as those logs are actually built to capture session-level activity.

The second archetype is slow exfiltration, sometimes called low-and-slow siphoning, and it works by calculated extraction kept below whatever threshold rules a security team has set, carried out over an extended period. Espionage-linked dwell time in the DIB runs to months, not days. A pattern stretched that thin across that much time is invisible to any rule built around a single point in time. Catching it requires longitudinal analysis of behavior across a user's full timeline, not a snapshot of any one session.

Both archetypes point to the same structural conclusion. The control families exist to produce visibility, but visibility depends on analysis that spans time and context, not just the presence of a log entry at the moment something happened.

Logging meets the letter of CMMC but misses the risk it is designed to prevent

A contractor can satisfy the text of CMMC's audit and monitoring controls by collecting logs and reviewing them on a schedule, and still run a program that would not catch the incidents those controls exist to prevent. Passive log collection, without behavioral analysis layered over it, leaves the most dangerous insider activity undetected, because authorized access does not generate an anomalous event for anyone to log.

The AU family requires that logs be created, retained, and reviewed, but it does not define what review has to look like in terms of frequency, depth, or method. A contractor that retains logs for the required period and reviews them once a month can technically attest to compliance while missing a slow exfiltration that unfolds over several weeks between one review cycle and the next.

Static, content-rule-based data loss prevention tools compound the problem, because they generate more alerts than any team can work through at the scale CMMC demands. Security operations teams already face so many daily alerts that most go unaddressed. The space between what gets flagged and what actually gets investigated is where real incidents survive undetected, because no one reached them.

That alert burden is a compliance risk in its own right. When analysts cannot keep pace with volume, genuinely suspicious events age past the response timelines that CMMC's IR controls require, turning a detection failure into a documented incident response failure as well.

There's also a liability dimension that extends past security. False Claims Act exposure attaches to inaccurate self-assessments and executive affirmations that get submitted to the government's contractor risk-assessment system. A contractor that attests its monitoring controls are implemented, while actually running a log-collection-only program incapable of surfacing real insider behavior, carries False Claims Act risk on top of the underlying security risk. The paperwork can say one thing while the operating reality says another, and that gap is what both an adversary and a federal auditor are positioned to find.

What behavioral monitoring requires to satisfy CMMC's intent

Meeting CMMC's actual monitoring intent calls for a capability that understands both the data being touched and the person touching it, correlating content, identity, role, destination, and behavioral pattern across a user's full timeline rather than reacting only at the moment an event gets flagged.

The AU family's requirement that logged events be reviewed and updated implies that logs need to be reviewable in a way that actually surfaces risk. That requires enrichment: knowing who the user is, what their role authorizes them to touch, what their recent access history looks like, and whether the event under review fits that pattern or breaks it.

Least-privilege enforcement under AC requires more than confirming what permissions exist on paper. It requires knowing whether the behavior tied to those permissions matches the job function they were granted for. A user with broad access who suddenly starts pulling from repositories unrelated to their current project is still operating inside their authorized permissions, and that is exactly the kind of activity behavioral analysis can flag where a static rule has nothing to trigger on.

Personnel security controls governing off-boarding require access revocation that happens in real time, not at the next scheduled provisioning cycle, along with review of activity in the period leading up to a termination. The cases of departing employees Akhter and Luo both show that the real risk window opens before the termination event is processed.

Incident response controls require the capacity to investigate an event, not merely detect it. That means a monitoring platform has to assemble the full account of an incident, what data was touched, which systems were involved, what the timeline looked like, and what the user did before and after, without forcing analysts to piece that story together by hand from raw log output.

None of this holds up in front of an assessor without explainability. C3PAOs and government assessors need auditable evidence that a specific control blocked or flagged a specific action, not a general assurance that a system is working as intended. If behavioral analysis cannot produce a clear decision trail, it creates assessment risk of its own, and that is the most legitimate objection people raise against AI-driven approaches in regulated defense environments. Any monitoring capability built to satisfy CMMC's intent has to answer that objection directly, producing a record an assessor can follow line by line, not just an output a security team is asked to trust.