Repeat compromise is the second incident at the same company after the first one has been contained. It rarely reuses the original vector. What repeats is the condition that opened the first one. An asset published on the internet that appeared on no list, and therefore sat outside patching and outside monitoring.
A lot of the companies that come to CSURFACE arrive with the incident already closed. Backups restored, legal did what legal had to do, the response report filed. What is left over is a question nobody on the team can answer with a list in hand. Where else can somebody get in?
That question is what this piece is about. The one that comes before it, what external visibility gives a response team while the incident is still open, is in the companion post.
The second time comes in somewhere else
Anyone who does incident response for a living knows the shape of this. The team closes the vector, rotates credentials, patches the box, writes the post-mortem. Months later the adversary is back, through an address that appeared on no diagram from the previous response.
The reason is uncomfortable. Response works on the scope of the incident, and the scope of the incident is whatever was found. No stage of it asks how many published assets exist outside that frame.
The 2026 Verizon DBIR supplies the context in three numbers that only mean something read together. Vulnerability exploitation moved ahead of stolen credentials as the most common way in. Median time to remediate rose from 32 to 43 days, meaning it got worse. And only 26% of the flaws in CISA's known-exploited catalog were fully remediated.
The front door is now the exposed flaw. The queue that should be closing it moves slower than last year. Three quarters of what is already known to be under attack stays open. Patching faster stopped working as a plan at the speed the problem moves.
Three days down, and the bill that came after
An e-commerce operation went three days without selling. R$ 900,000 in lost sales over that stretch. Operating expense for the period, which runs in the tens of millions, closed 11% above plan, between emergency response and overtime.
Those numbers came from the company itself. They are here because of what happened next. The company did not come back looking for someone to fix the server. It came back wanting to know what else was published under its name.
That is the moment the conversation changes subject inside a customer. It leaves the incident and enters the inventory.
The official inventory is not the surface
In the two cases published on the CSURFACE homepage, a mid-sized financial institution ran on 160 external assets in its official inventory and discovery returned 271. A B2B SaaS startup monitored 85, and discovery returned 570.
The security coordinator at one of Brazil's largest companies put the effect in one line that sits on the site: finding out we were monitoring only 15% of our real attack surface.
None of those numbers describe a new flaw. They describe a denominator. Every coverage metric a SOC reports, the share of assets monitored and the share inside the patch window, comes from a list somebody typed by hand once and never audited again. A campaign subdomain, a staging environment that went up alongside an integration, a domain inherited from an acquisition. Continuous discovery exists to measure that denominator instead of assuming it is right.
One caveat almost no vendor offers. Finding 400 new assets, by itself, doubles the team's queue and reduces no risk at all. Discovery without ordering is debt.
Sorting by theoretical severity does not reduce exposure
Most companies sort their queue by CVSS. It is the ordering that ships with the data, and it answers a question almost nobody is asking, which is how bad the flaw would be if exploited.
The operational question is different. Out of thousands of open findings, which ones are being exploited against somebody right now, and which of those sit on an asset of mine that is reachable from the internet.
ThreatSensor data published on the threat intelligence page shows the size of the gap. Of the 383 core vulnerabilities that combine the KEV catalog, a public exploit and high EPSS at the same time, 168 are under active exploitation right now. The State of Digital Exposure report, aggregating 68 organizations with completed discovery, records that a public exploit appears on average five days after the flaw is disclosed.
Five days is under an eighth of the 43-day median remediation time. That arithmetic is why prioritization by real exposure moves the outcome more than any headcount added to the patch queue.
The cycle that closes this already has a name
What I described above is a five-phase cycle: scoping, discovery, prioritization, validation and mobilization. Its name is CTEM, continuous threat exposure management, and it has existed as a public framework since 2022. A newer piece of vocabulary, preemptive exposure management, pins down what CTEM left open, which is when the work happens. Before an alert exists.
Two honest notes about the framework. Analyst firms do not certify products, so no vendor holds a CTEM badge. And the cycle sets no cadence, which means you can run all five phases once a quarter and call it CTEM without lying.
For a company that has already been compromised, cadence is the variable that matters. The window between an asset becoming exposed and somebody on the team learning it exists is the interval where repeat compromise happens.
The AI infrastructure nobody registered
A new class of forgotten asset showed up in the last two years, and it earns its own section because almost no inventory tracks it.
Product and data teams stood up orchestration consoles, inference endpoints and test environments with models attached. Much of it went live through engineering without passing security, stayed up after the experiment ended, and never entered any CMDB. The shadow AI entry describes the result: a good share of shadow AI becomes an internet-exposed asset before it becomes a data incident. The agentic AI security entry explains why. Every agent in production adds an endpoint, a credential and an integration, and a new asset enters the external surface like any other.
The limit has to be written down, because the limit decides whether the sentence above is sales copy or true. CSURFACE does not protect your AI agents. It finds the AI infrastructure your company published and forgot, the console, the endpoint and the key, and checks whether it is reachable. Agent identity inventory, OAuth token scope analysis and prompt injection testing need internal access and belong to a different product category.
What already works with nothing new built is the queue. When a critical CVE lands in an AI stack component, prioritization reorders by what is under observed exploitation, without asking what kind of software is affected.
Providers running SOC for other companies watch this script repeat
A provider serving dozens of customers sees the whole cycle several times a year, always with the same shape. The customer buys monitoring over the list it handed in, the incident comes in from outside that list, and the post-incident review turns into an argument about contract scope.
That is why the external surface tends to be the first module a managed SOC embeds in its own service. It attacks the problem that sits before monitoring, which is knowing what to monitor. The platform runs with an organization-level view, per-customer separation, scope-bound access control and an audit trail, which is the floor for operating that way. The partners page describes the model.
The commercial payoff for the provider shows up in the following quarter's report, when it can put a line in front of the customer that no competitor shows: how many assets entered and left the customer's surface since the last meeting, and how many of those nobody had ever registered.
Frequently asked questions
Does repeat compromise always come through the same path?
Rarely. The vector used in the first incident is usually the best-handled one afterwards, because it is the one the response documented. What survives is the background condition, which is published assets outside the inventory. The second incident comes through one of those.
Doesn't a well-built SOC solve this on its own?
A SOC solves detection across what it monitors. Where the list of monitored assets comes from was never inside its scope, and that question sits before detection. The two jobs are complementary, and external surface work comes first in the order.
How long does it take to map the external surface?
The first assets appear within hours from a seed domain, and coverage settles over the following days. What takes longer is ownership attribution, meaning proving that a discovered asset really belongs to the company and not to a lookalike.
Does CSURFACE protect AI agents?
No. It finds AI infrastructure published on the internet and checks whether it is exposed. Runtime agent protection, non-human identity inventory and prompt injection testing require internal access to the environment and are not done by an external platform.
What about while the incident is still open?
That is the other half of the subject, covered in what external visibility gives an incident response team, which describes the lists you can build from outside in a few hours with the incident in progress.