People ask me the same question often enough that it's worth writing down properly: how do you actually learn OT cybersecurity? The honest answer is "slowly, with help, while doing something else for a living" — but that's not very useful. So let me try to be more specific.
The shape of the journey depends on where you start. Three common entry points: from IT security, from network engineering, or from control engineering. The destination is the same — a practitioner who can sit in a kickoff meeting with a plant manager and an OT vendor and not embarrass themselves. The paths are different.
If you're coming from IT security
Your strength is the cybersecurity body of knowledge — threat modeling, controls frameworks, incident response, identity and access management. Your weakness is that you've internalized IT's priorities (confidentiality first, availability third) and that you assume devices behave like servers. Both assumptions break.
The first thing to unlearn is "patch fast." OT runs on a different cadence and the reasons are real. The second thing to unlearn is "scan everything." Active scanning on level-2 OT networks crashes devices. The third thing to unlearn is "user accounts are the access boundary." In OT, the access boundary is physical — and the user-account story is, charitably, a work in progress.
What to learn first: the Purdue model as a mental map of where things live and why. Once you can locate an asset on the Purdue model, the controls discussion gets easier. From there: SCADA vs. DCS vs. PLC vs. RTU — what they are, what they do, when each shows up. Then IEC 62443 for the framework that maps your existing controls knowledge onto OT-specific requirements (foundational requirements, security levels, zones and conduits).
Get hands-on as fast as you can. The cheapest way is a packet capture from a real OT network — many vendors share sample PCAPs of Modbus, BACnet, IEC 61850 traffic. Open them in Wireshark. Read the protocols. The protocols are what make OT feel foreign; the moment they stop feeling foreign, you've crossed a real threshold.
If you're coming from network engineering
You have a head start. Network architecture, segmentation, firewalling, routing — the muscle memory transfers. The gap is the cybersecurity body of knowledge: threats, controls, frameworks. And the OT-specific bits: which protocols matter, what's deterministic about a control network that isn't deterministic in an enterprise LAN, why a SPAN port is suddenly a load-bearing piece of security architecture.
Start with the cybersecurity fundamentals — CIA triad, threat modeling, risk assessment — but invert them. Availability first. Read a CISSP-equivalent book just enough to know the vocabulary; don't bother memorizing for the exam unless you want the certification for the resume. From there, the same path as the IT-security folks above: Purdue, controls, protocols.
Your secret weapon is reading architecture diagrams. Plant network diagrams are dense, vendor-specific, and full of unstated assumptions. Get good at reading them. Ask the dumb questions. The diagram in the binder is rarely the network that actually exists, and your job is going to involve mapping the gap.
If you're coming from control engineering
You know more about the process than most "OT cybersecurity experts" ever will. What you don't yet know is how an attacker thinks. The risk for you is in the opposite direction: you'll be tempted to defend the system you understand intimately by handwaving the threats you've never had to think about. Don't.
Read the threat side. The Triton/Trisis case study — read everything written about it. The Industroyer and Industroyer2 case studies. Understand how they actually worked, what was wrong with the defenses, what minimal changes would have stopped them. Read until you can explain the kill chain on a whiteboard.
Then learn enough IT security to communicate. CIA triad, IAM, encryption fundamentals, network controls. You don't need depth; you need fluency. Your value is at the intersection — the person who can sit between the security team and the operations team and translate. That's a rare skill and a well-paid one.
What everyone gets wrong
Certifications are not the journey, they're a milestone. The GICSP, the IEC 62443 cert, the vendor-specific certs — they're useful, they signal commitment, they unlock doors. They don't make you good at the work. People who pass the cert and then go quiet for a year because they haven't been hands-on are common. Don't be that.
Theory without packets is hollow. If you've never read a Modbus capture, you don't really understand Modbus. If you've never traced a GOOSE message through an IEC 61850 substation network, you don't really understand IEC 61850. The vocabulary stays slippery until you've seen the actual bytes.
Vendor training is necessary but not sufficient. Vendor-specific training is excellent for learning that vendor's product. It's not the same as understanding the OT cybersecurity field. Take vendor training when you'll use the product; don't mistake it for an OT security curriculum.
The community is small and willing. OT cybersecurity is small enough that the people doing it are usually generous with their time. Show up to S4, ICS Village, Black Hat ICS track, ICS-CERT briefings. Ask questions. Don't pretend to know things you don't — the field is small enough that you'll get caught, and people remember.
A rough year-one plan
If you have a year to give this seriously, while doing your day job:
- Months 1–2 — Vocabulary. Purdue model, ICS/SCADA terminology, IT vs OT, the major protocols by name. A good book or course should land this. (Plug: this is what Part 1 of my course is for.)
- Months 3–4 — Protocols. Modbus, BACnet, IEC 61850, IIoT/MQTT. Read captures. Map message flows. Start to recognize anomalies.
- Months 5–6 — Architecture. Read plant network diagrams. Practice locating assets on the Purdue model. Learn DMZ design, data diodes, OOB management, secure remote access patterns.
- Months 7–8 — Frameworks. IEC 62443 in depth. Foundational requirements, security levels, zones & conduits, capability maturity. Risk assessment as actually done.
- Months 9–10 — Controls. OT NIDS in practice. NGFW placement. IAM in OT. Patch strategy. Compensating controls. Read incident reports and reverse-engineer the controls that would've stopped them.
- Months 11–12 — Apply it. Engage with a real system if you can — your employer's, a lab, a vendor's training rig. Run an actual assessment end-to-end. Write it up. The write-up is where you'll discover what you don't understand.
Year two is depth. Pick a sector — substations, oil & gas, pharma, water, manufacturing — and go deep on its protocols, its regulators, its incident history, its people. Specialization compounds.
The blunt summary
OT cybersecurity isn't a different discipline from cybersecurity; it's cybersecurity with a different priority order, a different vocabulary, and very different blast radii. The journey to competence is faster than you'd think if you're disciplined about the foundations, hands-on with the protocols, and humble about what you don't know. The fastest accelerant is teaching it back — write articles, give talks, run study groups. You'll find out very quickly what you understand and what you don't.
Start where you are. Be specific. Get to packets early. Find people doing the work and ask them questions. The path is shorter than it looks.
The progressive structure described above maps closely to the four-part structure of the OT Cybersecurity Professional course — Fundamentals, Communications, Common Industries, OT Cybersecurity. See the full curriculum.