External visibility during incident response is an outside-in inventory, built without an agent, of everything published on the internet under an organization's name. While an incident is open it does two jobs: it estimates how far the compromise could reach, and it lists the other ways in that the adversary might have used.
The incident is already running when the phone rings. The internal team is containing, the response firm has landed or is landing, and somebody on the board has asked twice how big this is.
That question is harder than it sounds, and that is not my opinion.
The question that stalls the first hour
Revision 3 of NIST SP 800-61, published in April 2025, stopped organizing incident response into four phases and started describing it as a CSF 2.0 profile. The preparation activities, which live under Govern, Identify and Protect, were placed outside the response itself and at the same time named as what holds it up.
Inside that document, item RS.AN-08 covers estimating and validating an incident's magnitude. The note attached to it says that determining magnitude is often one of the most challenging aspects of incident response. The recommendation that follows explains why: look for indicators of compromise and evidence of persistence on both the assets known to be targeted and other potential targets. The warning after that is the hardest sentence in the chapter. Skipping the activity, or doing it superficially, underestimates the magnitude and lets the incident continue indefinitely on other targets without the organization's knowledge.
Two groups of target, then. What you know about, and what you do not. The second group is precisely what an internal asset list cannot give you, because the internal list describes what the company registered, and the adversary was never limited to what the company registered.
The same document is explicit elsewhere. Under asset management, the note says inventory information helps responders understand the impact of an incident, identify other assets that may be targeted, and prioritize response and recovery. Items ID.AM-01 and ID.AM-02 ask for current and automatically updated inventories of hardware and software, and name identifying shadow IT usage as one of the purposes.
The customer who arrived after the incident started
An e-commerce operation came to CSURFACE with the incident already under way. Technical response was contracted and running. What was missing was something else. Nobody could answer, with evidence, which of the company's assets were reachable from the internet at that moment, and which of them somebody could have come in through.
This was not sloppiness. It is the normal condition of any company that grew through projects, campaigns and integrations over ten years, with the inventory maintained by whoever was left over from each of those phases.
What the response team got was a map built from the outside, without depending on anything installed in the environment, while containment carried on.
Two lists you can build from outside in a few hours
The first list is what is published today under the organization's name. Discovery starts from a single domain and returns what is published under the group's name, covering subdomains, other brands, and assets belonging to subsidiaries that appear on no internal list. The first assets appear within hours and coverage settles over the following days. For a response team, the most useful part of that list is the history. Because the platform keeps a first-seen and last-seen record for every asset, service and certificate, you can answer what existed in the week of the incident rather than only what exists now.
The second list is the plausible paths. Knowing there are 300 assets is not enough. What matters is which of them expose an administrative service, which run a version with a flaw under known exploitation, and which concentrate reach, meaning which ones act as a bridge to the rest. That is the work of the exposure graph and the blast radius calculation, and it is the difference between handing over an inventory and handing over an ordered hypothesis.
Having the full map, kept current, narrows the search space to a handful of possible points, which is what the forensic team needs while the clock runs.
A leaked credential that still works is the fastest lead
This gets its own section because it tends to be the highest-value finding per hour of work during an incident.
Any organization that has been around for a few years accumulates leaked credentials tied to its own domain. They come from breaches at third-party services an employee signed up for with a work address, from repositories where somebody committed a key and later deleted the file without rewriting history, from collections that have circulated for years and get repackaged under a new name every season. The volume grows on its own and never stops.
Searching those sources for a company domain typically returns hundreds or thousands of lines. That is where the problem starts, because the raw list is worth very little. Most of it is dead: the password was rotated, the person left, the breached service no longer exists, or the pair was never valid and went into the collection as filler. A handful still work, and nothing in the list says which.
During an incident that stops being an annoyance and becomes a decision problem. The team has hours, not weeks, and needs to know whether a credential was the way in before deciding where to look. A thousand-line list does not answer that. Worse, it creates the impression that the credential angle was covered when it was not. The team looks, cannot act, files it away, and moves on to another hypothesis that may be the wrong one.
What would settle it is a single piece of information, and it is not in the list: which of those credentials still authenticate, right now, and against what service. Twelve pairs that work at this moment are not a smaller version of the list of a thousand. They are a different object. They stop being an indication and become a verified fact, with an owner, a target system and an obvious action attached to each one. The order of the day changes: those twelve accounts become the priority for lockout and for hunting active sessions, and the credential angle stops being an open question.
The reason almost nobody delivers this is that the check itself is uncomfortable. Testing whether a credential works means attempting to authenticate as its owner, which requires explicit authorization, care not to trigger account lockouts, and a record of everything attempted. Stopping at the match and handing over the CSV is far simpler. The CSV is also precisely the part that decides nothing.
What external visibility does not do
This section protects whoever will use the material, and it is worth more than the one above it.
External visibility is not a replacement for forensics. Endpoint logs, host execution timelines and disk images are outside its reach by construction. Nothing behind the VPN shows up, including over-permissive cloud accounts, unpatched workstations and misuse of valid credentials by somebody already inside.
Active validation happens where a testing module has coverage. Across the rest of the surface the assessment is passive, based on version and observed behavior, and a passive finding is a hypothesis rather than proof. Blurring the two during a crisis costs credibility inside the company, which is the scarcest currency a security team has in that week.
The platform also fixes nothing on its own and does not turn risk into a financial figure. Whoever decides what to shut down at three in the morning is still a person.
Where this fits for providers running SOC for other companies
Providers that embed the external surface into their own SOC service tend to use it at two distinct moments, and the second one shows up least often in proposals.
The first is arrival. A new customer in incident conditions hands over an asset list that does not hold up, and the scoping argument eats the first hours. Starting from a seed domain and building the surface from outside settles that without depending on access to an environment that is often still being restored.
The second is the week after containment. It is when the customer asks whether it is over, and it is the question RS.AN-08 says usually gets a superficial answer. Having the list of other potential targets, with a history of when each one appeared, turns that conversation into something checkable.
For the provider, the platform runs multi-customer by design, with per-organization separation, scope-bound access control and an audit trail. The partners page describes the model.
After the fire goes out
The work described here ends when the incident closes. What starts at that point is a different job, with a different metric and a different cadence, and it decides whether there will be a second incident.
The company in that case kept the surface monitored after containment, and the reason is always the same one. The list built during the incident had items nobody knew existed, and the only way to make sure they stop appearing is to look before the next one shows up.
That is the subject of why the company that already got hit tends to get hit again.
Where CSURFACE fits into this
Everything above is a market problem rather than a product problem, and it holds whether you solve it with your own tooling, with scripts, or with another vendor.
CSURFACE exists because we decided to solve three of those parts from the outside: the inventory of what is published under the group's name, with first-seen and last-seen history, in continuous discovery; ordering by reach and known exploitation rather than by theoretical score, in prioritization; and checking which leaked credentials still authenticate, which is the uncomfortable part almost nobody does.
If your team runs response for other companies, the conversation worth having is about partnership.
Frequently asked questions
Is external visibility useful during the incident or only afterwards?
Both, for different purposes. During, it sizes the reach and shrinks the forensic search space. Afterwards, it becomes continuous measurement of the surface, which is what prevents the next incident.
Does this replace an incident response service?
No. Containment, eradication, recovery and forensics stay the work of a response team with access to the environment. External visibility feeds that team the portion of the picture you can obtain from outside.
How fast is the map usable in a crisis?
The first assets appear within hours from a seed domain, with nothing installed. Coverage settles over the following days, and the first-seen and last-seen history comes with it, which allows reconstructing what was published on the date of the incident.
What will external visibility never find?
Anything that only exists inside the network. Lateral movement, credential abuse by somebody already authenticated, over-permissive cloud roles and unpatched hosts on internal networks. That part depends on internal telemetry and on forensic work in the environment.