Start inside the plant, because the argument is concrete and the abstraction is what lets people dismiss it.

A gas processing facility commissions a predictive-maintenance agent. The use case is unglamorous and genuinely valuable: read vibration, temperature and pressure trends from the historian, correlate against the maintenance system, flag the compressor bearing that is drifting toward failure three weeks before the alarm would fire. Nothing in this touches a control element. The vendor's deployment guide asks for one thing: read access to the historian.

The integration engineer knows exactly how to provide it, because there is an account for that. It was created in 2009, when the historian was integrated with the distributed control system. Its password is written into the configuration files of four different connectors, two of which belong to systems whose vendor no longer exists in the form that shipped them. It has read access to every tag in the plant, because scoping it in 2009 would have meant enumerating tags nobody had time to enumerate, and breadth was free. It has never been rotated, because rotating it means a coordinated change across every system that embeds it, and the window for that kind of change comes once a year if the turnaround schedule holds. The agent gets the 2009 account. The deployment takes an afternoon. Everyone involved has made a locally reasonable decision.

Six months later there are four agents: the maintenance agent, an operations copilot that answers shift questions against the same historian, a fleet-optimisation service run by a different vendor, and a pilot the data science team stood up themselves. Two ride the 2009 account. One has a vendor remote-access path of its own. One authenticated through credentials an engineer copied out of a connector config into a cloud secret store, which means the 2009 password now also lives outside the plant.

The facility, the 2009 account, the four connectors and the four agents are a constructed illustration, assembled from patterns documented in published security standards, public incident reporting and vendor deployment documentation. It is not a report of any real site, operator, vendor or deployment, and no part of this piece describes client work.

The scale of the arrival is not hypothetical, and the sector's flagship example is published by the companies themselves. ADNOC and SLB announced in August 2026 that an AI real-time operations centre is live across the company's full onshore and offshore drilling fleet — more than 120 rigs — developed and hosted inside ADNOC's UAE sovereign cloud, with company-published figures of thirty to forty per cent less engineering effort, engineers covering two to three times more rigs, and incident response times cut by hours. Those are vendor-and-operator metrics and should be read as such. But the deployment class is exactly the one in the illustration: agents in OT-adjacent positions — reading operational data, advising operations, optimising across a fleet — at the scale of an entire national champion's production estate. I am not making any claim about ADNOC's credential estate, which I have no visibility into and which, sitting on a sovereign cloud built for the purpose, may well be newer than most. The deployment is the evidence for the adoption curve. The credential estate is the general condition of the sector the adoption curve is entering.

That general condition deserves to be stated without the usual sneer, because the reasons for it are not stupidity, and any argument that treats them as stupidity will bounce off the people who actually run these systems.

Three populations, none of them negligent

Three credential populations, one estate Each population has a structural reason it does not rotate. None of the reasons is negligence, which is why none of them has gone away. HARD-CODED SERVICE ACCOUNTS Embedded in historian and SCADA integration configs, often since commissioning. WHY IT DOES NOT ROTATE A change needs an outage window across every system that embeds it — on assets procured for 20–30 years, before rotation was assumed. VENDOR REMOTE-ACCESS ACCOUNTS Issued to OEMs and integrators for support access to live equipment. WHY IT DOES NOT ROTATE Removal risk is asymmetric. Deleting it might break a support path needed during a failure — so it outlives the contract that justified it. SHARED OPERATOR CREDENTIALS Used at control consoles, across shift changes, on air-gapped-in-theory networks. WHY IT DOES NOT ROTATE The console is a position, not a person. The credential belongs to the chair, and the chair is staffed continuously. Logout is an availability risk. WHAT THE AGENT PLATFORM INHERITS An agent arriving in a predictive-maintenance or operations-copilot position does not get a fresh estate. The fastest integration path runs through exactly these three populations — every one of which was provisioned before the word “agent” meant anything.

