Walls have EARRs. Yours might already be listening.
The old warning was “walls have ears”: a reminder that private conversations can still be overheard by someone you didn't account for. The internet-facing version of your organisation carries the same risk. It just doesn't need a listener in the same building.
Every organisation has a version of itself that it has never seen. It lives on the public internet, in DNS records, expired certificates, forgotten subdomains, and software versions nobody remembers installing. Attackers study this version closely. Most companies have never looked at it at all.
Passive reconnaissance is the part of an attack nobody budgets for defending against. It isn't a breach. It isn't even an intrusion. It's simply looking, from the outside, using nothing but what's already public, at what's exposed, what's outdated, what's misconfigured, what's been left running since a project that ended years ago. It requires no access, breaks no law, and happens to every organisation with an internet-facing footprint, constantly, whether anyone is paying attention or not.
Seen this way, a hacker's view of your organisation isn't a hypothetical. It's a specific, assemblable picture, built entirely from things you've already made public, whether you meant to or not. The question isn't whether that picture exists. It's whether you've seen it before it's used to get in.
What the walls are actually saying
A firewall, a mail server, a web server, a VPN gateway, whatever's exposed, running a version with a publicly disclosed, actively exploited vulnerability, the kind added to CISA's Known Exploited Vulnerabilities (KEV) catalogue once real-world attacks are confirmed, not obscure research papers. It isn't a theoretical weakness. It's a known door, and ransomware affiliates, the people who open such doors for a living, are scanning for it today.
In one recent external assessment, a single KEV-listed vulnerability like this sat inside a report of over three hundred findings across critical, high, medium, and low severity. All three hundred were real. Only one of them was the reason to stop what you were doing and act that day.
A server on an operating system the vendor stopped patching years ago sits quietly on the public internet, still working, still stable, unthought about since the day it was installed, which is exactly why it's still there and exactly why it's the easiest way in. End-of-life infrastructure doesn't announce itself as a risk. It just keeps running until someone decides to use it.
Missing or misconfigured authentication settings show up across a perimeter in more than one place, but email is where they're most exploitable. An incorrect SPF policy or an absent DKIM record means an attacker can send messages that appear to come from your own domain, to your own people, or to your customers. It is one of the cheapest fixes available and one of the most consistently ignored, precisely because it doesn't look dramatic on a scorecard. It just quietly enables the fraud that starts most breaches.
An administrative port sits open to the entire internet, not because of a sophisticated attack, but because a setting was never changed after a system went live. Most exposure of this kind isn't the result of an attacker's skill. It's the result of a default nobody circled back to.
These four rarely show up alone. An organisation running an unpatched, actively exploited system on its perimeter is very often the same organisation that hasn't reviewed its DNS records in years, hasn't rotated an old server off the internet, and has never checked whether its email domain can be spoofed. That isn't a coincidence. It's what happens when nobody has looked at the perimeter from the outside in a long time. The findings aren't related to each other. They're related to the same gap in attention.
None of this required an attacker to break anything. It only required them to look.
Attackers use the same automated tools and open-source techniques that a proper external assessment uses: internet-wide scanners, certificate transparency logs, DNS records, threat intelligence feeds, and known-vulnerability databases. None of it is exclusive to either side. The only real difference is what happens with what's found, and how fast.
What separates the finding that matters from the rest of the list isn't its category. It's a combination of three things: how easily it can be reached from outside, how likely it is to actually be used, and how much damage it opens the door to. An unpatched, KEV-listed vulnerability on a system exposed to the internet scores high on all three. A theoretical weakness in a system nobody can reach from the internet doesn't, however alarming it looks on paper. That's the rule the exposed system, the end-of-life server, the authentication gap, and the exposed admin port were each illustrating in their own way. It's also why a scorecard, on its own, isn't enough.
Why the score isn't the point
A security score is a snapshot. It tells you where you stand relative to a benchmark, which is useful, but it isn't the thing that matters. What matters is the very small number of findings, often just one or two, that actually determine whether this is a quiet year or a very bad one. A single unpatched, actively exploited vulnerability on a public-facing system outweighs almost everything else in the report combined. The rest is context. That finding is the headline.
Take a recent example. Overall rating: a solid B, a couple of points below the sector average, the kind of score that reads as reassuring at a glance. Nineteen individual categories assessed, and most of them passed comfortably: strong DNS health, clean brand monitoring, no domain impersonation, good credential hygiene. On a scorecard, that's a page of green. But one category, patch management, scored an F, driven by a small number of critical, actively exploited vulnerabilities sitting on public-facing infrastructure. That single F is what actually determined the organisation's real exposure that quarter. Eighteen strong categories didn't offset it, and nothing about the overall B made that urgent enough to see at a glance.
Most assessments present findings like these with equal visual weight: nineteen tiles, nineteen scores, no signal about which one to look at first. An assessment that doesn't tell you which finding to fix this week, specifically, by name, hasn't finished the job. It has produced a scorecard, not a warning.
What this actually costs
The instinct is to treat this as a technical problem with a technical price tag: the cost of a patch, an afternoon of engineering time. That's the wrong unit of measurement. The real cost shows up later, and it's rarely just financial. Of the scenarios worth modelling, ransomware is consistently the largest, driven less by the ransom itself than by the operational cost around it: downtime, incident response, the quiet, unbudgeted expense of an organisation trying to run normally while it isn't. There's the reputational cost, which is harder to model and slower to recover from than the technical fix ever is. There's the loss of anything genuinely sensitive sitting behind that perimeter, trade secrets, client data, commercially confidential material, once it's out, it's out. And depending on what the compromised systems actually control or touch, there can be a safety dimension too, for staff, for customers, for anyone whose personal information or physical circumstances were exposed. A number a board can act on has to account for all of that, not just the cost of the patch.
For most organisations, compliance is the lens this gets viewed through first, not last. Whether the relevant framework is GDPR, DORA, ISO 27001, or a sector-specific standard, the same public-facing gaps that create technical risk are usually the ones a regulator or an auditor would flag first too. Treating the compliance exposure as an afterthought to the technical exposure gets the order backwards for how most organisations actually experience risk in practice.
A vulnerability is a technical fact. What it costs you is a business decision.
The questions worth asking your own perimeter
A one-off look at your perimeter answers the question for today. It doesn't answer it for next month, when a new CVE lands on the KEV list, a certificate expires, or a supplier you depend on gets compromised and drags your exposure up with theirs. Ask yourself whether you know, right now, if any of your public-facing systems carry a vulnerability that's actively being exploited. Ask whether you'd still know in three months, without commissioning something new to find out. Ask whether anyone is watching your supply chain the same way, given that a vendor's exposure quickly becomes yours. And ask the only question that really matters: whether you'd find out from ongoing review, or from an incident.
Most organisations don't lack security tools. They lack a clear, outside-in view of what's already visible, and someone to tell them, plainly, what to fix first and why. Internal teams are already carrying their own patch queues and their own prioritisation calls, often with good judgement and too little time. This isn't a verdict on that work. It's the outside check that even good security programmes rarely get, because it's very hard to see your own perimeter the way someone outside it does, the way a hacker already does.
That's what an External Attack Reconnaissance Review is built to do, and it's the right place to start. No internal access, no agents installed, nothing beyond a domain name to begin. The first review takes five working days and ends with a senior consultant walking you through what was found. From there, most clients move to ongoing coverage, so the next KEV-listed vulnerability or exposed supplier gets caught before it becomes an incident, not after. Your perimeter doesn't stay still once the report lands, and neither should the people watching it.
If you don't know what your walls are saying, someone else already does.