CMMC SI.L2-3.14.7: Identifying Unauthorized Use

The Control the Community Reads Halfway

SI.L2-3.14.7 is the seventh control in the System and Information Integrity family of NIST SP 800-171, which CMMC adopts for Level 2 certification. The SI family addresses how contractors identify, respond to, and recover from system and information integrity issues. Control 3.14.7 specifically requires the contractor to identify unauthorized use of organizational systems.

The CMMC practitioner community treats SI.L2-3.14.7 primarily as a monitoring control. Most implementation guidance points contractors toward SIEM platforms, intrusion detection, and network traffic analysis. That guidance addresses part of what the control requires and not all of it. The 800-171A assessment objectives tell a different story than the control text does.

The Two Halves of 3.14.7

Objective 3.14.7[a] states that authorized use of the system is defined. Objective 3.14.7[b] states that unauthorized use of the system is identified. Two determinations, not one. The CMMC Assessment Process directs assessors to evaluate each objective using the examine, interview, and test methods. For objective [a], the examine method points to policy and procedure artifacts. The contractor must produce something that defines authorized use before objective [b] can be meaningfully evaluated.

Why Monitoring Alone Does Not Satisfy the Control

A SIEM platform detects deviation from technical baselines. It observes what is happening on the network and flags activity that matches configured rules. The rules are typically written against indicators of compromise, known attack patterns, and statistical anomalies. None of that answers the question of whether the observed activity was authorized.

Consider a user who transfers a large file to a cloud storage service at 2:00 a.m. The SIEM may flag the transfer based on volume, time of day, and destination. Whether the transfer was authorized depends on the contractor's policy. If the user is an engineer working an approved overnight shift, transferring project files to an approved collaboration platform, the transfer is authorized and the SIEM alert is a false positive. If the user is transferring CUI to a personal storage account, the transfer is unauthorized and the SIEM alert is correct. The SIEM cannot distinguish between the two without a policy definition of what counts as authorized.

Detection technology observes activity without determining whether the activity is authorized. That determination requires a policy reference, which the control requires the contractor to produce separately. The identification step has meaning only once the authorization definition is in place.

Access Control and Authorized Use Are Different Questions

One distinction matters because it is the source of most confusion about 3.14.7. Access control specifies who may reach what resources. Authorized use specifies what users may do with the resources they can reach. An engineer with authorized access to a CAD system may or may not be authorized to export files from that system to a personal cloud account. Access control policies alone do not answer the export question. The authorization baseline does.

This is why existing AC-family documentation does not, by itself, satisfy objective [a]. Access control defines the boundary. Authorized use defines behavior within the boundary. Both are required, and they are not the same artifact.

The Authorization Baseline

The authorization baseline is the set of policy artifacts that together define authorized use of organizational systems. It is not a single document. It is a structured collection of artifacts that each define one dimension of authorized use and together provide the reference point the detection layer requires.

Many contractors already maintain documentation that bears on authorized use. Access control policies, configuration management baselines, and acceptable use policies all contribute. The question is whether the existing documentation can be assembled into a coherent reference on demand. The same ambiguity that makes SIEM alerts hard to interpret without a policy reference makes scattered documentation hard to evaluate as a definition of authorized use. The baseline adds coherence, not net new content.

Each baseline element draws on documentation the contractor already produces for related controls. A contractor with mature documentation for these related controls has most of the baseline content in hand already. The work required to produce the baseline is aggregation and cross-referencing, not creation.

The Detection Layer Maps Against the Baseline

Once the baseline exists, the detection layer has a reference point. No single tool covers the full baseline. Detection is layered because the baseline has multiple dimensions and different tools observe different dimensions. SIEM correlation rules can be written against role-based access expectations and the acceptable use policy. DLP tools enforce approved data movement patterns. Endpoint application control enforces the approved application inventory. CASB platforms monitor cloud service interaction. Manual review covers what tooling cannot reach.

The contractor must be able to demonstrate that each baseline element is covered by at least one detection mechanism. A baseline element with no corresponding detection is a gap the assessor can identify. That does not mean every element requires a dedicated tool. One tool can cover multiple elements, and manual review covers elements that tooling cannot reach. What matters is that coverage is complete and documented as a coverage map.

A Worked Example

The paper uses a fictional ten-person CNC machine shop to make the framework concrete. The Shop holds CUI subcontracts from a tier-one aerospace prime and operates a standard small-contractor environment: Microsoft 365 GCC High, dedicated CAD and CAM workstations, a SIEM platform, endpoint detection and response, and a managed service provider under contract for IT support. The profile is familiar to most practitioners advising the defense industrial base.

Each baseline element is worked through with specifics. The acceptable use policy prohibits personal cloud storage on company systems and states termination consequences for CUI violations. Five roles are defined, each with its own authorized activities against CUI. The approved application inventory names specific tools. The data movement pattern documentation traces CUI from the prime's collaboration portal through the file server and back out through approved channels. Remote access is restricted to company-issued laptops over VPN with multi-factor authentication, with CUI project folders accessible only to the engineering role. The third-party register specifies what each external provider is authorized to access and under what terms.

The detection coverage map shows how each element connects to a specific mechanism, from endpoint application control for the approved application inventory, to SIEM correlation rules for remote access conditions, to monthly manual review for third-party access against the register.

Evidence the Assessor Examines

The 800-171A methodology uses three evidence categories: examine, interview, and test. For 3.14.7, each category produces a different type of evidence the contractor must prepare. Examine evidence covers the policy and procedure artifacts: the authorization baseline itself, the detection configuration documentation, the review procedures, and the records of identified unauthorized use and its disposition.

Interview evidence comes from personnel with responsibility for defining authorized use, personnel with responsibility for operating the detection layer, and personnel with responsibility for investigating identified events. The assessor will ask questions that test whether personnel understand both halves of the control and can describe how their activity connects to the baseline.

Test evidence covers operational demonstration that the detection layer functions as documented: the current SIEM rule set, the current DLP policy, the current CASB configuration, and the disposition record for a sample of recent events.

A contractor who can produce the authorization baseline, the detection layer configuration, the coverage map, the review procedures, the sample event records, and the procedural documentation has satisfied both objectives and demonstrated the coherence between them. A contractor who can produce only the detection configuration and event records has produced evidence for objective [b] and nothing for objective [a]. That is the gap the assessor will identify.

Anticipated Objections

The first predictable objection is that the paper reads the 800-171A objectives too literally. The response is that the objective wording separates them as distinct determinations, the CAP directs assessors to evaluate each separately, and the examine method for objective [a] points to policy artifacts. Reading the two objectives as one collapses the methodology NIST published.

The second predictable objection is that wave-one C3PAO assessors will not evaluate the control this carefully in practice. That may prove correct. The contractor bears the asymmetric risk. The cost of preparing the authorization baseline is a policy document and modest governance effort. The cost of not preparing it, if the assessor does evaluate objective [a], is a control finding and a SPRS score impact. The risk-adjusted choice is the same regardless of which prediction about assessor behavior turns out to be correct.

The full paper develops each of these points with the evidence package, the detection layer coverage map, and the worked example that carries through all three sections.