TroutTrout
Back to Blog
CMMCSSPOT SecurityLegacy PLCs

How to Write an SSP Section for a Network with Legacy PLCs

Trout Team4 min read

Your SSP must describe how each NIST 800-171 control is implemented in your environment. For networks with legacy PLCs, this means documenting the asset, its limitations, the compensating control, and the evidence. Here is how to structure each section.

SSP Structure for Legacy PLC Networks

Each control section in your SSP should follow this pattern when legacy PLCs are involved:

1. System Boundary Description

Start by defining the boundary. Name the network segment, the assets within it, and the data flows. Be specific:

"The CNC production network contains 12 Allen-Bradley CompactLogix PLCs, 4 Fanuc Series 0i CNCs, and 2 Siemens S7-1500 PLCs. These assets process CUI as part of DoD contract [number]. The network segment connects to the enterprise LAN through an Access Gate appliance at [IP]. All traffic to and from these assets passes through the Access Gate proxy."

2. Asset Inventory Table

Include a table listing each asset:

Asset IDTypeMake/ModelProtocolCUI ContactEnduring Exception
PLC-001PLCAB CompactLogixEtherNet/IPYesIA 3.5.3, AU 3.3.1
CNC-003CNCFanuc 0iModbus TCPYesIA 3.5.3, SC 3.13.8

Assessors treat the larger system as the asset. If PLC-001 is a component of Production Line A, list Production Line A as the assessed asset.

3. Per-Control Documentation

For each control that requires an Enduring Exception, write three paragraphs:

The control requirement. State the NIST 800-171 control text.

The limitation. Explain why the asset cannot comply. Be technical and factual:

"IA 3.5.3 requires multi-factor authentication. PLC-001 runs firmware version 32.011 on EtherNet/IP with no identity stack. It accepts any TCP connection on port 44818 without authentication. The firmware cannot be updated to add MFA support. Replacing the device would require production line requalification and an estimated 3-week shutdown."

The compensating control. Describe the alternative and reference the evidence:

"Access Gate enforces MFA at the proxy layer for human sessions. Operators, engineers, and vendors must authenticate through the identity gateway with username/password plus TOTP token before the proxy establishes the connection to PLC-001. Machine-to-machine sessions (e.g., a historian polling the device) authenticate with a mutual TLS certificate or scoped service-account credential bound to a named service identity, and are logged identically. The PLC never receives unauthenticated traffic. Evidence: Access Gate policy rule [ID], sample session log [attachment], denied-access log [attachment]."

4. Evidence Attachments

For each compensating control, attach or reference:

  • Policy configuration export showing the specific rule
  • Session log sample showing MFA enforcement in action
  • Denied-access log showing blocked unauthorized attempts
  • Network diagram showing the proxy architecture and isolation boundaries
  • Segmentation baseline showing the micro-DMZ around the asset

5. Vulnerability Scanning Section

NIST 800-171 RA 3.11.2 requires vulnerability scanning. For OT assets that cannot be actively scanned without operational risk, document:

"Active vulnerability scanning of PLC-001 is classified as Not Applicable due to operational risk. EtherNet/IP scanning has caused unplanned controller faults in testing. Compensating measure: passive network monitoring via Access Gate provides continuous asset visibility, protocol analysis, and anomaly detection without active probing. See passive monitoring configuration [attachment]."

Common Mistakes to Avoid

Vague language. "We segment our OT network" is not documentation. Name the segmentation technology, the assets it covers, and the policy rules.

Missing evidence references. Every compensating control claim must point to a specific, retrievable artifact. Assessors will ask for it.

Planned controls. Do not document controls you intend to implement. The SSP describes what is in place now.

Conflating systems and components. Document at the system level (CNC mill, production line), not the component level (individual PLC). But still list component-level technical limitations.

Ignoring the Affirming Official. Your Affirming Official must review the compensating control evidence, not just approve the SSP text. Document the review date and the reviewer.


For more CMMC resources, case studies, and implementation guides, visit the CMMC Compliance for On-Premise hub.

FAQ

Frequently Asked Questions

How long should the SSP section be for a network with 20 PLCs?
Group PLCs into systems. A production line with 5 PLCs is one asset. A typical shop floor with 20 PLCs might result in 4-6 assessed systems, each with 2-3 pages of SSP documentation including evidence references.
Can I use a template for all PLCs?
You can use a consistent format, but each asset or system needs its own specific documentation. The limitation, compensating control, and evidence must be asset-specific.
What if my PLC does not handle CUI directly?
If the PLC is on a network segment where CUI flows, it is in scope. Even if the PLC itself does not process CUI, it could be used as a pivot point. Document its presence and the controls that protect the segment.
Do I need to re-document if I add a new PLC?
Yes. Any change to the system boundary requires an SSP update. New assets need to be inventoried, and their controls (or Enduring Exceptions) documented.
What format do assessors prefer for evidence?
PDF exports of policy configurations, CSV or JSON session logs, and network diagrams in any standard format. The key is that evidence must be retrievable on demand during the assessment.