For most of the 2010s, attack surface management was a manual practice. A penetration tester would be engaged for a two-week external assessment, produce a report enumerating exposed services, unpatched systems, and misconfigured cloud storage buckets, and the security team would remediate the highest-severity findings before the next quarterly assessment. The problem with this model is not that the testers were doing poor work — in their bounded scope, they were thorough. The problem is that the attack surface they assessed on day one of a two-week engagement was different from the attack surface that existed on day fourteen. Modern enterprise environments change continuously: new subdomains are provisioned for a marketing campaign, a developer spins up an S3 bucket with public read permissions to test a prototype, a third-party supplier adds an integration that exposes an API endpoint the security team did not know existed. The attacker who is scanning your external perimeter continuously will find these gaps before any quarterly penetration test does.
The External Attack Surface Management (EASM) category emerged from the recognition that external exposure needs continuous monitoring rather than point-in-time assessment. The technical challenge is non-trivial: building a complete, continuously updated map of an organisation's external footprint requires DNS enumeration at scale, certificate transparency log monitoring, passive DNS analysis, web crawler discovery, BGP routing table analysis, and correlation of all these data sources against a dynamic asset inventory that the organisation itself often cannot maintain accurately. When we backed Detectify in 2020 and later evaluated Hadrian in 2022, we were tracking how each company handled the hardest part of this problem: attribution — determining which discovered assets actually belong to the target organisation versus sharing infrastructure with third parties.
What changed between 2019 and 2022 was the cloud migration effect on attack surface geometry. An enterprise whose primary external exposure in 2015 consisted of a DMZ with a handful of published services — mail gateway, VPN concentrator, web application firewall — had, by 2022, an attack surface that sprawled across multiple cloud providers, dozens of SaaS integrations, API gateways serving mobile apps, and shadow IT infrastructure that the security team had not formally inventoried. The concept of a perimeter had not just blurred; it had disaggregated into hundreds of independently deployed components, each with its own exposure profile. Automated EASM platforms running continuous discovery against this environment were finding genuinely novel findings on a weekly basis — not because organisations were being careless, but because the rate of change in their infrastructure now exceeded any manual process's ability to track.
The maturation of the EASM category by mid-2022 had produced a bifurcation in approaches. One class of tools focused on discovery and inventory — building the most complete possible map of external exposure, presented as a dashboard with severity scoring against CVE databases. The second class went further: rather than simply mapping what existed, they tested it. Automated offensive testing — probing discovered services for exploitable conditions, not just known-vulnerable versions — is a fundamentally different capability. Hadrian's approach represented this second class: a platform that could not only enumerate your external attack surface but chain together multi-step attack paths and validate which exposure combinations were actually exploitable. This distinction matters because high-severity CVEs on systems that are not reachable from an attacker-controlled position are lower priority than medium-severity vulnerabilities on a publicly exposed service processing sensitive data. Context-aware exploitation validation changes the prioritisation calculus entirely.
We should be direct about a limitation that persists even in the most sophisticated EASM platforms as of this writing. Discovered attack surface is still primarily technical: services, certificates, IPs, hostnames. The human element — social engineering attack surface, credential exposure through data breaches, supplier personnel with access to target systems — is not easily represented in an automated discovery model. The organisations that treat EASM as their primary attack surface visibility mechanism are missing a category of risk that threat actors exploit heavily. EASM is a necessary but not sufficient component of external exposure management, and the companies that will build lasting franchises in this space are those that can coherently integrate technical surface discovery with credential intelligence and supply chain exposure mapping.