How CMMC Handles Exceptions and Compensating Controls

The problem the rule has to solve

CMMC Level 2 requires a defense contractor to implement all 110 security requirements in NIST SP 800-171 Rev 2 and prove it to a C3PAO. That is the contract. No exceptions on paper.

Except the contract has to be satisfiable in the real world, and the real world includes:

• A Siemens S7-1500 PLC that cannot do MFA.
• A CNC controller that accepts G-code over plaintext FTP because it was built in 2008.
• A calibrated test rig whose firmware cannot be modified without voiding certification.
• Government-furnished inspection equipment whose configuration the contractor does not own.

If the rule demanded that every one of those devices implement MFA, encrypt its transport with TLS 1.3, emit structured audit events, and pass vulnerability scans, it would be demanding the impossible. So the rule doesn't. It provides a specific mechanism for the gap.

Two mechanisms, actually: the Specialized Asset category and the Enduring Exception with its required Compensating Control. They are not loopholes. They are the load-bearing part of the framework for anyone running real OT.

Specialized Assets — the category that changes the scoping

32 CFR Part 170 defines five asset types as specialized:

• Operational Technology (OT) — PLCs, DCS, SCADA, HMIs, CNCs, industrial controllers.
• Internet of Things (IoT) — networked sensors, cameras, embedded controllers.
• Restricted Information Systems — systems constrained by contract, export control, or classification.
• Government-Furnished Equipment (GFE) — hardware provided by the customer that the contractor cannot reconfigure.
• Test Equipment — calibrated instruments whose firmware changes invalidate calibration.

These assets are in scope for the CMMC assessment but are evaluated against a reduced set of requirements. The SSP has to identify each one, document the CUI that flows to or from it, and describe how it is protected. The C3PAO verifies the protection, not the asset's native compliance.

The consequence is practical: a defense manufacturer with 200 PLCs on the shop floor does not need to retrofit MFA onto 200 PLCs. They need to document them, demonstrate the protection boundary around them, and produce evidence the boundary is doing what they claim it is doing. See the Specialized Asset (CMMC) glossary entry for the full category definitions.

The Enduring Exception mechanism

For each specialized asset — or for any asset with a hard incapacity — the contractor can invoke an Enduring Exception for specific controls the asset cannot satisfy natively.

Three properties define an Enduring Exception:

1. Asset-specific. It names the asset, not the control family. "The CNC on line 4 cannot perform user authentication" is an exception. "We don't do MFA on the shop floor" is not.
2. Control-specific. It names the NIST 800-171 requirement the asset cannot meet. Typically an access-control, audit, or system-and-communications-protection control.
3. Enduring. The limitation is inherent to the device and persists for the asset's service life. This is the distinction from a Plan of Action and Milestones (POA&M), which describes a gap the contractor is actively remediating. An Enduring Exception is a gap that will never close on the asset itself.

The exception goes in the SSP. It documents the incapacity. It does not waive the requirement. The control obligation does not disappear — it shifts.

See CMMC Enduring Exception for the full definition.

The Compensating Control — where the enforcement actually lives

Every Enduring Exception must be paired with a Compensating Control. This is the non-negotiable part, and it's where most readiness programs fail assessment.

The CMMC rule, echoed in NIST SP 800-171A assessment guidance, requires a compensating control to pass four tests:

1. Equivalent risk reduction. The control has to mitigate the specific risk the original requirement addressed — not a similar risk, the same one. If the original control was MFA to prevent unauthorized access, the compensating control must also prevent unauthorized access. Logging the access after the fact is detection, not prevention. Not equivalent.

2. Technically implemented. The mechanism is deployed and operating, not designed or budgeted. Configuration is exportable as evidence. If the C3PAO asks "where is this control running right now," the answer has to be a specific appliance, proxy, process, or system — not a project plan.

3. Verifiable. Logs, policy exports, network captures, or system configuration demonstrate the control operating on real traffic. A description in the SSP is not evidence. A log file is evidence. An exported ruleset is evidence. A screenshot of a management console is evidence.

4. Documented in the SSP. The asset, the uncovered control, the compensating mechanism, the evidence path, and the owner are all written down. An implemented control with no SSP documentation is, for assessment purposes, indistinguishable from no control.

See Compensating Control (CMMC) for the full framework.

What this looks like for OT, concretely

The pattern that actually works for OT specialized assets is proxy-layer enforcement. The asset stays unchanged. The compensating control runs in front of it on the network.

