Document CMMC exceptions for OT machines.
CMMC Enduring Exceptions and compensating controls
Some machines cannot meet a CMMC control. CMMC lets you record that as an Enduring Exception. You then prove a compensating control covers the risk.
Last updated:
How does CMMC handle exceptions and compensating controls?
CMMC handles them through the Enduring Exception. When an asset cannot meet a NIST SP 800-171 requirement and fixing it is not feasible, you record that limit in your System Security Plan (SSP). For each exception you then document a compensating control that is running and produces evidence an assessor can check.
The CMMC Program Rule (32 CFR 170.4) defines an Enduring Exception as "a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible." It is not a waiver. It does not remove the obligation to protect CUI. It moves the burden from the machine to a compensating control you must document, implement and prove.
This is different from a temporary deficiency, which the same rule defines as a gap with a known fix. A temporary deficiency goes in a POA&M and gets closed. An Enduring Exception stays for the life of the machine, so its compensating control must keep running for that long too.
Status, October 2026: the Department of War suspended CMMC Phase II third-party assessments in July 2026 (what the suspension changes). The NIST SP 800-171 obligation in DFARS 252.204-7012 still applies, and the score you post and affirm in SPRS under DFARS 252.204-7019 still covers every exception you claim.
Specialized assets change your assessment scope.
Before you write a single Enduring Exception, classify the asset. 32 CFR Part 170 names five asset types as specialized. They stay in scope. At Level 2, 32 CFR 170.19(c) requires you to list them in the asset inventory, the SSP and the network diagram, and to show they are managed under your risk-based security policies. The assessor reviews the SSP and does not assess them against the other requirements. At Level 3 they are assessed, and intermediary devices may supply the missing capability.
Operational Technology (OT)
PLCs, DCS, SCADA, HMIs, CNC controllers, industrial controllers.
Internet of Things (IoT)
Networked sensors, cameras, and embedded controllers.
Restricted Information Systems
Systems constrained by contract, export control, or classification.
Government-Furnished Equipment (GFE)
Customer-provided hardware the contractor cannot reconfigure.
Test Equipment
Calibrated instruments whose firmware changes invalidate calibration.
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 each asset, demonstrate the protection boundary around it, and produce evidence the boundary does what they claim. See the Specialized Asset (CMMC) entry for the full category definitions, and CMMC requirements for OT and IoT specialized assets for what each type needs before an exception applies.
What must the SSP document for each exception?
Six things, for every asset and every control it cannot meet. The rule only says the circumstance must be in the SSP. The list below is what an assessor needs to trace an exception from the machine to the proof. Most programs fail on the fifth row.
| Requirement | What to write in the SSP | Evidence the assessor asks for |
|---|---|---|
| 1. Asset identification | The specific device, its function, its network location and the protocol it speaks. | The same device in your asset inventory and on the network diagram of the assessment scope. |
| 2. The control it cannot meet | The exact NIST SP 800-171 requirement, for example IA 3.5.3 (MFA) or AU 3.3.1 (audit logging). One entry per control, never "various controls". | A one-to-one mapping from asset to requirement in the SSP. |
| 3. Why it cannot comply | The technical limit, stated plainly. No identity stack. Modbus with no TLS. Firmware that cannot be updated. | Vendor documentation or firmware version showing the limit is structural, not a backlog item. |
| 4. The compensating control | The mechanism that gives equivalent protection, where it runs and who owns it. For example, MFA enforced at a gateway before any session reaches the machine. | The policy configuration or rule export from the enforcement point. |
| 5. Proof the control works | Where the evidence lives and how often it is reviewed. | Session logs showing enforcement, segmentation baselines, denied-access records. A narrative alone is not evidence. |
| 6. Affirming Official review | Who reviewed the evidence, not just the SSP text, and when. | The affirmation record and the evidence it was based on. |
Assessors often treat a larger system as the unit, such as a CNC cell or a line segment, rather than each PLC. That cuts the number of entries you write. It does not cut what each entry must contain.
What the Enduring Exception covers.
Physical security controls (PE 3.10.1 through 3.10.5)
Facility access, visitor management, physical logs, access devices. TAG has no technology involvement. Customer-owned.
Personnel screening (PS 3.9.1)
Pre-employment screening. HR/people process. No technology component.
Physical media handling (MP 3.8.1, 3.8.3, 3.8.4, 3.8.7)
No network-layer equivalent. Physical media controls are procedural and facility-dependent.
Vulnerability scanning of OT assets (RA 3.11.2, 3.11.3)
TAG deliberately does not scan OT assets because active scanning risks disrupting production. This is a legitimate NA with documented rationale in the SSP.
What the Enduring Exception does not cover.
The risk that the OT asset's incapacity creates for CUI flows
The SSP obligation to document a compensating control and its rationale
The C3PAO's obligation to verify a compensating control exists and works
The Affirming Official's personal certification exposure under the False Claims Act
The Enduring Exception documents a limitation. It does not eliminate the requirement. The SSP must still show how the organization manages the residual risk.
Each exception needs a compensating control.
For each Enduring Exception, the SSP must document a compensating control that provides equivalent protection. Below are the five controls most commonly invoked for OT assets, with the specific limitation, the proxy-layer enforcement, and what the SSP should contain.
| Control | OT Limitation | Compensating Control | TAG Role | SSP Documentation Required |
|---|---|---|---|---|
| IA 3.5.3 | Production machines, CNC controllers, and quality inspection stations have no native identity stack. They cannot prompt for a second factor, store credential hashes, or validate tokens. Most communicate over serial or proprietary protocols with no authentication handshake. | Access Gate enforces MFA at the proxy layer before any session reaches the equipment. The user authenticates through the identity gateway. The machine never sees unauthenticated traffic. | R | Document the asset, its protocol, and the reason MFA cannot be enforced natively. Reference the Access Gate policy rule that requires MFA for all sessions to the asset. Attach the policy configuration and a sample session log showing MFA enforcement. |
| AU 3.3.1 / 3.3.2 | Legacy factory equipment generates no audit logs. CNC cutters, labeling machines, and packaging systems have no syslog daemon, no event buffer, and no mechanism to record who accessed them or what commands were issued. | Access Gate captures tamper-evident session logs for every connection to the asset. Logs include user identity, timestamp, source, destination, protocol, and command payload. Logs are forwarded to SIEM. | R/A | Document that the asset cannot generate logs and that the compensating control is network-layer session logging via Access Gate. Include the log retention policy, SIEM forwarding configuration, and a sample log entry. |
| SC 3.13.8 | Modbus, DNP3, EtherNet/IP, and most industrial protocols transmit in plaintext. Firmware on laser cutters, welding robots, and inspection scanners cannot be updated to support TLS. Replacing the equipment is not operationally viable. | Access Gate enforces TLS/FIPS-validated encryption on all CUI paths. Traffic between the user and Access Gate is encrypted. The plaintext segment between Access Gate and the OT asset is isolated within a micro-DMZ with no external egress. | R/A | Document the protocol, the encryption gap, and the compensating architecture. Include the TLS configuration, the FIPS validation certificate reference, and the micro-DMZ network diagram showing the isolated plaintext segment. |
| AC 3.1.1 / 3.1.2 | Shop floor equipment has no identity layer. A CNC mill, a coating system, or a packaging line accepts any connection on its open port. There is no concept of user accounts, roles, or permission sets on the machine itself. | Access Gate enforces identity-based access control at the proxy boundary. Each user is authenticated and authorized before a session is established. Role-based policies restrict access to specific assets, protocols, and commands. | R | Document that the asset has no native access control. Reference the Access Gate RBAC policy, the user-to-asset mapping, and the least-privilege rule set. Attach a policy export and a denied-access log sample. |
| SC 3.13.6 | Production equipment accepts any inbound connection. Measurement stations, conveyor controllers, and test rigs do not implement firewalls, allowlists, or connection filtering. Any host on the network segment can reach them. | Access Gate enforces a deny-all default posture with explicit allow-list exceptions. Only authorized users, from authorized sources, using authorized protocols, reach the asset. Everything else is dropped and logged. | R/A | Document that the asset cannot filter connections natively. Reference the Access Gate deny-by-default policy, the allow-list rules, and the drop log. Attach the baseline policy and a sample of denied connection attempts. |
R = Responsible, A = Accountable, S = Supportive. Refer to the Shared Responsibility Matrix for the full control mapping.
Multi-factor authentication
Why the OT asset cannot comply
Production machines, CNC controllers, and quality inspection stations have no native identity stack. They cannot prompt for a second factor, store credential hashes, or validate tokens. Most communicate over serial or proprietary protocols with no authentication handshake.
Network-layer proxy enforcement
Access Gate enforces MFA at the proxy layer before any session reaches the equipment. The user authenticates through the identity gateway. The machine never sees unauthenticated traffic.
SSP documentation
Document the asset, its protocol, and the reason MFA cannot be enforced natively. Reference the Access Gate policy rule that requires MFA for all sessions to the asset. Attach the policy configuration and a sample session log showing MFA enforcement.
Audit logging
Why the OT asset cannot comply
Legacy factory equipment generates no audit logs. CNC cutters, labeling machines, and packaging systems have no syslog daemon, no event buffer, and no mechanism to record who accessed them or what commands were issued.
Network-layer proxy enforcement
Access Gate captures tamper-evident session logs for every connection to the asset. Logs include user identity, timestamp, source, destination, protocol, and command payload. Logs are forwarded to SIEM.
SSP documentation
Document that the asset cannot generate logs and that the compensating control is network-layer session logging via Access Gate. Include the log retention policy, SIEM forwarding configuration, and a sample log entry.
Encryption in transit (CUI paths)
Why the OT asset cannot comply
Modbus, DNP3, EtherNet/IP, and most industrial protocols transmit in plaintext. Firmware on laser cutters, welding robots, and inspection scanners cannot be updated to support TLS. Replacing the equipment is not operationally viable.
Network-layer proxy enforcement
Access Gate enforces TLS/FIPS-validated encryption on all CUI paths. Traffic between the user and Access Gate is encrypted. The plaintext segment between Access Gate and the OT asset is isolated within a micro-DMZ with no external egress.
SSP documentation
Document the protocol, the encryption gap, and the compensating architecture. Include the TLS configuration, the FIPS validation certificate reference, and the micro-DMZ network diagram showing the isolated plaintext segment.
Access control and least privilege
Why the OT asset cannot comply
Shop floor equipment has no identity layer. A CNC mill, a coating system, or a packaging line accepts any connection on its open port. There is no concept of user accounts, roles, or permission sets on the machine itself.
Network-layer proxy enforcement
Access Gate enforces identity-based access control at the proxy boundary. Each user is authenticated and authorized before a session is established. Role-based policies restrict access to specific assets, protocols, and commands.
SSP documentation
Document that the asset has no native access control. Reference the Access Gate RBAC policy, the user-to-asset mapping, and the least-privilege rule set. Attach a policy export and a denied-access log sample.
Deny by default (network communications)
Why the OT asset cannot comply
Production equipment accepts any inbound connection. Measurement stations, conveyor controllers, and test rigs do not implement firewalls, allowlists, or connection filtering. Any host on the network segment can reach them.
Network-layer proxy enforcement
Access Gate enforces a deny-all default posture with explicit allow-list exceptions. Only authorized users, from authorized sources, using authorized protocols, reach the asset. Everything else is dropped and logged.
SSP documentation
Document that the asset cannot filter connections natively. Reference the Access Gate deny-by-default policy, the allow-list rules, and the drop log. Attach the baseline policy and a sample of denied connection attempts.
Four tests every compensating control must pass.
Assessors working from the NIST SP 800-171A assessment procedures check every compensating control against four practical tests. Most readiness programs fail on the second and third.
1. Equivalent risk reduction
The control mitigates the specific risk the original requirement addressed, not a similar one. If the original control was MFA preventing unauthorized access, logging that access afterwards is detection, not prevention. Not equivalent.
2. Technically implemented
Deployed and operating, not designed or budgeted. When the C3PAO asks where this control is running right now, the answer is a specific appliance, proxy, or process, not a project plan.
3. Verifiable
Logs, policy exports, or network captures show the control acting on real traffic. A description in the SSP is not evidence. An exported ruleset is.
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 entry is, for assessment purposes, indistinguishable from no control.
What a C3PAO asks.
Three questions per compensating control, in this order:
- Show me the control. Not the SSP paragraph, the actual enforcement point. Which appliance, which policy, which rule.
- Show me the evidence. A session log, a policy export, or a capture showing the control acting on real traffic during normal operations, not a synthetic test.
- Show me the link to the asset. The traceability from asset to exception to compensating control to evidence has to be explicit.
If any link is missing, the finding is a gap. A gap on a compensating control is a gap on the underlying NIST 800-171 requirement the Enduring Exception said would be handled.
Three patterns that fail the assessment.
Policy as control
The SSP states that vendors must authenticate before reaching OT systems, but nothing technically enforces it. A policy is not a compensating control unless a mechanism actively prevents the scenario.
Generic language
The description reads like a datasheet: enforces zero trust across all systems. The C3PAO asks which systems, which enforcement points, which logs. If the SSP cannot answer, the control is not verifiable.
Evidence that describes instead of demonstrates
A screenshot of the management console shows the policy exists. A log showing the policy acting on a real session shows it runs. Only the second counts.
The Affirming Official signs under the False Claims Act.
The Affirming Official certifies CMMC compliance under penalty of law. When they sign an SSP that invokes Enduring Exceptions for OT assets, they are certifying that the organization has implemented compensating controls to manage the risk those assets create. If the compensating controls are not technically implemented and verifiable, the certification is a statement of fact that may not be true.
Under 31 U.S.C. 3729 (the False Claims Act), a false claim can result in treble damages and per-claim penalties. The threshold is not intent to defraud. Reckless disregard or deliberate ignorance of the truth is sufficient. An SSP that lists Enduring Exceptions without corresponding compensating controls, or with controls that exist only on paper, creates measurable legal exposure for the Affirming Official and the organization.
How Access Gate provides the compensating control.
A compensating control must be technically implemented and verifiable, not just documented. Access Gate is an on-premise proxy that connects to your existing network, and traffic to OT assets is routed through it. It enforces identity-based access control, MFA, encryption, audit logging, and deny-by-default policies at the network layer. The OT asset does not need to be modified, updated, or replaced. The control is enforced before traffic reaches the device.
The Trout CMMC Shared Responsibility Matrix maps every NIST 800-171 control to a responsible party: customer, Trout, or shared. For OT assets invoking Enduring Exceptions, the matrix shows exactly which controls Access Gate satisfies, what evidence it produces, and what remains the customer's responsibility. This gives the Affirming Official a clear, auditable basis for their certification.
The Affirming Official checklist.
Seven yes/no questions. If you cannot answer yes to all seven, your Enduring Exception documentation has gaps.
Have you listed every OT asset invoking the Enduring Exception in the SSP?
For each exception, have you documented the specific control requirement and why the asset cannot comply?
Have you documented a compensating control and how it provides equivalent protection?
Is the compensating control technically implemented and verifiable, not just planned?
Can you produce evidence for your C3PAO (logs, policy configs, segmentation baselines) on demand?
Has the Affirming Official reviewed the compensating control evidence, not just the SSP narrative?
Is vulnerability scanning (RA 3.11.2) NA documented with a written rationale in the SSP?
See the shared responsibility matrix.
See exactly which NIST 800-171 controls Access Gate covers for your OT assets, what evidence it produces, and what remains your responsibility.
Need an inspectable reference for the CUI enclave side? Open-CMMC is our Apache-2.0 hardened file browser for on-prem CUI storage, with per-control SSP evidence.
Questions about CMMC exceptions.
CMMC lets a contractor record an Enduring Exception in the System Security Plan when an asset cannot meet a requirement and remediation is not feasible. The exception is not a waiver. Each one must name the asset and the control, explain the technical limit, and point to a compensating control that is implemented and produces evidence.
You cannot rely on a control you intend to build later. The compensating control must be in place and producing evidence when you affirm and when you are assessed. A planned control is a gap, and a gap belongs in a POA&M, not an Enduring Exception.
Yes. If one PLC cannot do MFA, audit logging or encryption, each control needs its own entry in the SSP. Assessors often treat a production cell or line segment as one system, which cuts the number of entries, but each entry still needs all six elements.
Rarely. It is meant for assets with structural limits, such as OT, IoT, test equipment and government-furnished equipment. An IT server that could run an agent but does not have one installed does not qualify.
Policy configurations, session logs, segmentation baselines, denied-access records and network diagrams showing the compensating architecture. Narrative descriptions alone are not enough.
RA 3.11.2 is usually documented as not applicable for OT assets that cannot be actively scanned without risk to production. The SSP must include a written rationale.
Yes. The Department of War suspended Phase II third-party assessments in July 2026. The NIST SP 800-171 obligation in DFARS 252.204-7012 still applies, and contractors still post and affirm a score in SPRS. That affirmation covers your exceptions and their compensating controls.