CISA advisory documents the cost of response plans that skip third-party engagement

What the advisory found

CISA advisory AA25-266A, issued on September 23, 2025 under the title "CISA Shares Lessons Learned from an Incident Response Engagement," draws three lessons from a real intrusion, and a dev.to analysis of the document argues that the one most readers will skip concerns third parties. As the advisory records, the incident response plan in that engagement offered no way to bring in outside help quickly and no mechanism for giving that help access to the resources it needed. The omission delayed parts of the response during the phase of an incident when every hour counts most.

The intrusion behind the lesson

The timeline in the advisory, as recounted in the dev.to post, starts with suspicious activity on a public-facing application. An attacker exploited CVE-2024-36401 on two hosts, moved laterally to a web server and a SQL server, and was caught only when endpoint alerts fired on the database server roughly three weeks after the initial activity. The third-party lesson sits in the response phase: by the time the intrusion surfaced, the plan's missing provisions were already limiting what responders could do.

Access is the slow part

Engaging external help is not instant. Contracts, contact details and access provisioning all take time to arrange, and a plan with no procedure for them forces an organization to negotiate all three while an incident is live. The dev.to writeup adds a measurable dimension to this readiness problem: nobody can pre-authorize access to systems that were never documented in the first place.

To illustrate how many potential blind spots exist, it cites ZoomEye exact-match observations collected on September 29, 2026 for the product named in the advisory, GeoServer: 57,663 internet-facing instances in total, 47,664 of them running an HTTP service, 9,770 listening on port 8080 and 625 on port 8443. The exercise it proposes for any single organization is smaller in scale but sharper in effect: take your own fingerprint matches for exposed products and check each one against the documentation your response plan depends on. Every host that fails that check is a host an external responder cannot be cleared to examine in advance.

What the recommendations imply

Read as a checklist, the advisory's recommendations amount to pre-work that has to happen before an incident:

• Name the third parties you would call and the circumstances that trigger the call, since contracting and legal review can outlast the incident they are meant to support.
• Pre-provision access paths, so it is known in advance how an external responder obtains read-only access to endpoint telemetry, web logs and the relevant cloud or on-premises consoles.
• Define in writing what an outside party may and may not touch, so access can be granted rather than negotiated live.
• Test the arrangement, because an untested access path may simply not work when it is needed.
• Keep escalation contacts, on-call rotations and authorization levels current, since plans that go unreviewed drift out of date.

Why it matters

The three lessons in the advisory reinforce one another. An unpatched public service creates the incident, missing detection coverage lets it run for three weeks, and a response plan without a third-party procedure slows the response once it is finally noticed. Any one of them alone might have been manageable; in combination they turned a patchable flaw on an exposed host into an intrusion lasting weeks.

Organizations that rely on external providers or integrators face an added wrinkle. Those providers hold deployment knowledge for services internal teams may never have documented, which makes them useful for filling gaps in the asset inventory yet also a hard dependency once response begins. Reviewing the third-party clause in your own plan is, on the dev.to analysis's argument, a cheap fix that shortens the gap between the moment an alert fires and the moment outside help is actually working on the problem.