Internet-exposed servers: not if, but when

Try a quick exercise: list everything in your company that currently answers a request coming from the internet. The firewall. The VPN concentrator. The mail server. The ERP web panel. The RDP gateway opened "temporarily" in 2021 for someone working from home. The test server left running after a project ended. If that list took you more than two minutes, or if you are not confident it is complete, you already have half the answer this article is about.

Nobody attacked you today for who you are. The sensor networks that listen to internet scanning traffic recorded roughly 218 million events in January 2026, coming from 248,608 unique hosts — 32% more than the previous month, including 113 million attempts aimed at MSSQL database servers alone. These are automated attempts and scanning traffic, not successful breaches; the distinction matters. But at that volume, exposure stops being a question of probability. It is not if, but when — and the variable that actually matters is what happens in the hours afterwards.

What is actually exposed to the internet in your company

Most small and mid-sized companies cannot answer this question within a working day. Not out of negligence, but because the list exists nowhere: it lives in the head of an administrator who left two years ago, in a firewall configuration nobody has read since it was written, and in the collective memory of three people who remember different things. And whatever appears on no list also appears in no patching plan.

• Publicly reachable web administration panels — in a study of 3,000 attack surfaces, 60% had such panels exposed.
• Risky ports open directly to the internet — 49% in the same study.
• Databases reachable from outside — 42%; exactly the category those 113 million January attempts were aimed at.
• Perimeter devices (firewall, VPN, gateway) treated as hardware that "just works", rather than as software that must be updated.
• Test, demo or staging servers left running, still present in DNS, with no assigned owner.
• Nobody owns the list: the inventory is not a versioned document, it is a memory.

The pattern is not one badly configured server. It is that the attack surface grows with every new project and never shrinks, because nobody has the explicit job of shrinking it. Every integration, every supplier with access, every "let us leave it open until next week" adds something that never closes again. You cannot defend what you cannot enumerate — and the uncomfortable part is that the attacker enumerates your infrastructure weekly, automatically and for free.

Vulnerability exploitation has become the main entry point

The Verizon DBIR 2026 recorded a shift that had been building for years: vulnerability exploitation overtook stolen credentials to become the number one initial access vector, for the first time in the report's 19-year history. That is 31% of the analysed initial access vectors, up from 20% the previous year — a 55% year-over-year jump. The figure does not mean 31% of companies were attacked that way; it means that among the successful entries researchers analysed, nearly one in three came through exploiting a vulnerability rather than through stolen passwords or phishing.

Where those exploits land is the part that should interest you most. Also in DBIR 2026, perimeter devices and VPNs climbed from 3% to 22% of exploitation-driven breaches — sevenfold in a single year. Mandiant analyses point the same way: in the period analysed, the four most frequently exploited vulnerabilities were all in perimeter devices (Palo Alto PAN-OS, Ivanti Connect Secure, Ivanti Policy Secure and Fortinet FortiClient EMS). In other words, the exact box you bought to defend the perimeter became the most attacked thing on it.

What AI actually does on the attacker's side

It is worth being precise here, because the public story has fixed itself on flawlessly written phishing emails. That is the visible part and, honestly, the least interesting one. The real change is not at the start of the attack chain but in its middle: AI removed the human from the stages that used to consume hours of skilled operator time.

The evidence has started to surface publicly. In November 2025, Anthropic disclosed a cyber-espionage campaign attributed to a China-nexus actor, tracked as GTG-1002 and recorded as MITRE ATT&CK Campaign C0062: run in September 2025 against roughly 30 targets, it is considered the first campaign orchestrated largely autonomously by an AI agent, which executed an estimated 80-90% of the operational tasks — reconnaissance, vulnerability discovery, exploitation, lateral movement, credential harvesting and exfiltration. Separately, in May 2026 the first fully autonomous post-exploitation attack driven by a language model was documented in the wild, completed in under an hour.

The consequence is economic, not technological. Target selection used to be a human decision: someone picked you and spent an afternoon on you, and the cost of those hours was, in effect, your protection. Being small genuinely was a defence. When scanning, triage, exploitation and lateral movement become a single automated pipeline instead of four human tasks, "we are not worth anyone's effort" stops being a category — because nobody's effort is being spent.

You are no longer chosen as a target. You are simply enumerated.

The three clocks

Whether you end up breached is, fundamentally, a race between three timers. Most companies watch only one of them, and usually not the one they can influence.