Five of the most commonly invoked controls, and what the compensating pattern looks like:

Each of these compensating controls passes the four tests. They reduce the same risk the original control addressed. They run on actual hardware or software that the C3PAO can inspect. They produce logs and policy exports that serve as evidence. And they live in the SSP alongside the asset and the Enduring Exception they cover.

What a C3PAO actually asks for

The assessment procedures in NIST SP 800-171A are specific about compensating controls. A C3PAO will work through three questions for each one:

1. Show me the control. Not the SSP paragraph. The actual enforcement point. "Which appliance, which policy, which rule."
2. Show me the evidence. A session log. A policy export. A network capture that demonstrates the control acting on real traffic. Ideally during the contractor's normal operations, not a synthetic test.
3. Show me the link to the asset. How does this specific compensating mechanism cover the specific Enduring Exception on the specific asset? The traceability from asset → exception → compensating control → evidence has to be explicit.

If any of those three links are missing — the control exists but isn't documented, the documentation exists but the control isn't running, the control is running but doesn't match what the SSP describes — the finding is a gap. A gap on a compensating control is a gap on the underlying NIST 800-171 requirement, which the asset's Enduring Exception explicitly said would be handled.

The part the Affirming Official is personally signing

The Affirming Official is the senior company representative who certifies the CMMC assessment and re-affirms annually in SPRS. The signature carries personal exposure under the False Claims Act (31 U.S.C. 3729). See Affirming Official (CMMC) for the role definition.

When the Affirming Official signs, they are attesting that:

• Every NIST SP 800-171 Rev 2 control is either implemented on the asset or covered by a valid Enduring Exception with a functioning Compensating Control.
• Evidence exists and can be produced on demand.
• The SSP accurately describes the environment as it actually operates.

The False Claims Act threshold is not intent to defraud. Reckless disregard or deliberate ignorance of whether the statement is true is sufficient. Penalties are treble damages plus per-claim fines. The Department of Justice has been pursuing cybersecurity-related FCA cases through its Civil Cyber-Fraud Initiative since 2021. Settlements so far have involved misrepresented NIST 800-171 compliance and missing controls that the contractor certified as present.

For compensating controls specifically, the relevant question the Affirming Official has to be able to answer honestly is: is this control technically operating, or does it exist only in the SSP document? A control that exists only on paper turns the certification into a false statement, and the liability attaches to the signer.

The common mistakes

Three patterns that cause compensating-control findings during assessment:

Policy as control. The SSP contains a policy statement ("vendors must authenticate before accessing OT systems") but no technical enforcement exists. Policies are necessary but not sufficient. A policy is not a compensating control unless a mechanism actively prevents the scenario the original requirement addressed.

Generic language. The compensating-control description reads like it was copied from a vendor datasheet — "enforces zero-trust access across all systems." The C3PAO asks which specific systems, which specific enforcement points, which specific logs. If the SSP cannot answer, the control is deemed not-verifiable.

Evidence that describes the control instead of the control operating. A screenshot of the management UI shows the policy exists. A log showing the policy acting on a real session shows the policy runs. Only the second is evidence for assessment.

What to do before the assessment

If you are 180 days from a Level 2 assessment and your program leans on Enduring Exceptions for OT, three things are worth doing concretely:

1. Enumerate every specialized asset. Name each one, name the controls it cannot satisfy, name the CUI paths that touch it. The SSP needs this as a table the C3PAO can read.
2. Map each exception to a running compensating control. Not a planned one. One that is operating today and producing logs today. If the compensating mechanism doesn't exist yet, the Enduring Exception is not yet valid.
3. Collect the evidence proactively. Session logs for the last 30 days, policy exports, network diagrams showing the enforcement boundary. The day of the assessment is not the day to find out that the logging was misconfigured six months ago.

The framework is well-designed. Specialized Assets, Enduring Exceptions, and Compensating Controls give OT-heavy defense suppliers a viable path to Level 2 compliance without retrofitting MFA onto a decades-old CNC. But the path only works if the compensating controls actually run, actually produce evidence, and actually match what the SSP says they do.

Trout Access Gate is the compensating-control enforcement layer many defense suppliers use for OT specialized assets — identity-bound MFA, session-level audit, TLS termination, deny-by-default — running as a non-inline proxy in front of the assets that cannot satisfy the controls themselves. See the CMMC Enduring Exceptions for OT guide, or talk to an engineer about what the compensating-control evidence looks like in your environment.