After an OT incident, IT teams often expect to pull logs from a PLC the way they would from a Windows server. That expectation ends in frustration. PLCs store minimal forensic data, often only the last few hundred to thousand events depending on manufacturer and model. Understanding what a PLC can and cannot tell you is essential to post-incident investigation.
Most PLCs retain ladder logic scans, memory changes, and I/O events in circular buffers. When the buffer fills, old events are overwritten. A PLC that's been running for weeks or months may have no record of an intrusion that happened 10 days ago. That's different from IT systems, where you can often pull 90 days of event logs. In OT forensics, you work with what the hardware provides, and you assume that critical evidence has been lost.
What You Can Actually Recover
Firmware extraction is often the highest-value forensic activity on a PLC. If an attacker modified the application logic or injected persistent code, the current firmware is your primary evidence. You extract this by reading directly from the controller's flash memory or by using manufacturer diagnostic tools. Some manufacturers allow this over the engineering interface; others require physical access to EEPROM chips. This is where hardware expertise matters.
Memory dumps and the ladder logic currently loaded in the PLC's RAM are also valuable. These show you what the controller was executing at the time of capture. Compare this to a known-good baseline or to the PLC's configuration documentation. Any deviation could indicate compromise. However, memory is volatile—if the PLC loses power or undergoes a restart during evidence collection, that data is gone forever.
Critical Forensic Constraints
- Live forensics require extreme care: Stopping a PLC to extract memory could initiate failover to another system or trigger emergency procedures. Coordinate with operations and understand the safety implications before you collect anything.
- No commercial forensic tools apply: EnCase and FTK are designed for Windows and Linux file systems. They're useless on a Siemens S7-1200. You must use manufacturer tools or hardware readers.
- Vendor cooperation is inconsistent: Some manufacturers provide diagnostic software that logs all operations. Others provide almost nothing. Know your equipment's capabilities before an incident strikes.
- Chain of custody is harder: Many OT forensic activities require physical access to the controller or access via serial consoles and proprietary cables. Documenting this activity clearly is your responsibility.
Building Your Forensic Readiness
Begin now by documenting your PLC inventory: manufacturer, model, firmware version, and which diagnostic tools you have access to. Create a hardware forensics kit—cable connectors, USB-to-serial adapters, and extraction tools appropriate for each major platform you operate. Train at least one member of your OT team on how to safely extract memory and firmware without disrupting operations. Run this procedure quarterly on lab equipment so the process is smooth if you need it under pressure.
Post-incident forensics on OT systems is a specialized discipline. If your team hasn't done it before, the incident response window is not the time to learn. Our forensic specialists have recovered evidence from Rockwell CompactLogix, Siemens SIMATIC, and ABB controllers in real breaches. We can help you prepare now and support you if an incident requires investigation. Reach out to discuss a forensics readiness assessment.
This article was written by the Cascadia OT Security practice, which advises Pacific Northwest data centers and manufacturers on industrial cybersecurity. For engagement inquiries, reach our practice team.