A Claroty network-policy recommendation does not approve a firewall change

Keep recommendation and authorization as separate records

Claroty's official platform record says network policies can be automatically defined and recommended from CPS visibility, then monitored, refined, and enforced through existing network controls. The direct answer is that a recommendation can identify a defensible segmentation option without authorizing the change. OT traffic can carry control, safety, engineering, historian, vendor-support, time-synchronization, and recovery functions whose consequence is not fully visible from observed communications alone.

The recommendation record should preserve the affected assets and zones, observed flows, business and process context, threat or exposure rationale, proposed source, destination, protocol, port, direction, timing, confidence, exceptions, and supporting telemetry. The authorization record should separately name the asset owner, control-system engineer, operations approver, cybersecurity reviewer, safety reviewer where applicable, maintenance window, test plan, rollback owner, and expiry or review date.

Test policy intent against the physical process

A flow that looks unnecessary during observation may be required only during startup, shutdown, calibration, failover, batch change, engineering access, backup, disaster recovery, or an infrequent vendor intervention. Conversely, a commonly observed flow is not automatically safe or authorized. Before enforcement, teams should compare the proposed rule with network diagrams, controller and device dependencies, safety functions, remote-support procedures, time sources, name resolution, logging, patch paths, and recovery communications.

Testing should include normal operations and the difficult states that passive baselines can miss. Use a representative lab, staged rule, simulation, or controlled maintenance window where feasible. Define success, forbidden effects, monitoring, stop conditions, and rollback steps before the change starts. When direct testing is unsafe or impractical, preserve the limitation and require compensating review rather than converting incomplete visibility into confidence.

Prove what was enforced and what changed

Approval is still not proof of implementation. The retained chain should connect the Claroty recommendation, approved rule, target firewall or switch, native change ticket, configuration version, deployment response, device commit, validation observations, process checks, exceptions, and closeout. If enforcement spans several controls, record each target and result instead of treating a platform-level status as proof that every device accepted the same policy.

Post-change review should check allowed and denied traffic, asset availability, control latency, alarms, operator observations, safety-system state, vendor access, logging, and rollback readiness over an agreed period. Unexpected blocks and bypasses need named ownership. Temporary rules should expire automatically or return to review. A later policy refinement should create a new version while keeping the prior recommendation, authorization, and observed outcome available for incident and audit reconstruction.

Keep Claroty claims inside the official record

The registered Claroty page establishes current provider positioning around CPS asset inventory, exposure management, network protection, secure access, and threat detection. It specifically describes defining and recommending network policies and using existing firewalls, switches, or NAC tools for monitoring, refinement, and enforcement. It does not establish complete asset context, safe change timing, compatibility with a reader's controls, approval authority, successful enforcement, or risk reduction in a particular environment.

OT Defense Review reviewed the registered source on August 18, 2026 and did not operate a customer deployment. Buyers should verify discovery methods, asset context, policy rationale, native-device integrations, rule translation, approval workflow, safety and operations review, staged testing, enforcement evidence, rollback behavior, exception handling, audit history, and support boundaries against representative production conditions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.