Hard-coded service accounts exist because the alternative was an outage. A historian is integrated with a control system once, at a project, under schedule pressure, by an integrator who will leave when commissioning ends. The credential that integration uses gets written into configuration — sometimes encrypted, often not, occasionally into the connector's source — because the systems on either side were designed in an era when the network was assumed closed and the credential was a formality. From that moment, changing the credential is not an IT operation. It is a coordinated change across every system that embeds it, each with its own vendor, its own change process and its own restart behaviour, on assets procured for twenty or thirty years of service. The change can only happen in an outage window, outage windows are scarce and oversubscribed, and a credential rotation will lose the priority contest against physical maintenance every single time. So the rotation is deferred, and deferred, and becomes load-bearing precisely because everything assumes it will never happen.

Vendor accounts outlive contracts because removal risk is asymmetric. The turbine manufacturer's support account was provisioned during warranty. The warranty ended; the account did not. The reasoning is not laziness — it is a genuine asymmetry. Removing the account costs nothing today and might cost catastrophically during the next failure, when the vendor's engineer needs access at three in the morning and the person who could re-provision it is asleep. Keeping the account costs nothing today and might cost catastrophically never, as far as anyone can see. Every individual renewal of that reasoning is defensible. Its fixed point is an estate where the set of external organisations with a standing path into the control network is the set of every vendor the plant has ever had, rather than every vendor it currently has — and where nobody can produce the difference between those two sets on demand.

Shared operator credentials exist because the console is a position, not a person. A control room chair is staffed continuously across shifts. The engineering that matters is that the display is always up and the operator can always act; an individual login per person, with the logout-login gap at every shift change, was historically read as an availability risk to the thing the whole facility exists to protect. So the credential belongs to the chair. The sector's own standards acknowledge the pattern rather than pretending it away — the control they apply to shared accounts is a duty to identify which individuals are authorised to use each one, which is to say: a list of people, maintained beside the account, standing in for the attribution the account itself cannot provide.

Add the qualifier that makes all three worse: air-gapped in theory. The isolation these credentials were provisioned under has been eroding for two decades — historians replicated to corporate networks so engineers can see trends from their desks, remote access added during 2020 and never removed, cellular modems on remote assets, and now cloud-hosted analytics platforms that exist precisely to consume operational data. Each erosion was individually justified. The credentials were never re-examined at any of them, because each erosion arrived as a network change, and the credentials are not a network.

What machine rate does to estate time

Into this estate, the agent platform introduces a second cadence.

The estate's own cadence is geological. Systems are commissioned on multi-decade lifecycles. Integrations are added at projects, years apart. Credentials are provisioned at commissioning and reviewed — where they are reviewed at all — on cycles measured in months to years. Rotation, where it is possible at all, is gated on outage windows that occur once or twice a year. Call this estate time.

The platform's cadence is weekly. A deployment per quarter becomes several agents per deployment becomes a connector per agent per system, and each connector wants a credential. Creation is automated, because automating creation is what makes the platform useful. Deprovisioning is a ticket, because deprovisioning is nobody's feature. I made the general version of this argument in an earlier piece on this site — that identity issuance at machine rate breaks reconciliation-based governance by arithmetic, because discovery cannot outrun automated creation — and I will not re-argue it here. What energy adds is the multiplier.

Machine rate meets estate time Two cadences on the same estate. The gap between them is the finding. ESTATE TIME commissioned multi-decade lifecycle integration added projects, years apart outage window rotation possible, once or twice a year review cycle months to years, where it exists Credentials change when the plant can stop. The plant can rarely stop. MACHINE RATE deployments per quarter · agents per deployment · connectors and scoped credentials per agent creation is automated; deprovisioning is a ticket Identities are created faster than any review cycle above can even count them. Minting at machine rate into an estate that rotates at outage-window rate does not add a new risk. It multiplies the old one: each new principal inherits the reach of the un-rotatable credentials it is wired through.

