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 shows why the second time tends to find an open door. The exposed flaw overtook the stolen credential as the most common way in, and meanwhile median remediation stretched from 32 to 43 days. CISA's catalog of vulnerabilities known to be under exploitation showed 26% remediated, which is the measure of how long an asset stays available after its flaw is already public.
Put the three together and what is left is a window that widens on its own: the likeliest way in got easier, the remedy got slower, and most of what is already known to be dangerous is still up. Patching faster stopped keeping up at that speed.
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, and they are not here to prove anything about a platform. What matters is what came next, when the operation got back on its feet and returned with a question nobody had asked before the incident, about 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 two documented cases, 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. Measuring that denominator instead of assuming it takes looking from outside, and continuously, because an internal list only records what somebody remembered to record.
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.
The public ThreatSensor base shows the size of the gap. Measured on 21 September 2026, the core that combines the KEV catalog, a public exploit and high EPSS at the same time is 26.9% of the monitored base. And the median between a CVE being published and the first public exploit is under one day: in 55.8% of cases the code already existed on the publication date.
Put that next to the 43-day median remediation time the 2026 DBIR measures. The exploit does not turn up halfway through the remediation window, it is already there when the window starts. That arithmetic is why ordering by observed exploitation moves the outcome more than any headcount added to the patch queue. The queue hands over the wrong items first, and that is where the time goes.
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. External visibility does not protect your AI agents. What it reaches is the AI infrastructure the company published and forgot, the console, the endpoint and the key, and the check that it answers. 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. Operating that way takes three things that rarely come together: an organization-level view with separation between customers, scope-bound access control, and an audit trail that survives a customer asking who looked at what. Without them the provider ends up running one scan per client from a single console, and the model does not hold.
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.
Where CSURFACE fits into this
None of the above depends on buying anything. Measuring the denominator, ordering by observed exploitation and closing the cycle are work, and you can do that with your own tooling, with scripts, or with another vendor.
CSURFACE solves three of those parts from the outside, with no agent installed: continuous discovery of what is published under the group's name, with first-seen and last-seen history; prioritization by observed exploitation rather than theoretical score, fed by threat intelligence; and the full CTEM cycle on top of that.
For anyone running a SOC for other companies, the conversation is partnership, because what gets bought there is a commercial model rather than a feature.
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.