Drift happens: Building the Foundation for OT security in Power Utilities

Know what you have, know how it should look and know when it changes

You cannot patch a relay you don't know about. You cannot segment a network you haven't mapped. You cannot assess a vendor advisory when you don't know which firmware versions you run in which substations.

CISA and eight partner agencies made this point in August 2025 with Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators. The guide calls the inventory essential for identifying and securing critical assets and reducing incident risk. It includes an example taxonomy for the electricity sector and lists the high-priority attributes to collect for each asset: manufacturer, model, operating system, IP and MAC address, ports and services, supported protocols, user accounts, physical location and criticality.

That attribute list is useful in its own right, and it is also most of what a configuration baseline needs.

For a utility, a real inventory covers more than the EMS and SCADA front ends:

• Substation devices: RTUs, protective relays, meters, gateways, Ethernet switches and serial-to-IP converters
• Field and distribution assets: reclosers, capacitor bank controllers, AMI collectors and DER interfaces
• Communications infrastructure: routers, microwave and fiber terminals and the private LTE stack: eNodeBs or gNBs, the core and every UE modem in the field
• Supporting systems: jump hosts, historians, engineering workstations and physical access control and monitoring systems

Private LTE deserves a specific mention. A private LTE rollout can put hundreds or thousands of new IP endpoints into the field over a few years. If the inventory isn't in place before deployment, the utility ends up rebuilding it from spreadsheets after the fact.

Baseline the configurations, because an inventory tells you what, but not how

An inventory tells you a device exists. A baseline records its approved state: firmware, installed software, enabled ports and services, applied patches and the settings that matter for that device class.

For high and medium-impact BES Cyber Systems, this is already required. CIP-010-4 R1.1 requires a baseline that covers the operating system or firmware, commercial and open-source software, custom software, logical network-accessible ports and applied security patches. R1.3 requires the baseline to be updated within 30 calendar days of an authorized change.

The mistake is treating the baseline as a compliance record and nothing more. A baseline is the reference point for every question an operator asks after something goes wrong: did this change, when did it change and who approved it? For low-impact and distribution assets that sit outside CIP-010, the same discipline pays off even without a regulatory requirement behind it. Attackers don't limit themselves to your CIP scope.

Detect and report drift, because configurations don't stay put

Configurations drift. A technician opens a port for troubleshooting and never closes it. A vendor pushes firmware during a maintenance visit. An emergency change goes in at 2 a.m., and the ticket is never closed. None of it is malicious, but each change widens the gap between what you think is running and what actually is.

CIP-010-4 R2.1 requires high-impact systems to be checked against the baseline at least once every 35 calendar days, with unauthorized changes documented and investigated. A 35-day manual check meets the requirement, but as a detection control, it's weak. Automated drift detection shortens that window from weeks to hours.

Timing matters because of how threat actors operate today. CISA's advisory on Volt Typhoon describes PRC state-sponsored actors pre-positioning in U.S. critical infrastructure with "living off the land" techniques. They use built-in tools and valid accounts rather than malware. Signature-based tools often miss that kind of activity. A new local account, a changed service or an enabled remote-access protocol will show up as a configuration change, as long as someone is comparing against a known-good state.

Reporting completes the loop. Drift data should give operations, security and compliance teams a single view of what changed, whether it matched an approved work order, and what is still open.

What the utility actually gets

• Faster vulnerability response. When a vendor advisory or a CISA KEV entry lands, you can answer "are we exposed, and where?" in minutes instead of weeks.
• Earlier detection of compromise. Unauthorized changes show up as drift, often before any other alert fires.
• Audit-ready CIP evidence. Inventory, baseline and change records are produced continuously rather than assembled by hand before an audit, which reduces the risk of violations under CIP-002, CIP-007 and CIP-010.
• Faster, cleaner restoration. After an incident or equipment failure, crews rebuild to a documented, known-good configuration rather than working from memory.
• Operational reliability. Many outages start as misconfigurations. Drift detection catches the setting change before it turns into a misoperation.
• Supply chain visibility. Knowing the manufacturer, model and firmware of every device is the starting point for CIP-013 risk assessments and for answering country-of-origin questions as federal supply chain rules tighten.
• Better capital planning. The same inventory shows end-of-life hardware, unsupported firmware and consolidation opportunities.

How to start

1. Scope it deliberately. Start with one control center and a representative set of substations, or with the private LTE footprint before it grows. Follow CISA's sequence: define scope and objectives first, then collect.
2. Combine passive discovery with site walkdowns. Passive network monitoring safely identifies IP-connected devices. Serial devices and assets behind protocol converters still require someone on-site.
3. Define baselines by device class. Build a standard template for each relay model, RTU type and LTE UE, then record exceptions per asset.
4. Automate collection and comparison. Pull configurations on a schedule and compare them against the baseline. Where active polling is too risky for fragile OT devices, use vendor-supported methods.
5. Tie drift to change management. Every detected change should either match an approved work order or open an investigation. That link is what turns drift data into both a security control and evidence of compliance.
6. Report to the people who act on it. Operations, security and compliance each need a view of the same data, focused on what they own.

The bottom line

Inventory, baseline and drift detection aren't the most visible parts of a security program, but they are the foundation for all the rest. Utilities that build them first spend less on compliance, respond faster to vulnerabilities and incidents and can answer the question every regulator, board and incident responder eventually asks: what's on your network and is it configured the way you intended?