Anthropic's Critical Infrastructure Defense Program and the Remediation Backlog

What Anthropic Announced

The Anthropic Cyber Mission supports defenders with tools, research, and resources, starting with critical infrastructure and open-source software. It has four parts that matter to infrastructure owners.

• Critical Infrastructure Defense Program (CIDP). Frontier Claude models, Anthropic engineers on site, and threat research for the trusted providers who protect operational technology. It launched with eleven founding partners, a mix of large consulting firms, OT security vendors, and industrial equipment manufacturers, and several are already using Claude to fix vulnerabilities. Anthropic calls this a first step with a small cohort, and says it will expand to more security vendors, system integrators, and equipment manufacturers.
• State, local, tribal, and territorial governments. A program launched in June has offered frontier models and technical support to more than half of US states and to some of the largest public infrastructure operators, for code scanning and patching, incident response, and red teaming.
• OSS Scanner. Free, opt-in periodic scans for open-source projects, each report carrying a proof of concept, an explanation, and a suggested fix where one exists. The reports are model-generated and sent without human review, and Anthropic expects a true-positive rate above 90 percent.
• An expanded Cyber Verification Program. Broader access to Claude's cyber capabilities for defensive security teams of any size, including infrastructure operators.

The common thread is reach. More of the people who defend these systems will have a capable model looking at their code, configurations, and networks.

Fixing Is Now the Slow Step

Anthropic states the problem plainly: "It's easier than ever to find vulnerabilities, but verifying, prioritizing, and fixing these findings remains challenging." In its open-source work, months passed between a vulnerability being found and being fixed. For operational technology, the announcement says, a fix may have to wait until it can be applied safely to running machinery, and in rare cases that can take decades.

Anyone who has worked an OT backlog knows why. A change to a controller or a gateway usually needs some combination of these:

• An outage window, scheduled around load, season, or production, sometimes once a year.
• A vendor release, because the operator can't change firmware the vendor hasn't shipped.
• Retesting, since a configuration change on a certified build can void support or require the system to be qualified again.
• Field work, at a remote site with a technician on a truck.
• A compatible peer, because the device on the other end of the connection may speak only the old protocol.

AI can shorten the analysis around each of these: confirming a finding is real, tracing what it reaches, drafting the change, and checking the vendor's notes. The window, the vendor, and the truck stay on their own schedule. Anthropic's forecast is that AI will favor defense within two years, and it says that may not hold in the near term. The near term is where operators live.

What More Findings Means for Your Clients

When a provider starts working with a frontier model, the first thing its clients see is a longer, better-evidenced list. Each item on it needs the same four answers before anyone touches a running system:

1. Is it real? A model-generated finding with a proof of concept is a strong lead. Someone still confirms it against the system as built.
2. Is it reachable? The same weakness on an isolated segment and on a routable network carries different risk. Exposure decides the priority.
3. What breaks if we change it? Every client, peer, and integration that depends on the current behavior.
4. Who decides? A named person who owns the business risk of that system and signs the treatment.

Then each finding gets one of three treatments: remediate it, mitigate it with compensating controls, or accept the risk that remains with a review date. A backlog that grows faster than outage windows can only stay manageable when every item has one of those treatments recorded against it.

Where Closing Capacity Runs Thin

This is good news for defenders, and the founding cohort is a sensible place to start: large firms with the reach to learn quickly what works on real plants. Anthropic says the program will grow from there to more security vendors, system integrators, and equipment manufacturers.

The pressure will build furthest down the chain. Most small water systems, municipal utilities, and rural co-ops are served by regional integrators and engineering firms with small security benches. As discovery spreads, through the program, through state programs, and through the scanners and models those firms already use, their clients will receive more findings without receiving more staff. A client who gets a better list and no path to close it is left with more open risk on paper.

That makes remediation capacity the thing to plan for. The integrators who line up the fixing and the documentation now will be the ones whose clients feel the benefit.

Water shows the timing problem clearly. Under America's Water Infrastructure Act, community water systems serving 3,301 to 49,999 people were due to recertify their risk and resilience assessments by June 30, 2026, and their emergency response plans are due by December 31, 2026. A SCADA finding that lands this quarter should inform that plan: what the weakness reaches, how the operator responds if it is used, and which compensating control holds until the fix. For the integrators serving those systems, updating plans and closing findings now fall in the same window.

How Findings Close on a Running System

I've worked this problem from inside an operator. At a NERC/FERC CIP grid operator, as the vulnerability SME, I handled cipher-suite, protocol, key-exchange, and certificate findings on systems that could not simply be restarted. Most of the effort went into the step before any change: reading vendor advisories and release notes, opening support cases so the answer came back in writing, testing what a change would break, and tracing which peer still needed the weak setting. Findings were remediated where the systems allowed and accepted with documented compensating controls where legacy hardware couldn't take the fix.

The other half of the work sits with the team that runs the systems. Findings need to be verified before anyone acts on them, and the fixes that hold up wait on change windows that belong to that team. The most useful deliverable is a verified change they can apply.

On a running system, the closure paths usually look like this: a configuration change in the next window; a modern proxy in front of a legacy system, which shrinks the exposure to a short internal hop; or compensating controls such as isolation, an allowlist of named clients, connection limits, and monitoring for anything unexpected, each with evidence kept current until the finding closes.

