Cheat sheet: independent review for CompTIA SecOT+ V1 (SOT-001): OT architecture, controls, monitoring, incident response, risk, and exam decision points.
Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.
Scope and study context
Item
Detail
Vendor / provider
CompTIA
Official exam title
CompTIA SecOT+ V1 (SOT-001)
Official exam code
SOT-001
Review focus
Security of OT, ICS, industrial environments, and supporting IT/OT operations
Best next study step
Use original practice questions to test decisions under scenario pressure
For efficient SOT-001 preparation:
Review the tables above for 20–30 minutes.
Start with topic drills on OT architecture, asset inventory, segmentation, and incident response.
After each missed question, write down the decision rule you missed.
Use original practice questions to force scenario-based judgment, not memorization.
Move to mixed sets only after your weak topics are improving.
Use detailed explanations to compare your reasoning with the safest operational answer.
Finish with timed mock exams to practice pacing and decision confidence.
CompTIA SecOT+ V1 (SOT-001) Exam Focus
Use this Cheat Sheet as independent review support for CompTIA SecOT+ V1 (SOT-001). It is organized around high-yield operational technology security decisions: architecture, monitoring, controls, vulnerability handling, identity, remote access, incident response, and risk.
Core Exam Mental Model
If the question says…
Think first
Common trap
Plant floor, controller, safety impact, production outage
OT/ICS risk, safety, availability
Applying pure IT response without process approval
Legacy protocol, PLC, HMI, RTU, DCS
Compensating controls and segmentation
Assuming encryption/authentication exists
Vendor remote support
MFA, PAM, jump host, time-bound access, logging
Direct VPN into control network
Suspicious controller write
Engineering workstation validation, change window, process impact
Blocking traffic without operations coordination
Vulnerability on critical OT asset
Risk-based patching, testing, maintenance window
Scanning/patching aggressively like IT endpoints
Need visibility without disruption
Passive discovery, SPAN/TAP, OT-aware IDS
Active scanning of fragile controllers
IT/OT data sharing
Industrial DMZ, broker/historian replica, least privilege
Direct enterprise-to-PLC access
IT vs OT Security Priorities
Area
IT emphasis
OT/ICS emphasis
SOT-001 decision point
Primary objective
Data protection and business services
Safety, availability, process integrity
Do not choose controls that endanger safe operations
CIA priority
Often confidentiality first
Availability and integrity often first
Confidentiality still matters, but downtime can be critical
Change frequency
Frequent patching and updates
Controlled, tested, scheduled changes
Prefer maintenance windows and rollback plans
Asset lifecycle
Shorter refresh cycles
Long-lived equipment, legacy OS/protocols
Use compensating controls when upgrades are impractical
Technology that monitors or controls physical processes.
ICS
Industrial control system; broad category including SCADA, DCS, PLCs, RTUs, HMIs, and related systems.
SCADA
Supervisory control and data acquisition; often geographically distributed.
DCS
Distributed control system; commonly used in plants and continuous processes.
PLC
Programmable logic controller; directly controls equipment and logic.
RTU
Remote terminal unit; common in remote monitoring/control environments.
HMI
Human-machine interface; operator workstation for viewing and controlling processes.
Engineering workstation
Used to program/configure PLCs and control devices; high-value target.
Historian
Collects and stores process data; often bridges OT and enterprise reporting.
SIS
Safety instrumented system; designed to move process to safe state. Treat as highly critical.
Sensors and actuators
Field-level devices that measure and affect the physical process.
Jump server
Controlled access point into OT networks; should be monitored and hardened.
OT DMZ
Buffer zone between IT and OT networks; reduces direct connectivity.
Conduit
Controlled communication path between zones.
Zone
Group of assets with similar trust level, function, or risk.
Purdue Model Cheat Sheet
The Purdue model is a common way to reason about industrial environments. Exact implementations vary, but the concept is high-yield: separate enterprise IT, OT operations, control systems, and field devices.
Watch for unauthorized configuration/control traffic
PROFINET
Industrial Ethernet automation
Real-time industrial communication
Availability and segmentation are key
BACnet
Building automation
May expose HVAC/building controls
Treat facilities systems as security-relevant
MQTT
Publish/subscribe telemetry
Broker security, TLS, client auth, topic ACLs
Broker compromise can expose many devices
SNMP
Device monitoring
Weak community strings in older versions
Prefer secure versions/configuration
RDP/SSH/VNC
Remote administration
Credential theft and lateral movement
Use jump hosts, MFA, logging, allowlists
Security Control Selection Matrix
Need
Best-fit control
Why
Watch for
Discover assets safely
Passive asset discovery
Reduces risk to fragile OT devices
May miss powered-off or silent assets
Stop direct IT-to-OT access
Segmentation and industrial DMZ
Limits lateral movement
VLAN alone is not a complete security boundary
Control vendor sessions
PAM + MFA + jump host
Named, approved, recorded access
Shared vendor accounts reduce accountability
Detect unauthorized PLC writes
OT-aware IDS/NDR
Understands industrial protocols
Generic IDS may miss process-specific commands
Prevent unknown executables
Application allowlisting
Useful for stable engineering/HMI systems
Requires controlled change process
Protect legacy unpatchable assets
Compensating controls
Reduces exposure without unsupported changes
Does not remove the underlying vulnerability
Secure removable media
USB control and scanning kiosk
Common OT infection path
Blanket bans may fail operationally without alternatives
Reduce credential abuse
Least privilege, RBAC, MFA
Limits blast radius
MFA must be compatible with uptime and emergency access
Preserve evidence
Central logs, time sync, packet capture
Supports investigation
Unsynchronized clocks weaken timelines
Recover controller state
Logic/config backups
Enables validated restoration
Backups must be tested and versioned
Segmentation and Network Security
Segmentation Options
Control
Strength
Best use
Limitation
VLAN
Logical separation
Traffic organization
Not sufficient alone against routed access
ACL
Basic traffic filtering
Restrict known flows
Can become hard to manage
Firewall
Stateful boundary control
Zone-to-zone enforcement
Rules must be specific and reviewed
Industrial firewall
OT-aware filtering
Protocol-aware control near cells/areas
Requires OT protocol understanding
Data diode
Unidirectional flow
High-assurance outbound data transfer
Not for interactive control
Microsegmentation
Fine-grained host/workload policy
Sensitive servers and mixed environments
More operational complexity
NAC
Device admission control
Prevent rogue devices
Legacy OT compatibility issues
Air gap
Physical/logical isolation
Very high-risk environments
Often eroded by USB, laptops, vendors, temporary links
Notes and examples
Zone and Conduit Thinking
Concept
Meaning
Exam application
Zone
Group of assets with similar risk/security requirements
HMI zone, controller cell, historian zone
Conduit
Controlled communication path between zones
Firewall rule, proxy, gateway, data diode
Least functionality
Only required services/protocols are enabled
Disable unused ports and services
Default deny
Block unless explicitly allowed
Stronger than broad allow rules
Trust boundary
Point where security assumptions change
IT/OT boundary, vendor access, cloud bridge
Segmentation and Network Architecture
Segmentation limits blast radius and controls who can communicate with critical OT assets.
Strong Segmentation Patterns
Pattern
Purpose
OT DMZ
Prevents direct IT-to-OT communication
Jump server
Centralizes and logs administrative access
Firewall between zones
Enforces allowed conduits
Data diode / unidirectional gateway
Allows one-way data flow where appropriate
Separate identity boundary
Reduces enterprise domain compromise impact
Remote access broker
Controls vendor and engineer sessions
Industrial IDS sensor
Monitors traffic without disrupting operations
Management network
Separates administration from process control traffic
Egress allowlisting
Prevents uncontrolled outbound connections
Network access control
Helps restrict unauthorized devices where feasible
Segmentation Decision Path
flowchart TD
A[Need communication between IT and OT?] --> B{Is it required for operations?}
B -- No --> C[Deny by default]
B -- Yes --> D{Can data flow be one-way?}
D -- Yes --> E[Use broker, data diode, or controlled publish path]
D -- No --> F[Use OT DMZ or jump host]
F --> G[Apply MFA, least privilege, logging]
G --> H[Restrict ports, protocols, source, destination]
H --> I[Monitor and review periodically]
Segmentation Traps
“Flat but firewalled at the perimeter” is not enough.
VLANs help organize traffic but do not replace policy enforcement.
Remote access should not land directly on controllers.
Engineering workstations need extra protection because they can change control logic.
Historians and reporting servers can become pivot points.
Temporary vendor access often becomes permanent if not governed.
Identity, Access, and Remote Access
Topic
Correct approach
Common wrong answer
Operator access
Role-based access tied to duties
Everyone uses the same HMI admin login
Engineering access
Named accounts, approval, MFA/PAM, logging
Shared engineering account with no session trail
Break-glass access
Documented, monitored, tested emergency account
Untracked permanent local admin
Service accounts
Least privilege, noninteractive where possible, rotation plan
IF industrial_protocol_write
AND source NOT IN approved_engineering_workstations
AND destination IN controller_assets
THEN severity = high
AND action = validate_change_window + notify_OT_operations
IF new_asset_seen
AND zone == control_network
AND asset NOT IN approved_inventory
THEN severity = medium_or_high
AND action = identify_owner + check_physical_location + restrict_if_unapproved
IF remote_access_session
AND user_type == vendor
AND no_ticket_or_approval
THEN severity = high
AND action = suspend_session + notify_access_owner + review_recording
Monitoring, Detection, and Logging
OT monitoring should detect abnormal behavior while preserving availability.
High-Value Data Sources
Source
What it can reveal
Passive network sensors
New devices, unusual protocols, unexpected commands
Do not treat every anomaly as an immediate reason to block traffic. In OT, blocking the wrong flow can disrupt operations. The better answer is usually to validate with operations, check the baseline, assess safety impact, then contain carefully.
Vulnerability, Patch, and Change Management
Activity
IT-style instinct
OT-safe approach
Vulnerability scanning
Run authenticated scans broadly
Use passive discovery first; test active scans in lab
Segment, allowlist, restrict access, plan lifecycle replacement
Firmware updates
Apply to all devices
Validate vendor guidance, test device/process impact
Config changes
Admin applies directly
Use change ticket, peer review, backup, rollback
Emergency fix
Expedite normal process
Still document approval, risk, and recovery plan
Penetration testing
Test live production
Scope carefully; avoid unsafe actions on controllers
Baseline drift
Ignore small changes
Compare against approved golden configs
Notes and examples
Vulnerability Triage
Factor
Raises priority when…
Exploitability
Public exploit, remote access, no authentication
Exposure
Asset reachable from less trusted zone
Criticality
Controls safety, production, or essential service
Compensating controls
Weak or absent segmentation/monitoring
Patch feasibility
Patch is tested and low-risk
Active indicators
Exploitation attempts or suspicious behavior observed
Vulnerability and Patch Management
OT vulnerability management is risk-based. The goal is not simply to patch fastest; it is to reduce risk without causing unsafe or unplanned disruption.
OT Vulnerability Workflow
Identify affected assets.
Confirm process criticality and exposure.
Check vendor guidance and compatibility.
Test patches or firmware in a lab when possible.
Schedule maintenance windows.
Apply compensating controls if patching must wait.
Monitor for exploitation.
Document risk acceptance if required.
Validate operation after the change.
Risk Factors to Combine
Factor
Why it matters
Exploitability
Is there a working exploit or active exploitation?
Exposure
Is the asset reachable from untrusted networks?
Process criticality
Would compromise affect safety or production?
Compensating controls
Segmentation may reduce immediate risk
Vendor support
Unsupported patches can break systems
Maintenance window
Determines feasible remediation timing
Asset role
Engineering workstations and historians may be high-value pivots
Recovery capability
Backups and spares affect response options
Vulnerability Management Traps
Mistake
Better approach
“Patch immediately” for all OT devices
Use tested, scheduled, risk-based patching
Ignoring vulnerable assets because they are internal
Assess lateral movement and insider risk
Using only CVSS
Add exposure, exploitability, and process impact
Scanning production with default tools
Use passive discovery or approved safe scans
Applying vendor firmware without validation
Test and coordinate with operations
Forgetting compensating controls
Use isolation, ACLs, monitoring, and virtual patching
Incident Response in OT Environments
OT Incident Workflow
flowchart TD
A[Alert or report] --> B[Validate asset and process context]
B --> C{Safety impact?}
C -->|Yes| D[Engage operations/safety lead immediately]
C -->|No| E[Continue technical triage]
D --> F[Stabilize process if needed]
E --> G[Scope affected assets and network paths]
F --> G
G --> H{Containment could disrupt process?}
H -->|Yes| I[Plan containment with OT operations]
H -->|No| J[Apply approved containment]
I --> J
J --> K[Preserve evidence and logs]
K --> L[Eradicate, recover, validate]
L --> M[Lessons learned and control updates]
Likelihood and impact of threat exploiting vulnerability
OT impact includes safety, production, environment
Control
Safeguard reducing risk
Firewall, MFA, allowlisting, monitoring
Residual risk
Risk remaining after controls
Must be accepted by appropriate owner
Compensating control
Alternative safeguard when ideal control is impractical
Segmenting an unpatchable controller
Risk register
Tracked list of risks, owners, treatment plans
Should include OT asset criticality
BIA
Business impact analysis
Identifies process and operational dependencies
MOC
Management of change
Prevents unsafe or undocumented modifications
Notes and examples
Common Framework Concepts
Concept
Use
Exam-safe framing
ISA/IEC 62443 zones and conduits
OT segmentation and security levels
Common OT security architecture model
NIST CSF functions
Identify, Protect, Detect, Respond, Recover
Useful lifecycle structure
CIS Controls
Prioritized security safeguards
Adapt implementation for OT constraints
MITRE ATT&CK for ICS
Adversary tactics/techniques in ICS
Helps map detections and gaps
Policies, standards, procedures
Governance hierarchy
Policy says what; procedure says how
Audit evidence
Proof controls operate
Logs, approvals, configs, training records
Governance, Risk, and Documentation
Governance questions usually ask who approves decisions, how risk is documented, and how controls are sustained.
Useful Governance Artifacts
Artifact
Purpose
Network diagrams
Show zones, conduits, and dependencies
Asset inventory
Supports risk, patching, and response
Risk register
Tracks accepted and mitigated risks
Change records
Prove what changed, when, and why
Access reviews
Remove stale or excessive access
Incident playbooks
Guide coordinated response
Backup and recovery plans
Support restoration
Vendor access procedures
Control third-party risk
Maintenance schedules
Align security work with operations
Training records
Show staff readiness
Framework Awareness
Candidates should recognize that OT security programs often reference industry frameworks and guidance, such as NIST Cybersecurity Framework concepts, NIST SP 800-82-style ICS guidance, and IEC 62443-style zone/conduit thinking. For exam scenarios, focus less on memorizing framework labels and more on applying the control logic correctly.
Cryptography and Secure Communications
Control
Use
OT caveat
TLS
Encrypts/authenticates transport
Legacy devices may need gateway/proxy support
Certificates
Device/user/service identity
Requires lifecycle management and revocation plan
Hashing
Integrity verification
Does not provide confidentiality
Digital signatures
Authenticity and integrity
Useful for firmware/software validation
Encryption at rest
Protects stored data
Key storage is critical
Encryption in transit
Protects data on the wire
Does not authorize commands by itself
VPN
Encrypted tunnel
Must still enforce least privilege and logging
PKI
Certificate trust infrastructure
Operational complexity and expiry risk
Secure boot
Verifies trusted startup components
Hardware/firmware support required
Key rotation
Limits long-term credential exposure
Coordinate with uptime requirements
Physical and Environmental Security
Area
Security relevance
Practical controls
Control cabinets
Direct access to controllers and wiring
Locks, tamper seals, access logs
Plant floor ports
Rogue device risk
Port security, NAC where compatible, disabled unused ports
OT security is not only network security. Physical access to cabinets, ports, controllers, sensors, and engineering stations can create cyber and safety risk.
Area
Review focus
Control rooms
Badge access, visitor control, locked consoles
Cabinets
Locks, tamper evidence, port security
Field devices
Protection from tampering and environmental damage
USB ports
Removable media control and scanning stations
Network closets
Switch access, spare port control, cable management
Need to identify assets without disrupting production
Passive discovery
Aggressive active scan
Controller is vulnerable but cannot be patched
Segment, monitor, restrict access
Ignore vulnerability
Vendor needs emergency access
Time-bound MFA/PAM through jump host
Permanent firewall opening
Data must flow from OT to IT only
One-way gateway/data diode
Bidirectional VPN
Operator account shared by all shifts
Named accounts or compensating accountability
Keep shared admin for convenience
Ransomware in enterprise IT
Check IT/OT segmentation and remote access paths
Assume OT is safe because it is “separate”
Suspicious command during maintenance window
Validate change ticket and operator approval
Immediately declare compromise
New OT firewall rule request
Allow only required source, destination, port/protocol, time
Any-any rule for troubleshooting
Unexplained process change
Correlate cyber logs with operations and physical access
Review only Windows endpoint logs
Legacy HMI needs hardening
Allowlisting, restricted services, backups
Install untested endpoint tools directly in production
Quick Memorization Tables
Authentication, Authorization, Accounting
AAA element
Meaning
OT example
Authentication
Proves identity
MFA for engineer login
Authorization
Grants allowed actions
Engineer can program PLC; operator can view/control HMI
Accounting
Records activity
Session recording and command logs
Notes and examples
Control Types
Type
Purpose
Example
Preventive
Stop event before it occurs
Firewall rule, MFA, locked cabinet
Detective
Identify event
OT IDS, SIEM alert, camera
Corrective
Restore or fix
Backup restore, patch, reimage
Deterrent
Discourage action
Warning banner, visible cameras
Compensating
Alternative risk reduction
Segmenting unsupported controller
Administrative
People/process control
Policy, training, change approval
Technical
System-enforced control
ACL, encryption, allowlisting
Physical
Physical protection
Badge access, cabinet locks
IDS, IPS, SIEM, SOAR, NDR
Tool
Primary function
OT use
IDS
Detect suspicious activity
Passive alerting on industrial commands
IPS
Block traffic inline
Use cautiously where blocking can affect process
SIEM
Central log correlation
Cross-correlate OT, IT, identity, firewall logs
SOAR
Automate workflows
Automate enrichment/ticketing; be careful with auto-containment
NDR
Network detection and response
Build asset/traffic baselines and detect anomalies
Final SOT-001 Review Checklist
Know why OT security prioritizes safety, availability, and process integrity.
Map common assets to roles: PLC, RTU, HMI, SCADA, DCS, historian, engineering workstation, SIS.
Choose industrial DMZ, jump host, PAM, MFA, and session logging for controlled IT/OT and vendor access.
Prefer passive discovery and OT-aware monitoring before active scanning.
Treat unauthorized controller writes, new devices, and unexpected remote access as high-value alerts.
Use risk-based patching with testing, maintenance windows, backups, and rollback.
Protect legacy systems with segmentation, allowlisting, restricted services, and compensating controls.
Never choose an incident response action that ignores operations, safety, or process state.
Distinguish backup, HA, DR, RTO, RPO, immutable backup, and golden image.
For cloud/IIoT integration, prefer brokered, outbound, authenticated, logged data flows over direct OT exposure.
Notes and examples
Final Readiness Checklist
Before you sit for CompTIA SecOT+ V1 (SOT-001), confirm that you can explain:
Why OT security prioritizes safety, availability, and process integrity.
How the Purdue model supports segmentation decisions.
Why passive discovery is often preferred in production OT.
How to secure vendor remote access.
How to handle vulnerabilities when immediate patching is unsafe.
What makes engineering workstations high-value targets.
How an OT DMZ reduces IT/OT pivot risk.
What data sources support OT detection and response.
How ransomware can affect OT even if it starts in IT.
Why tested backups must include configurations and control logic.
How to coordinate incident response with operations and engineering.
Why compensating controls are central to legacy OT security.
Cheat Sheet for CompTIA SecOT+ V1 (SOT-001)
This Cheat Sheet is designed for candidates preparing for CompTIA SecOT+ V1 (SOT-001) who want a focused refresher before moving into topic drills, mock exams, and detailed explanations.
Use it to reinforce the highest-yield ideas: operational technology security priorities, industrial network architecture, asset discovery, segmentation, monitoring, vulnerability management, incident response, and common exam decision traps.
This is IT Mastery review support. It is not affiliated with CompTIA.
High-Yield Mindset
OT security questions often test whether you can protect systems without disrupting physical processes.
The OT Priority Shift
In many IT environments
In many OT environments
Confidentiality is often emphasized first
Safety and availability often dominate
Systems can usually be patched more frequently
Patching may require testing, outage windows, or vendor approval
Active scanning is common
Active scanning can disrupt fragile devices
Endpoint agents are common
Agents may be unsupported or risky on control systems
Reimaging is routine
Reimaging may require validated configurations and process owner approval
Data loss is a major concern
Loss of view, loss of control, unsafe state, or downtime can be critical
Practical Exam Rule
When a scenario involves production OT:
Protect human safety first.
Preserve process availability and integrity.
Coordinate with operations, engineering, and asset owners.
Prefer passive visibility before intrusive testing.
Use segmentation, compensating controls, and change control when patching is not immediately possible.
Certificate-based auth, least privilege, egress control
Unrestricted outbound Internet access
Incident in active process
Safety-first response with operations lead
Pure IT-only incident playbook
Asset Inventory and Baselines
Asset inventory is foundational because OT environments often contain legacy systems, vendor-managed devices, undocumented connections, and fragile protocols.
A baseline is the known-normal state of assets, configurations, communications, and process behavior.
High-yield baseline examples:
PLC-to-HMI communication patterns
Engineering workstation programming activity
Historian polling intervals
Normal remote access windows
Expected protocol commands
Usual bandwidth and connection pairs
Normal operator login times
Approved firmware and logic versions
Common Inventory Mistakes
Relying only on spreadsheets that are never reconciled.
Using aggressive discovery tools on fragile production networks.
Tracking IP addresses but not process criticality.
Ignoring temporary vendor connections.
Failing to document PLC logic, firmware, and configuration backups.
Treating OT assets as if they are owned only by IT.
Industrial Protocols: What to Recognize
You do not need to memorize every packet field to answer many exam scenarios. Focus on the security implications.
Protocol / technology
Common context
Security review point
Modbus / Modbus TCP
Industrial control communication
Often lacks native authentication or encryption in legacy use
DNP3
Utilities and remote control
Secure variants may exist, but legacy deployments require protection
EtherNet/IP
Industrial automation
Segment and monitor command behavior
PROFINET
Industrial Ethernet
Protect controller and device communication paths
OPC DA
Legacy Windows-based data exchange
Often difficult to secure; isolate and control access
OPC UA
Modern industrial interoperability
Can support stronger security when configured correctly
IEC 61850
Power systems/substations
High criticality; protect timing and control messages
BACnet
Building automation
Watch for exposed building systems and weak segmentation
MQTT
IIoT messaging
Secure broker, authentication, authorization, and TLS matter
Serial protocols
Legacy control systems
May be bridged to IP; gateway security becomes important
Time sync protocols
Process coordination and logging
Protect against time manipulation and preserve forensic value
Notes and examples
Protocol Trap
If a protocol lacks built-in security, the best answer is usually not “encrypt the PLC” in isolation. The better control is often layered:
Segment the network.
Restrict allowed communication pairs.
Use protocol-aware firewalls or monitoring.
Place gateways in controlled zones.
Authenticate remote users and systems.
Monitor for abnormal commands.
Use secure protocol variants where feasible and supported.
Identity, Access, and Privileged Operations
OT access control must balance accountability, safety, and operational continuity.
Control
OT-specific review point
MFA
Strongly preferred for remote and privileged access
PAM
Controls and records privileged sessions
RBAC
Assigns access by role: operator, engineer, vendor, admin
Least privilege
Users get only the access needed for their function
Named accounts
Improve accountability compared with shared accounts
Break-glass accounts
Must be protected, documented, monitored, and tested
Session recording
Useful for vendor and privileged access review
Time-bound access
Reduces risk from standing privileges
Account review
Removes stale vendor, contractor, and former employee access
Password vaulting
Helps protect privileged credentials
Exam Trap: Shared Accounts
Shared accounts are common in older OT environments, but they reduce accountability. If a scenario asks for the best security improvement, prefer named accounts, role-based access, MFA, and logging where operationally feasible.
Ransomware and Malware Resilience
Ransomware scenarios are high-yield because they test segmentation, backup, identity, and recovery decisions.
Strong Ransomware Controls
Control
Why it matters
Network segmentation
Limits spread from IT into OT
MFA
Reduces credential-based access
Offline or immutable backups
Prevents attackers from encrypting backups
Tested restoration
Confirms recovery is realistic
Application allowlisting
Helps control what can run on OT endpoints
Email and web controls
Reduces initial infection risk
EDR where compatible
Improves detection on supported systems
Least privilege
Limits damage from compromised accounts
Disable unnecessary services
Reduces attack surface
Incident playbooks
Speeds safe response
Backup Review Points
Backups should include more than ordinary files:
PLC logic
HMI configurations
Engineering workstation projects
Historian configurations
Firewall and switch configurations
Server images where appropriate
License keys and vendor installation media
Golden images for supported endpoints
Documentation for restore order and dependencies
Supply Chain, Vendor, and Third-Party Risk
OT environments often depend on vendors for maintenance, firmware, proprietary tools, and remote support.
Risk
Control
Persistent vendor VPN
Time-bound access with approval and MFA
Shared vendor credentials
Named accounts and session logging
Unverified firmware
Vendor validation, integrity checks, change control
Contractor laptop connects to OT
Controlled access, scanning, jump host, no direct access
Remote support tools
Approved tools only, monitored sessions
Poor asset ownership
Contracts and procedures defining responsibilities
Untracked changes
Formal change management and configuration records
The easiest operational answer is often “let the vendor connect directly.” The safer exam answer is controlled vendor access through approved channels, with least privilege, MFA, logging, time limits, and operations approval.
Secure Configuration and Hardening
Hardening in OT should be tested and coordinated. A technically “secure” setting can cause downtime if it breaks vendor support or process communication.
High-Yield Hardening Areas
Area
Examples
Services
Disable unused services, ports, and protocols
Accounts
Remove default accounts, enforce least privilege
Passwords
Change defaults, vault privileged credentials
Remote access
Disable unauthorized tools, require MFA
Host firewall
Restrict inbound/outbound traffic
Application control
Allow approved software only
Logging
Enable useful audit trails
Time sync
Centralized, reliable time source
Removable media
Control, scan, and log use
Configuration backups
Store known-good versions securely
Hardening Trap
Do not harden production OT by applying generic server baselines without testing. Use vendor-supported baselines, lab validation, change control, and rollback plans.
Cloud, IIoT, and Edge Connectivity
Modern OT environments may send operational data to cloud platforms, analytics systems, or remote monitoring services. These connections increase value and risk.
Area
Key review point
Edge gateway
Harden, patch, monitor, and restrict access
Cloud identity
Use least privilege and strong authentication
Certificates
Manage lifecycle and protect private keys
APIs
Authenticate, authorize, log, and rate-limit
MQTT broker
Secure topics, credentials, and TLS
Data flow
Send only required data to approved destinations
Egress filtering
Prevent arbitrary outbound connections
Device onboarding
Verify identity before trust
Remote management
Use approved tools and logging
Data classification
Understand operational sensitivity
Cloud/IIoT Trap
Do not assume outbound-only traffic is automatically safe. Malware and compromised devices often use outbound channels. Control destinations, authenticate systems, inspect where feasible, and monitor behavior.
Common SOT-001 Candidate Traps
Trap
Why it is wrong
Better thinking
Applying IT playbooks directly to OT
Can disrupt physical processes
Adapt response to safety and operations
Patching first in every scenario
Patches may break control systems
Test, schedule, and use compensating controls
Active scanning production networks
May crash fragile devices
Prefer passive discovery or approved scans
Treating confidentiality as always highest
OT often prioritizes safety and availability
Match control to process risk
Ignoring engineering workstations
They can alter controller logic
Harden, monitor, and restrict access
Trusting internal networks
Flat OT networks are risky
Segment and monitor east-west traffic
Leaving vendor VPN always on
Persistent access increases attack surface
Time-bound, MFA-protected, logged access
Assuming backups are good
Untested backups may fail
Test restores and protect backups
Using shared admin accounts
No accountability
Named accounts, PAM, session recording
Blocking traffic without analysis
Could stop production
Validate with baseline and operations
Forgetting physical access
Local access can bypass network controls
Secure cabinets, ports, and control rooms
Overlooking time sync
Logs become hard to correlate
Maintain reliable time synchronization
Monitoring only IT logs
OT-specific events are missed
Include PLC/HMI/jump/industrial network data
Assuming VLAN equals segmentation
VLANs are not policy by themselves
Enforce rules with firewalls/ACLs
Ignoring cloud egress
Outbound paths can be abused
Allowlist, authenticate, monitor
Quick Scenario Practice Patterns
Use these patterns when working through original practice questions.
Scenario 1: Unknown Devices on OT Network
Best reasoning:
Do not immediately scan aggressively.
Check passive monitoring, switch MAC tables, and network diagrams.
Identify owner, location, and communication flows.
Validate with operations.
Quarantine or restrict only after assessing process impact.
Update inventory and monitoring rules.
Scenario 2: Critical PLC Vulnerability Announced
Identify affected PLCs and exposure.
Review vendor guidance.
Determine process criticality.
Test patch or firmware where possible.
Apply segmentation or firewall restrictions immediately if needed.
Schedule maintenance window.
Monitor for exploit indicators.
Document residual risk.
Scenario 3: Vendor Needs Emergency Access
Confirm business and operational need.
Use approved remote access path.
Require MFA and named account.
Limit access to required systems.
Record or log session.
Set expiration time.
Review changes afterward.
Scenario 4: Ransomware in Enterprise IT
Assume possible OT risk until validated.
Block unnecessary IT/OT paths.
Confirm OT backups and monitoring.
Review domain trust and shared credentials.
Increase monitoring of jump hosts, historians, and remote access.
Coordinate with operations before isolation decisions.
Scenario 5: Suspicious PLC Logic Change
Involve operations and engineering immediately.
Assess safety and process impact.
Preserve logs and project files.
Compare logic to known-good backup.
Identify account and access path used.
Contain compromised credentials or workstation.
Restore validated logic if required.
Fast Review Tables
Best Control by Goal
Goal
Strong candidate answer
Reduce IT/OT pivoting
OT DMZ and strict conduits
Secure vendor access
MFA, PAM, time-bound access, logging
Discover assets safely
Passive monitoring and documentation review
Protect unsupported systems
Isolation and compensating controls
Detect abnormal control traffic
Industrial protocol-aware monitoring
Recover from ransomware
Offline/immutable tested backups
Control PLC logic changes
Engineering workstation security and change management
Prevent rogue devices
Physical security, port control, NAC where feasible