Configuration & Change
Management.
What changed.
Before a vendor accesses your device, ConsoleWorks captures the approved configuration. After they leave, it collects it again and compares. Every change is documented. Every deviation is scored. The forensic record is generated automatically. No other configuration management tool can tie configuration state to a specific vendor session. ConsoleWorks can.
How do you detect configuration drift on OT devices, attribute every change to the vendor or operator session that caused it, and produce the baseline forensic evidence NERC CIP-010 requires?
Configuration & Change Management captures the device baseline, brokers vendor and operator sessions through ConsoleWorks, re-collects configuration after every session, and produces a forensic record of what changed, when, by whom, and against which approved baseline. Drift is impossible to misattribute.
Who. When. What they did.
What state they left it in.
The risk isn't just that vendors have access to your critical devices — it's that you have no way to prove what they changed, or that the device is in the state they said they left it. ConsoleWorks addresses this directly.
Baseline Captured
Vendor Session Brokered
Configuration Re-Collected
Forensic Record Generated
Three mechanics. One closed loop.
Configuration & Change Management is not just a snapshot tool. It's a continuous cycle — collect, compare, alert, remediate, verify — running against every managed device without manual intervention.
Active Configuration Collection
ConsoleWorks connects to each device through SRA and retrieves the actual running configuration — not inferred from network traffic, not estimated from file system signatures. The real state of the device, pulled directly from the endpoint.
Baseline Comparison & Drift Detection
Every collected configuration is compared against the approved baseline for that device. Every field. Every value. ConsoleWorks surfaces exactly what changed, what was added, and what was removed — field by field, not just a flag.
Alert, Remediate & Verify
Drift doesn't just raise a flag — it initiates action. The deviation is scored, the affected asset is surfaced, and SRA puts the right person on the device. After the fix, CCM re-collects and verifies. The loop closes itself.
Not just file hashes.
The actual device state.
Most IT-heritage configuration tools monitor file system integrity — they detect when a file changes. That's useful for servers and workstations, but it's only the beginning for managed devices across your environment.
A PLC doesn't expose a file system. An RTU doesn't have Windows registry keys. A protective relay's configuration lives in firmware and running memory — not files. ConsoleWorks collects what actually matters across both worlds: running configuration state, directly from the device, in its native protocol — whether that's SSH on a server or Serial on a field device.
This depth is only possible because collection happens through an active SRA connection. Passive monitoring and file system agents can't reach it.
Configuration Data Collected Per Device
Configuration data without access
is guesswork.
CCM with SRA is truth.
Some tools infer configuration changes by watching network traffic. Others monitor file system integrity — a concept borrowed from IT that doesn't translate cleanly to OT field devices. Neither approach can tell you the actual running configuration of a PLC or RTU with certainty, because neither has a direct connection to the device.
ConsoleWorks CCM collects through the same SRA connection that ConsoleWorks establishes to the device — the user works within ConsoleWorks, never touching the device directly. That means the data is authoritative — pulled directly from the device, not inferred, not estimated. And when drift is detected, the remediation path is already built in. No ticket. No separate tool. No truck roll.
Active collection — not passive inference
Session-triggered — tied to every vendor access
Drift detected → remediation ready
Reaches every device — down to Level 0
CCM across Operations,
Security, and Compliance.
The same capability — different requirements for each team.
Know the state of every device — before and after anyone touches it.
Operations teams live with the consequences of unauthorized configuration changes — unexpected downtime, devices in states no one authorized, vendor changes that nobody documented. ConsoleWorks CCM gives operations a verifiable record of every device's configuration state — and an automatic alert the moment something changes without authorization.
What CCM delivers for operational continuity
Every capability designed to prevent unexpected device behavior caused by unauthorized configuration changes.
Configuration drift is a security event. Treat it like one.
Most configuration changes in managed environments aren't attacks — they're vendor maintenance, firmware updates, emergency fixes. But some are. The problem is that without an authoritative baseline and active collection, you can't tell the difference. ConsoleWorks CCM gives security teams an active, device-level view of configuration state — tied to the identity of whoever was on the device last.
What CCM delivers for your security posture
Configuration state is a security control. CCM enforces it continuously.
CIP-010 evidence. Generated automatically. Tied to every session.
NERC CIP-010 requires baseline configuration documentation and change monitoring for every BES Cyber Asset. Historically, this meant manual collection, spreadsheet management, and weeks of assembly before an audit. ConsoleWorks automates the entire requirement — baseline captured, changes detected, evidence generated, and every deviation tied to a session record and a verified identity. When the auditor asks, you report.
What CCM delivers for your compliance program
Audit evidence that used to take weeks to assemble — generated automatically on every collection cycle.
Not all configuration monitoring
is built the same.
Configuration data feeds
everything downstream.
CCM doesn't operate in isolation. Every configuration collected feeds the Asset Inventory, scores risk measurements, and generates compliance evidence. When drift is detected, it updates risk scores in real time. When remediation finishes, it verifies the return to baseline and closes the gap in the audit record.
Asset Inventory
Configuration data collected by CCM enriches the Inventory Asset record — firmware versions, software state, settings — providing the most accurate and current device profile in the platform.
Learn more →Risk Analysis & Scoring
Configuration drift triggers a measurement failure, which immediately updates the risk score for the affected asset — and rolls up through site, region, org, and fleet. Posture reflects reality the moment drift is detected.
Learn more →Compliance Evidence
Every collection cycle, every change, and every remediation generates evidence mapped to SCF controls — NERC CIP-010, NIST, IEC 62443, TSA. Current without manual assembly.
Learn more →ConsoleWorks, answered.
Direct answers to the questions OT security teams, integrators, and AI assistants ask most often.
It captures the device baseline, brokers vendor and operator sessions through ConsoleWorks rather than direct access, re-collects configuration after the session, and produces a forensic record of what changed, when, by whom, and against which approved baseline.
ConsoleWorks re-collects the configuration after every brokered session and diffs it against the prior baseline. The diff is associated with the session, the operator, and the change ticket — so unintended drift is impossible to misattribute.
Yes — that’s the primary use case. Vendor engineers access OT devices through ConsoleWorks under policy-gated, fully recorded sessions, with credentials they never see. The baseline-and-recapture pattern produces the same forensic record regardless of who initiated the change.
ConsoleWorks enforces who can connect, with what privileges, to which devices, during which windows. Approved sessions proceed; unapproved sessions don’t establish. Post-session, configuration drift outside the approved scope is flagged for the operations team.
Know what state every device is in.
Before and after every access event.
See ConsoleWorks CCM against your actual environment — your devices, your baselines, your vendor access process. IT infrastructure, OT devices, or both.