That third group is the one a faster discovery cycle will grow most. The guide to compensating controls for legacy systems walks through the controls that carry weight and the one-page record an assessor can accept.

Running AI Tools Near a Running Plant

Handing powerful AI tools to people who work near critical systems is a fair thing to worry about. The water utility case above shows the other side of that worry: attackers already use these tools, and they don't ask permission. Defenders need the same speed, and what makes it safe is control: who gets access, where the tools run, and who approves a change.

The guidance already exists. In December 2025, CISA and Australia's cyber agency, joined by U.S. and international partners, published principles for integrating AI into OT built around human oversight of critical decisions and fail-safe design. In May 2026, six Five Eyes agencies published joint guidance on the careful adoption of agentic AI, centered on layered defense and strict access controls. Water utilities have a data reason to be careful too: in June, WaterISAC and AWWA advised members to scrutinize public-records requests from AI service providers asking for SCADA logs.

• Verify the people. Anthropic reserves its most capable cyber tooling for verified defenders, and CIDP starts with a small cohort of trusted providers. Inside the plant, the personnel risk assessment and training that already apply to anyone with access (CIP-004 for electric utilities) apply to whoever directs an agent.
• Treat an agent like a vendor session. A named identity, scoped and time-boxed access, multi-factor authentication for the person who starts it, and a session log: the controls remote vendor access already carries.
• Keep the analysis off the plant. Models read advisories, configurations, and records, and draft the change. Writing to a controller stays a human action inside the change window.
• Keep the data at home. Prompts, findings, and logs stay in the operator's environment, under the operator's keys.
• Record every step. Agent actions, approvals, and changes land in the same record as the finding they close.

That is how we work on OT engagements: AI handles the analysis outside the control network, and people make every change.

Trust comes from the same place it always has: verified people, scoped access, a human approval at the point of change, and a record of what happened. AI raises the speed of the work, and those controls keep pace with it.

What the Frameworks Already Expect

A vulnerability found by a model is still a vulnerability, and the frameworks infrastructure owners answer to already describe what to do when the fix can't land right away.

• NERC CIP-007 R2: evaluate released security patches for applicability at least once every 35 calendar days. For each applicable patch, within 35 days of the evaluation, apply it, create a dated mitigation plan, or revise an existing one, and carry out the plan on its schedule.
• NIST SP 800-53: flaw remediation sits under SI-2 and vulnerability monitoring under RA-5. A finding left in place is a risk response under RA-7, and work still in progress goes into the plan of action and milestones (CA-5).
• NIST Cybersecurity Framework 2.0: ID.RA-06 expects risk responses to be chosen, planned, tracked, and communicated, and ID.RA-07 expects exceptions to be recorded and tracked.

The common requirement is a dated decision for every finding. A larger volume of findings raises the number of those decisions, and the format stays the same.

Plan the Closing Work Now

Whether the findings come from the program, a state initiative, or your own tooling, the firm that holds the contract is the one the client calls. A few steps taken now make the difference between a backlog and a queue.

• Make verification a step. Confirm each finding against the system as built, and against the controls the tool can't see, before it reaches the client as work.
• Rank by exposure. Know which client systems sit on a routable network and which are isolated, so triage can rank on day one. Map every remote and vendor access path into them as well, including the cellular and satellite links that backhaul remote sites. A finding on a system those paths reach moves up the list. Attackers are doing the same mapping faster: in a case Dragos described in May, an intruder in a water utility's IT network used AI models to locate an industrial gateway and try its login. The credentials held, and the OT network stayed out of reach.
• Collect change windows and owners. For each client, the next outage and a named person who can sign a treatment. Without both, no finding gets a realistic date.
• Ask vendors now. A written question about firmware and supported protocol and cipher options for the oldest systems. The answers become the first line of each record.
• Keep one register per client. AI-found, scanner-found, and tester-found items in the same register with the same fields, in the format the client's framework expects.
• Decide who closes what. Keep triage and client-specific systems in-house. Line up an overflow bench for the standard fixes and the exception records before the volume arrives.

Where FEDLIN Fits

FEDLIN secures the links critical infrastructure runs on, and we work behind the integrator, provider, or engineering firm that holds the contract. When your clients' findings outgrow your own staff, we are the bench for the closing work. We close the cryptographic and security findings that can be fixed, harden the remote and vendor access paths that reach those systems, and write the compensating-control records for the ones that can't, as scoped, fixed-price work delivered in your format, with findings reported to you first.

Our bench includes OT/ICS and SCADA assessment experience across water and wastewater utilities, including risk-and-resilience work aligned to AWWA J100, so a water client's findings can be tied back to its risk and resilience assessment.

If you expect that volume, start a conversation before it arrives. Book a scoping call, and once an NDA is in place we scope the work over a channel you choose and return a fixed scope within 24 hours (business days). The partners page explains how firms bring us in, and critical infrastructure security and closing a security findings backlog describe the work.

One disclosure: FEDLIN participates in Anthropic's Cyber Verification Program, an independent verification that is separate from CIDP. FEDLIN has no role in CIDP.

Find it, fix it, or document why you can't.

Start With One Client

Pick the client whose backlog worries you most, and its oldest open finding. Write down the treatment, the owner, and the next date it will be looked at. If any of those three is blank, that is the first gap to close, and it will be the same gap on every new finding that client receives.

Anthropic's Critical Infrastructure Program: Common Questions