Configuration drift is the gap between the organization’s approved device settings and the device’s current settings/configuration.
A configuration policy for a set of devices gets approved. The baseline gets set. Everyone moves on to the next fire.
Then a camera goes offline, and a team member resets it with a paperclip, unknowingly restoring the factory default password. A vendor technician opens a port during a service call and forgets to close it. A PLC gets left in program mode after a maintenance window, and nobody notices before the next shift. None of it trips an alarm on your side. It just sits there, moving the device further from the configuration policy someone signed off on months ago.
Adversaries don’t need a new vulnerability to exploit that gap. They probe for exactly this: the open port nobody remembered, the default credential nobody rotated, the setting nobody reset after maintenance. They check constantly. Most organizations check on a schedule, once a quarter, once a year, whenever the audit comes due. In between, the device is out of policy and nobody knows it.
That gap, between the baseline an organization approved and the configuration actually running on the device, is exactly what we have built through the new configuration drift report.
Every device on the network, from IP cameras and printers to PLCs, controllers, routers, and switches, feeds a single device record. Active discovery safely communicates directly with the device to collect metadata and deep insights. Drift detection, policy evaluation, alerts, and compliance reporting all draw on that same record, built from more than 2 million devices across 1,341 vendors, 84 device types, and 4,748 configuration fields (Dragos device intelligence data, September 2026). Three groups pull different values from the same record: compliance analysts, security engineers, and threat management analysts.
We built this release from practitioner interviews across utilities, manufacturing, healthcare, finance, and data centers. A device can’t attest to its own configuration, so compliance analysts were assembling evidence one control at a time to satisfy standards like NERC CIP and IEC 62443. Security engineers were catching policy violations at human speed, when staying ahead of exposure takes machine speed. Configuration Drift Reporting was built to close both gaps.
Picture a compliance analyst at a NERC CIP-regulated utility, staring down an audit request for proof that a specific control has held for the last two quarters. Today, that proof gets assembled by hand: screenshots, spreadsheets, and a hope that nothing changed in the gaps between manual checks.
The configuration drift report replaces the hope with a record. The drift report shows what changed on a device, when it changed, and whether it should have: compliance measured against policy, drift broken out by severity and by field, and a documented narrative built for compliance requirements, audit responses, and risk reporting. For a PLC, that can mean tracking drift in key switch position, uptime, and the project name loaded onto the controller, three fields that look minor on their own but, together, show whether someone quietly switched a controller into program mode, restarted it outside a maintenance window, or loaded a different logic file than the one that passed validation. The report reads like it was written for the auditor, because it was.
The Drift Report: compliance by policy, drift events by severity, and the fields drifting most often.
A security engineer holding the line across thousands of devices cannot review every configuration and waiting for the next scheduled check means living with unknown exposure in between, the exact window an adversary is counting on.
That is the job the policy engine does instead. Users define what good looks like once. Policies are built from rules drawn from compliance frameworks, organizational standards, and hardening guides, tailored to each asset class. The policy becomes the baseline. Every device is held to it continuously, and drift is alerted the moment something falls out of alignment. The violation, the value, and the call to action appear directly on the device page, closing the window before an adversary can find it.
When something looks wrong on a device, a threat management analyst needs more than the current state. They need what changed, when it changed, and whether it should have, across the inventory and against prior states, so they can tell a routine update apart from something that deserves a closer look.
The refactored device metadata experience is built for exactly that moment: the violation, the value, and the next action are the first things on the page, so analysts get to the insight faster and can remediate before the exposure window grows.
Across electric, energy and utilities, finance, and data centers, the policies built on this record map to controls regulators and auditors already look for: NERC CIP, IEC 62443 Part 4-2, NIST SP 800-53 Rev. 5, CIS Controls v8, the EU’s NIS2 Directive, the HIPAA Security Rule, and PCI DSS v4.0. That mapping means the evidence a compliance analyst pulls together is not extra work bolted onto an audit cycle. It is the audit cycle, produced as a byproduct of running the policy in the first place.
A configuration baseline only means something if someone keeps checking it, and most organizations check less often than adversaries do. Configuration Drift Reporting closes that gap for good: compliance analysts get the audit evidence, security engineers get the alert the moment a device falls out of alignment, and threat management analysts get the full history to tell a routine change from a real one. Same record, three jobs, one gap that no longer sits open waiting for whoever finds it first.
Contact us to see how Configuration Drift Reporting works.
