The Audit Problem in OT
An auditor asks: "Show me who accessed PLC-14 on March 3rd and what commands they executed."
In most OT environments, this question is unanswerable. Here is why:
- Shared accounts: Operators log into HMIs with a shared "operator" account. Three shifts, twelve people, one username.
- VPN-based vendor access: The vendor connects through a site-to-site VPN. The firewall log shows a connection from the vendor's IP range. It does not show which individual connected or what they did.
- No command-level logging: SCADA historians record process values. Syslog captures network events. Neither records the specific commands a user sent to a PLC or the screens they navigated on an HMI.
- No session attribution: Even when logs exist, they are tied to IP addresses or shared accounts, not to authenticated individuals.
This gap is not theoretical. It is the specific gap that CMMC and NIS2 auditors will flag.
What the Regulations Require
CMMC Requirements
AU.L2-3.3.1 (Audit Events): Create and retain system audit logs and records to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. With the CMMC October 2026 deadline requiring third-party certification, meeting this control is time-critical.
AU.L2-3.3.2 (Audit Content): Ensure that actions of individual system users can be uniquely traced back to those users.
AC.L2-3.1.7 (Privileged Functions): Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
The key word in 3.3.2 is individual. Shared accounts do not satisfy this control. IP-address-based logging does not satisfy this control. You need per-user, per-session traceability.
NIS2 Requirements
Article 21 mandates cybersecurity risk-management measures including incident handling. Specifically:
- Organizations must implement measures for incident detection, response, and recovery
- Evidence must be preserved and available for post-incident analysis
- Supply chain security measures must include monitoring of third-party access
When a vendor session to a PLC causes a process disruption, NIS2 requires that you can reconstruct exactly what happened, who did it, and when.
How Session Recording Works
Session recording in a proxy-based architecture captures the full content of every connection between a user and an OT asset. The proxy intercepts the session, so recording happens transparently, without any software on the endpoint.
The recording chain:
- User authenticates to the Access Gate with MFA. Identity is verified and bound to the session.
- Policy is evaluated. The system checks whether this user is authorized to access this asset, at this time, with this protocol.
- Session is established. The proxy opens a mediated connection to the target device.
- Full session is recorded. For RDP/VNC sessions: screen capture. For SSH sessions: terminal commands and output. For Modbus/OPC UA: protocol-level commands and responses.
- Session is indexed. The recording is stored with metadata: user identity, target asset, protocol, start time, end time, duration.
The result is a searchable, attributable record of every interaction with every OT asset.
Mapping Session Recording to Compliance Controls
| Compliance Requirement | Control ID | What Auditors Ask For | How Session Recording Delivers |
|---|---|---|---|
| Audit event creation | CMMC AU.L2-3.3.1 | Logs of all access to CUI systems | Every session is logged with user, asset, protocol, timestamp |
| Individual traceability | CMMC AU.L2-3.3.2 | Proof that actions trace to individuals | MFA-authenticated users bound to recorded sessions |
| Privileged function logging | CMMC AC.L2-3.1.7 | Logs of admin/engineering actions | Write operations, configuration changes captured at protocol level |
| Least privilege enforcement | CMMC AC.L2-3.1.5 | Evidence of access restrictions | Policy engine restricts per-user, per-asset, per-operation access |
| Incident detection and response | NIS2 Article 21(b) | Incident handling procedures with evidence | Recorded sessions provide forensic evidence for incident reconstruction |
| Evidence preservation | NIS2 Article 21 | Retained logs for post-incident analysis | Session recordings stored with configurable retention, tamper-evident |
| Supply chain monitoring | NIS2 Article 21(d) | Vendor access controls and audit trail | Third-party sessions recorded with same fidelity as internal sessions |
| Risk management reporting | NIS2 Article 21(a) | Demonstrable security controls | Session recording dashboards show access patterns and policy enforcement |
What Session Recording Captures by Protocol
Different protocols yield different types of audit data:
| Protocol | Session Type | What Gets Recorded |
|---|---|---|
| RDP / VNC | HMI access, engineering workstations | Full screen capture (video), keystrokes, clipboard activity |
| SSH | Linux-based controllers, network devices | Terminal commands, output, file transfers |
| Modbus TCP | PLC communication | Function codes (read vs. write), register addresses, values |
| OPC UA | SCADA to PLC, historian connections | Node access, read/write operations, browse activity |
| HTTP/HTTPS | Web-based HMIs, device management | URLs, form submissions, API calls |
This protocol-level granularity is what separates session recording from network logging. A firewall log tells you that a Modbus TCP connection occurred. Session recording tells you that User X sent a Write Single Register (function code 06) command to register 40001 with value 1, changing the setpoint of a pump.
Practical Deployment Guide
Rolling out session recording across an OT environment does not need to happen all at once. A phased approach reduces risk and builds organizational confidence.
Phase 1: Vendor Remote Access (Week 1-2)
Start here. Vendor sessions are the highest-risk, highest-visibility target.
- Route all vendor remote access through the Access Gate
- Enable session recording on all vendor sessions
- Require MFA for every vendor connection
- Set retention policy (90 days minimum for CMMC, align with NIS2 requirements)
Why this first: Vendors access critical assets, often with elevated privileges, through shared credentials. This is the gap that auditors look for first.
Phase 2: Internal Engineering Access (Week 3-4)
Extend recording to internal engineers and operators accessing PLCs and HMIs.
- Define per-user access policies (who can access which assets)
- Enable recording on engineering workstation sessions
- Implement protocol-aware policies (e.g., allow read, block write during production hours)
Phase 3: Full Coverage (Month 2-3)
Expand to all OT access paths.
- Record all sessions to SCADA servers and historians
- Integrate session logs with SIEM for correlation
- Generate compliance reports mapping sessions to control requirements
- Conduct a mock audit using recorded sessions as evidence
What to Expect from Auditors
When a CMMC assessor or NIS2 auditor reviews your OT environment, they will ask for:
- Access logs showing who accessed which systems and when
- Evidence of individual attribution (not shared accounts)
- Proof of least-privilege enforcement (users restricted to authorized assets)
- Incident response evidence (ability to reconstruct what happened during a security event)
Session recording provides a single, searchable source of evidence for all four. Instead of stitching together firewall logs, VPN logs, SCADA historian entries, and Windows event logs, you point the auditor to a recorded session with the user's name, the target asset, and the full content of their interaction.
Stop treating OT access as a network problem. Treat it as an identity problem with session-level evidence. For a deeper look at why a proxy-based architecture is the right foundation for session recording in OT, start there. That is what auditors expect, and that is what compliance frameworks require.
For more CMMC resources, case studies, and implementation guides, visit the CMMC Compliance for On-Premise hub.
For more NIS2 resources, sovereign deployment options, and compliance guides, visit the NIS2 Compliance for On-Premise OT hub.
