Official intent
Continuously monitor OT so abnormal behavior is seen before it becomes downtime. The official source remains authoritative.
Read the official campaign ↗You cannot respond to what you cannot see. OT monitoring is built passively — from network taps and SPAN ports, not agents on fragile devices — to baseline normal traffic and flag the abnormal: new devices, unexpected connections, protocol anomalies, and changes to controller logic. The aim is early warning, tuned to an environment where the traffic is predictable and deviations matter.
Who this applies to: Environments with networked control equipment. Monitoring value rises sharply once segmentation exists, because 'normal' becomes definable.
Why it matters
OT traffic is repetitive, which makes anomalies unusually meaningful — a new connection to a PLC is rarely benign. Monitoring turns that predictability into early detection of intrusions and of failing equipment, often before either causes a stoppage. Without it, the first sign of trouble is the process itself going wrong.
Risks this reduces
- Intrusions that go unnoticed until the process itself misbehaves
- New or unauthorized devices appearing on control networks
- Unexpected connections to controllers and changes to control logic
- Failing equipment detected only after it causes a stoppage
Deploying monitoring must not disturb the process. Use passive collection (taps, SPAN) rather than active scanning or agents on control devices, and place sensors with the process owner so nothing loads or interrupts real-time traffic. Visibility is the goal; a monitoring rollout that risks a trip has defeated its purpose.
Who owns it
OT engineer
OT / network administrator, IT / security lead, Vendors
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: OT-02 — Validated OT asset inventory, OT-03 — OT network segmentation
- Passive capture points — SPAN ports or network taps — identified with the process owner
- A baseline of normal assets and communications, built with the people who run the process
- A named responder who receives alerts and has authority to investigate
Action timeline
- Identify where you can passively capture OT traffic (SPAN/taps)
- Confirm no monitoring will be placed as an agent on control devices
- Deploy passive capture on one critical segment and baseline normal traffic with the process owner
- Name the person who receives alerts and agree what they are authorized to do with one
- Deploy passive capture on a critical segment
- Baseline normal traffic and assets with the process owner
- Enable anomaly alerts (new devices, unexpected connections, protocol/logic changes)
- Route alerts to a named responder
- Extend coverage across zones and sites
- Integrate OT alerts with IT detection and response
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Identify passive capture points (SPAN ports, network taps) that see critical OT traffic.
- Deploy an OT-aware monitoring capability without placing load or agents on control devices.
- Baseline normal assets and communications with the people who run the process.
- Alert on meaningful anomalies — new devices, unexpected flows, protocol errors, controller logic changes.
- Route alerts to a responder, tune out noise, and connect OT detection to your overall response.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No visibility into OT traffic; the first sign of trouble is the process going wrong.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A monitoring plan names coverage, sensor placement, alert ownership, and the passive-only constraint.
Is the intent written down, with a named owner and a scope? - Configured
Passive capture is running on at least one critical segment and a traffic baseline exists.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Sensors cover the critical zones, anomaly alerting is enabled, and alerts reach a named responder.
Does it cover everything in scope, with the exceptions written down? - Measured
Detection is tested, alert volumes and investigation outcomes are tracked, and tuning reduces noise measurably.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
Coverage is reviewed against the inventory on a cadence, OT alerts feed the wider response process, and records are retained.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Introduce a benign test device or connection and confirm monitoring detects it.
- Verify sensors are passive and add no measurable load to control networks.
- Confirm recent alerts reached a named person and were investigated, not just logged.
Evidence to retain
OT monitoring plan naming coverage, sensors, and alert ownership
Sensor placement and detection/alerting configuration
Alert investigation records and baseline documentation
Detection test result and sensor passivity confirmation
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Monitored zone coverage | OT zones with passive monitoring ÷ zones in the segmentation design. | All critical zones; the remainder scheduled. |
| Alert investigation rate | Alerts investigated and dispositioned ÷ alerts raised. | 100% of high-severity alerts. |
| Detection test result | Whether a benign test device or connection was detected within the expected interval. | Detected every time the test is run. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Buying a monitoring tool and letting its alerts pile up unread, trying to run agents on fragile controllers, and baselining once but never updating it as the plant changes. An alert nobody owns is not monitoring.
Two sized paths
One passive sensor on the link between the office and the plant answers the highest-value question: is anything talking to production that should not be? Baseline it with the person who runs the line and route alerts to a real person. Full-coverage OT monitoring platforms come later.
Extend passive coverage across zones and sites, integrate OT detections with IT detection and response so one team sees the whole picture, tune aggressively so alerts stay actionable, and reconcile monitored assets against the inventory automatically.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Sensor placement itself is a plant change and belongs in the change record, with a rollback that is as simple as removing the tap. Place taps with the process owner, verify sensors are genuinely passive and add no measurable load, and never install agents on control devices to save deployment effort. Where a vendor supplies or manages the monitoring, hold their access to the same brokered remote-access controls as everyone else. Re-baseline after every significant plant change or the alerts become noise.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication recommends passive monitoring approaches suited to control networks and warns against intrusive collection.
What this does not claim: 800-82 is guidance, not a compliance standard. Pinpointing individual overlay controls is part of the pending SME pass.
Why: The network monitoring and adverse-event analysis outcomes describe this practice directly.
What this does not claim: The CSF describes outcomes, not testable controls.
Why: Continuous monitoring is a system requirement in the standard's system-integrity family.
What this does not claim: IEC 62443 is a voluntary industrial standard; conformance is a separate, scoped exercise. The specific requirement identifiers are pending verification against the licensed normative text and should be treated as directional until that check completes.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.3.1Audit log creation and retentionOperational supportModerate
Why: Passive OT monitoring continuously produces records of network activity on control segments — and its alert-investigation routine consumes them — giving the OT estate a usable record base for monitoring and investigation that controllers and HMIs cannot generate themselves.
What this does not claim: Sensor observations are not system audit logs: the requirement asks for created and retained audit records across organizational systems, with retention decided deliberately, and a monitoring platform's rolling capture may not qualify. Provides evidence relevant to the requirement for the OT estate only, and only where OT falls within the assessed boundary.
Review status: Pending OT SME review.
Open the 3.3.1 page →3.3.5Audit correlationOperational supportModerate
Why: The practice's operating rhythm — investigate every alert, disposition it, feed OT detections into the wider response process — is the review-analysis-response loop this requirement wants, running on the OT sources most correlation processes omit.
What this does not claim: One well-run source is not correlation across sources: the requirement expects review and analysis connected across the organization's audit records — identity, endpoint, cloud — and the practice contributes the OT feed, not the joining. It should be evaluated within the organization's defined system boundary, where the OT segment may be a small part of the whole.
Review status: Pending OT SME review.
Open the 3.3.5 page →3.14.6Attack monitoringPartial implementation supportModerate
Why: Monitoring systems and communications traffic to detect attacks is this practice's whole outcome on the OT network: passive sensors baseline normal industrial traffic and surface deviations, on segments where passive detection is often the only safeguard production tolerates.
What this does not claim: May partially address the requirement, for the OT slice only and only where OT assets sit inside the assessed boundary. The requirement covers organizational systems broadly — the IT estate's monitoring is separate work — and a passive sensor sees the network, not the host: engineering workstations and historians still need endpoint-level visibility that many OT environments cannot safely run, which is a gap to record, not assume away.
Review status: Technical review complete.
Open the 3.14.6 page →3.14.7Unauthorized use identificationPartial implementation supportModerate
Why: Unauthorized use in a plant looks like a connection or command with no business existing — a new device on the control network, a workstation talking to a PLC it never touched, a write from an unexpected source. Baseline-deviation monitoring is built to surface exactly that.
What this does not claim: May partially address the requirement. Separating unauthorized use from authorized-but-unusual operations takes process knowledge the sensor lacks — a contractor laptop during a shutdown may be entirely legitimate — so the practice yields candidates for review, not determinations, and identification of unauthorized use across the IT estate (accounts, applications, data access) is untouched by OT network monitoring.
Review status: Technical review complete.
Open the 3.14.7 page →NIST SP 800-171 Rev. 3
03.03.05Audit Record Review, Analysis, and ReportingOperational supportModerate
Why: Continuous OT monitoring is review-and-analysis running as a daily routine for the plant: someone is watching what the environment is doing, anomalies get investigated, and findings reach people who can act. Where OT segments sit inside the CUI boundary, that routine is the operating muscle this requirement's cadence depends on.
What this does not claim: The practice watches process behavior and network anomalies more than audit records as such, and it says nothing about the enterprise systems where most CUI audit review happens. The defined review frequency, the reporting path, and cross-repository correlation are the organization's audit program to establish — the practice keeps eyes on one estate, not the requirement implemented.
Review status: Pending NIST SME review.
Open the 03.03.05 page →03.14.06System MonitoringPartial implementation supportModerate
Why: Continuous OT monitoring watches control-network traffic and device behavior for the abnormal — the attack-indicator and unauthorized-use detection this requirement names, applied to the slice of the system that lives on the plant floor.
What this does not claim: May partially address the requirement for OT assets inside the assessed boundary; enterprise endpoints, identities, and cloud services — most of the requirement's scope — sit outside this practice entirely. Where OT itself sits outside the CUI system boundary, as much of it does, the relationship is informative rather than load-bearing.
Review status: Pending NIST SME review.
Open the 03.14.06 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.