1. 1The attacker's clock — the time from a vulnerability being published to an exploit being used in the real world. It fell from over 700 days in 2020 to roughly 44 days in 2025, and Mandiant reporting in 2026 shows 28.3% of published vulnerabilities being exploited within the first 24 hours. For new critical vulnerabilities in perimeter devices, the median interval to mass exploitation was zero days: exploitation begins practically at the same time as publication, sometimes ahead of the fix.
2. 2Your clock — the time from publication until you have actually applied the fix. The median rose from 32 to 43 days, while organisations have 50% more vulnerabilities from the KEV catalogue to handle than a year ago. Your clock is slowing down precisely as the workload grows.
3. 3The detection and response clock — how long it takes you to notice something is wrong and act on it. It is the only one of the three you can change in months rather than years, and the only one that depends almost entirely on you rather than on a vendor's schedule.

Put the first two clocks side by side and you get the arithmetic of this whole article: you cannot fix in 43 days something that is exploited in zero. This is not a discipline problem — no IT team, however good, wins a race with that handicap. It is a structural one. Perfect prevention has stopped being a complete plan for anything sitting on the perimeter.

The point is not to sell fear, but proportion. "Not if, but when" is not a marketing formula, it is the result of a subtraction anyone can do. And its practical conclusion is reassuring rather than oppressive: if you cannot win the patching race, then two other things matter, and you control both of them. How many clocks start at all — that is, what is exposed — and how quickly you find out that one of them went off.

What to do: shrink the surface, shorten the clock

This is not a security programme, it is a sequence. The first two steps cost nothing but attention and can start on Monday morning.

1. 1Build the real exposure inventory. Not the list in someone's head, but what actually answers a query from outside: public IP addresses, subdomains, open ports, administration panels, forgotten services. The result must be a versioned document with a named owner, not an email.
2. 2Close everything that has no business reason to be public. Administration panels, RDP, databases, management interfaces — moved behind the VPN or restricted by IP address. This is usually where most of the attack surface disappears, with no budget at all.
3. 3Treat the perimeter as critical software, not as hardware. Subscribe to the security advisories of your firewall, VPN and gateway vendors, and name someone who actually reads them. These are the devices at the top of the exploitation charts, not your application servers.
4. 4Keep two patching calendars, not one. A monthly one for internal infrastructure. An emergency one, measured in hours, for anything exposed to the internet that appears in the KEV catalogue. The second calendar exists purely because the attacker's clock is at zero on the perimeter.
5. 5Scan recurrently, not annually. The surface changes with every new project, every integration, every supplier added. A scan from six months ago describes a company that no longer exists.
6. 6Instrument detection on exposed assets. The goal is simple and verifiable: to learn about an anomaly from an alert, not from a client who cannot place an order or an employee calling to say things "feel slow".
7. 7Write and rehearse the response before you need it. Who decides to isolate a system, who informs management, who talks to clients, and within what timeframe. A two-hour tabletop exercise is worth more than a 40-page plan nobody has read. Recovery and tested backup come after this layer, not instead of it.

What this looks like with an external partner

The first two steps you can do internally within a week, and they are worth doing even if you never work with anyone external. Steps 3 to 7, however, almost always fail for the same reason: they have no recurrence and no owner. It is not a competence problem but a continuous-attention problem, inside a company where everyone already has a full workload. That layer is exactly what we cover as part of our cybersecurity practice.

• Monthly external and internal scanning, with a CVSS-prioritised report, concrete remediation recommendations and a retest after the fix — the monthly Vulnerability Scanning package, sized by the number of hosts.
• Round-the-clock monitoring and real-time alerting on Zabbix and Grafana, with executive dashboards and a monthly availability and incident report. From our own project experience, around 80% of incidents are proactively detectable before anyone calls.
• An incident response plan with playbooks for ransomware, data exfiltration and business email compromise, plus tabletop exercises with management — so the hard decisions are made in advance, not in the first hour of a crisis.
• An accountable person, even if they are not your employee: CISO as a Service, for companies that need a strategy and a counterpart for the authorities but cannot justify a full-time specialist.

Sizing follows the number of hosts and devices, and the real scope is decided after the first inventory — very often the surface turns out to be smaller than the fear and larger than the list the company started with.

Conclusion

Internet exposure is not a mistake, it is the natural consequence of doing business online. What changed is that automation removed the cost of selection for the attacker, and the arithmetic between their clock and yours is not going to reverse. The difference between an incident and a crisis remains, almost always, how small your surface is and how quickly you find out. If you cannot say right now, within two minutes, what in your company answers a scan coming from the internet, that is where we start — let us talk for 30 minutes and you leave with the list, whatever you decide afterwards.