CMMC Enduring Exception for OT
Your PLC cannot enforce MFA. Your CNC cannot generate audit logs. Your HMI cannot encrypt Modbus traffic. The Enduring Exception documents this. The compensating control proves you managed the risk.
What Is the CMMC Enduring Exception?
The CMMC Enduring Exception is a mechanism that allows a defense contractor to document, in their System Security Plan (SSP), that a specific asset cannot natively implement a specific NIST 800-171 requirement due to hardware or firmware limitations. It applies to assets like PLCs, CNCs, HMIs, and legacy industrial equipment that were never designed with cybersecurity controls built in.
The Enduring Exception is not a waiver. It does not remove the obligation to protect CUI. It shifts the burden from the asset to a compensating control that must be documented, implemented, and verifiable.
What the Enduring Exception Legitimately 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.
The Compensating Control Requirement
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 | PLCs, CNCs, and HMIs 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 OT asset. The user authenticates through the identity gateway. The PLC 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 OT equipment generates no audit logs. There is no syslog daemon, no event buffer, and no mechanism to record who accessed the device, when, 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. The device firmware cannot be updated to support TLS. Replacing the device 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 | OT assets have no identity layer. A PLC accepts any connection on its open port. There is no concept of user accounts, roles, or permission sets on the device 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 | OT devices accept any inbound connection. They do not implement firewalls, allowlists, or connection filtering. Any host on the network segment can reach the device. | 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
PLCs, CNCs, and HMIs 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 OT asset. The user authenticates through the identity gateway. The PLC 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 OT equipment generates no audit logs. There is no syslog daemon, no event buffer, and no mechanism to record who accessed the device, when, 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. The device firmware cannot be updated to support TLS. Replacing the device 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
OT assets have no identity layer. A PLC accepts any connection on its open port. There is no concept of user accounts, roles, or permission sets on the device 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
OT devices accept any inbound connection. They do not implement firewalls, allowlists, or connection filtering. Any host on the network segment can reach the device.
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.
False Claims Act Exposure
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 Closes the Gap
A compensating control must be technically implemented and verifiable, not just documented. Access Gate is deployed as an on-premise proxy between the IT network and OT assets. 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.
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?
Download 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.