The multiplier is inheritance. A new machine identity minted into a clean estate carries its own risk: one more principal to own, scope and eventually kill. A new machine identity minted into this estate carries the old estate's risk as well, because the fastest integration path wires it through the un-rotatable populations. The agent that authenticates via the 2009 historian account does not just add a principal — it adds a consumer of a credential that cannot be changed, which means it adds one more system that will break when the credential finally is changed, which means it raises the cost of the rotation that was already too expensive to schedule. Every agent wired through a legacy credential makes that credential harder to retire. Machine rate does not sit beside the deferred-maintenance problem. It compounds it, in the strict sense: the backlog grows faster because of what is being added on top of it.

And the copied credential is the quiet half of the compounding. The moment an engineer moves a connector password into a cloud secret store so an agent platform can use it, the credential's exposure surface has left the plant. Nothing about the plant's own security posture changed, and the credential now also lives wherever the platform lives, subject to a different organisation's key management, backup policy and staff turnover. The 2015 attack on Ukrainian distribution utilities — the canonical public case study in this sector, documented in the joint E-ISAC and SANS analysis — ran on stolen legitimate credentials used through the utilities' own remote access paths into their control environments. The lesson the sector took was about segmentation and remote access. The lesson that ages better is about credential reach: the attackers did not break the control systems, they authenticated to them.

The same shape appears on the pipeline side. The 2021 Colonial Pipeline intrusion — per the incident-response firm's testimony before the United States Senate, and as widely reported at the time — began with a legacy VPN account that was no longer in active use but had never been deactivated, protected by a single password that had appeared in a public batch of leaked credentials. An account that had outlived its purpose, unrevoked, with a credential that had leaked into an environment nobody was watching. That is the vendor-account population and the copied-credential mechanism, in a sector-defining incident whose operational consequence — a precautionary shutdown of the pipeline's operations — is exactly the outcome OT credential conservatism exists to prevent.

The instruments govern the perimeter, the person and the load

The natural response at this point is that this sector, nearly alone among industrial sectors, has mandatory, audited, financially enforceable cyber security standards — the CIP family of reliability standards — and that an estate governed by them cannot be as ungoverned as I am describing. The response is half right, and the half that is right is worth conceding properly: the family is real, it is enforced with penalties, and the disciplines it has built — asset categorisation, electronic security perimeters, personnel risk assessment, access review — are the reason the sector's baseline is as high as it is. I am not arguing the standards are weak. I am arguing they are aimed, and the aim predates this population.

Read the family's lifecycle machinery closely — the actual clocks, quoted from the standards' own text — and watch what each one attaches to.

The personnel and training standard requires a process, upon a termination action, to initiate removal of the individual's ability for unescorted physical access and Interactive Remote Access, and to complete those removals within 24 hours of the termination action. That is a real revocation clock with a real deadline — and its trigger is the termination of a person. The clock starts when an individual's employment or arrangement ends. A machine principal has no employment to terminate. When the agent deployment that justified a service account is decommissioned, nothing that the standard recognises as a termination action has occurred, and the 24-hour clock — the sharpest revocation instrument in the family — never starts.

The systems security management standard carries the password machinery. For password-only authentication for interactive user access, the responsible entity must technically or procedurally enforce password changes, or an obligation to change the password, at least once every 15 calendar months. Fifteen calendar months is a long cycle by IT standards, and it was set with full knowledge of what rotation costs in this environment — but notice the scoping phrase doing the work: interactive user access. The clock attaches to humans logging in. A service account used system-to-system presents no interactive session, so the one mandatory rotation clock in the family does not attach to it. And the adjacent duties bend further: known default passwords must be changed per Cyber Asset capability — a phrase that concedes, in the standard's own text, that some governed assets cannot do even that — and the shared-account control requires identifying the individuals authorised to use each shared account, which is an attribution list beside the credential rather than a lifecycle on it.

The clocks attach to people What the sector’s security standards time-bound, read against what a machine principal actually presents. WHAT THE CIP FAMILY PUTS A CLOCK ON Removal of the individual’s access completed “within 24 hours of the termination action” trigger: the termination of a person Password change obligation “at least once every 15 calendar months” attaches to: interactive user access, password-only Default passwords changed “per Cyber Asset capability”; shared accounts → a list of people the duty bends to what the asset can do Perimeters, persons, access classes. WHAT A MACHINE PRINCIPAL PRESENTS No termination action. No person leaves when it should die. the 24-hour clock never starts No interactive login. The password clock never attaches. system-to-system access is a different class Created weekly by a platform, not commissioned annually by a project. a population growth rate the review cycles were not sized for No person. No session. No clock. THE GAP, STATED PRECISELY This is not a criticism of the standards, which govern what they were written to govern. It is an observation: every lifecycle clock in the family attaches to a person or an interactive session — and an agent’s credential has neither.

I want to be precise about what this reading is and is not. It is not a claim that the CIP family ignores system accounts — access authorisation, review and revocation provisions in the family reach accounts generally, and the perimeter standard concerns itself, at family level, with identifying and being able to terminate vendor remote access sessions. It is a claim about the temporal machinery. The hard clocks — 24 hours, 15 calendar months — attach to persons and to interactive sessions respectively. What remains for machine principals is periodic review at programme cadence: real, auditable, and unfitted by construction to a population that grows weekly. A review cycle sized for an estate where credentials are created at commissioning meets a platform that creates them per agent per connector, and the arithmetic of the earlier section applies: the review measures a population that has already changed by the time the review closes.

Meanwhile, the instruments the sector is actually writing in 2026 face the other direction. The federal energy regulator's most prominent AI-adjacent actions this summer concern AI as electrical load — a run of orders on large loads in June, and in July a direction toward creating a registered reliability class for large computational load entities, as reported at the time. This is necessary work; gigawatt-scale data centres are a genuine reliability problem. But note what it means for the argument: the sector's freshest AI instruments govern AI as a consumer of megawatts, not AI as a holder of credentials inside the control estate. The demand side of AI gets a registered class with reliability obligations. The deployment side — agents arriving inside the operator's own networks — inherits the existing family, whose clocks, as above, do not attach.

The objections, at full strength

Three objections deserve to be stated at their strongest, because each is right about something important.

OT conservatism is a safety case, not negligence — and 'just rotate' is the amateur's answer. Fully conceded, and more than conceded: this objection is load-bearing for everything the companion piece builds. The people who decline to rotate the historian credential are not behind on patching; they are correctly refusing to inject change risk into systems whose failure modes are physical. A credential change that takes down a data path mid-run is not an inconvenience — depending on what consumes the path, it is an operational event with a safety dimension. Any proposal that begins 'first, rotate everything' has disqualified itself, and most IT-native identity tooling begins exactly there. The honest conclusion is not that the conservatism is wrong but that it changes the design constraints: a credential lifecycle for this estate must treat revocation and rotation as operational manoeuvres with scheduling, sequencing and safe-state confirmation — which is precisely why the companion piece exists and why it is not a healthcare piece with the nouns changed.

Segmentation already bounds the blast radius. The zones-and-conduits discipline of the ISA/IEC 62443 series, the electronic security perimeter machinery of the CIP family, the demilitarised zone between corporate and control networks — these are real, mature, and in the well-run subset of the sector, genuinely enforced. Concede all of it. Then notice what an agent deployment is: a new conduit, by definition. The historian data has to reach the analytics platform; the copilot has to query operational data from the corporate side; the optimisation service has to see the fleet. Every one of these crosses the boundary the segmentation model defends, with credentials, in the sanctioned direction, through the approved DMZ pattern. Segmentation constrains where a credential can be used from. It says nothing about how long the credential lives, who owns it, or what happens when the thing it was minted for is gone — which are lifecycle properties, and the lifecycle is the gap. The perimeter model is not wrong; it is orthogonal, and the failure documented in every incident cited above walked through the perimeter with valid credentials.

These agents are read-only and advisory. Today, and mostly, yes — and the concession matters, because it correctly prices the immediate risk lower than the headline 'agents in SCADA' framing implies. Three things erode it. First, read paths are how credentials propagate: the read-only deployment is what moved the 2009 password into a cloud secret store, and the password was never read-only — the scoping that would have made a read-only credential possible is exactly the work the 2009 provisioning skipped. Second, advisory has a ratchet: the copilot that drafts the work order becomes the copilot that files it; the optimisation service that recommends set-point changes becomes, after two years of being right, the service whose recommendations are applied by default. Each step is small, locally approved, and never revisits the identity architecture laid down in the read-only phase. Third, the sector's own published deployments already describe agents participating in operations — incident response acceleration, engineering effort reduction — which is a description of actuation-adjacent work even where the final click belongs to a human. The read-only objection is true as a snapshot and false as a trajectory, and credentials are provisioned for trajectories.

What the failure actually looks like

The failure this piece predicts is not, in its first instance, a breach. It is an unanswerable question.

Something happens — a bad recommendation actioned, an anomalous read pattern, a security review after an incident somewhere else in the sector, or nothing more dramatic than an insurer's questionnaire growing a section. Someone with authority asks the two questions this estate cannot answer: which credentials can the agents use, and who decided that. The first question fails on the copied credentials — the 2009 password lives in the connector configs and the secret store and wherever else five years of integration shortcuts have put it, and no inventory maps credential to consumers. The second question fails on the inheritance — nobody decided the agent should hold plant-wide historian read; someone decided, in 2009, that a batch interface should, and the agent inherited the decision without inheriting a decider. The paper trail terminates in a commissioning project that closed before the agent vendor was founded.

Every element of that scene is individually mundane, which is the point. The estate fails the question not because anyone did anything wrong by the standards of their moment, but because thirty years of locally reasonable decisions were never re-underwritten when the population using them changed. The compounding argument of this piece is that agents change the population faster than any prior arrival — faster than the historians' corporate replication, faster than 2020's remote access — and that the sector's instruments, aimed at persons, perimeters and now megawatts, will not force the re-underwriting on their own.

What would falsify this

Four observations would damage or destroy the argument, and I would rather name them than wait for a reader to.

  1. A published measurement showing OT machine-credential rotation is actually happening — a sector survey or audit-derived dataset, with stated counting methodology, showing that service-account credentials in operational estates rotate at rates comparable to their IT equivalents. I could not find one; the argument leans on the structural reasons rotation should be rare plus the incident record, and a real measurement pointing the other way would beat both.
  2. Evidence that agent platforms deployed into energy operations mint into a separate identity plane by default — short-lived, workload-scoped credentials at the platform boundary, never touching legacy accounts. If the fastest integration path in practice does not run through the three populations, the inheritance multiplier collapses and this piece overstates the compounding.
  3. A CIP-family revision, or an equivalent binding instrument, that attaches lifecycle clocks to machine principals — an expiry, review or revocation deadline whose trigger is a property of the credential rather than of a person or session. The gap this piece describes is temporal; an instrument that starts the clock closes it.
  4. Demonstration that the compounding does not compound — that agents wired through legacy credentials do not, in practice, raise the cost of retiring them, because platforms abstract the credential behind a broker that can be re-pointed without touching consumers. Where that broker pattern is real, the correct conclusion is the companion piece's, not this one's.

The strongest honest summary is temporal. The estate rotates at the speed of outage windows. The instruments' clocks start on events machine principals never generate. The platforms mint at the speed of software. Three cadences, one estate — and the gap between them is not being watched by anything currently binding. The companion piece, published alongside this one, takes the constructive half: what a credential lifecycle looks like when it accepts the conservatism as a design constraint rather than an obstacle — issuance gated on an owner who holds an operational role, expiry that snaps to the maintenance calendar, a revocation plane that works during the incident with the IT link severed, and choreography for the one property no other sector forces you to confront: that revoking a credential mid-procedure is itself a hazard.