Vendor attack surface monitoring is the continuous discovery and observation of everything a vendor exposes to the public internet, gathered without the vendor's participation. It answers a narrower question than a full TPRM assessment does - not "does this vendor have sound internal controls," but "what does this vendor's external footprint look like right now, and has that changed since the last time we looked." The narrow scope is the source of its usefulness: because it needs no vendor cooperation, it can run on every vendor in a portfolio, continuously, starting the day the relationship is added rather than the day a questionnaire comes back.
What it actually discovers
The signal set is entirely externally observable - the same categories a security-rating provider, or a determined attacker, would find, collected the same way:
- Domains and subdomains. The full inventory of a vendor's internet-facing hostnames, surfaced through passive DNS, certificate-transparency logs, and public registration data - including forgotten subdomains that still resolve long after whatever they served was decommissioned.
- Exposed services and ports. Which services actually respond on which hosts: an administrative interface left reachable, a database port open to the internet, a staging environment that was never meant to be public.
- Certificate and DNS hygiene. Expired or misconfigured TLS certificates, missing or weak email-authentication records (SPF, DKIM, DMARC), and DNS misconfigurations that make spoofing or subdomain takeover easier.
- Cloud storage exposure. Publicly readable or writable object storage carrying the vendor's data - or, in a shared-tenancy failure, yours.
- Technology fingerprinting. The software, frameworks, and versions running on internet-facing systems, cross-referenced against newly disclosed vulnerabilities as they are published rather than at the vendor's next renewal date.
- Credential exposure. Vendor employee or service credentials that surface in breach dumps and still validate against the vendor's own infrastructure.
How the discovery is actually done
Almost all of it is passive reconnaissance - reading data that already exists in public sources (certificate-transparency logs, passive DNS, WHOIS/RDAP, breach corpora) rather than sending traffic at the vendor. A smaller layer is lightweight active scanning: connecting to a vendor's own public-facing hosts the same way any browser or client would, to confirm what is actually listening, not just what DNS claims should be there. OWASP's Attack Surface Analysis Cheat Sheet documents the same discipline applied inward, to an organization's own systems - map the entry points first, then reassess whenever the system changes, because an attack surface enumerated once and never revisited is already stale. Run outward, against vendors, it is the identical logic on someone else's infrastructure.
This is not a hypothetical exercise; the U.S. government runs it operationally on its own agencies. CISA Binding Operational Directive 23-01 requires federal civilian agencies to perform automated asset discovery and vulnerability enumeration across their networks on a defined cadence, precisely because undiscovered assets are the ones nobody is defending. CISA also offers this as a free external service through its Cyber Hygiene vulnerability-scanning program, which continuously scans an organization's internet-facing systems and reports what it finds - the same outside-in model a TPRM program applies to vendors instead of to itself.
What it structurally cannot see
This is where the honesty matters. Attack surface monitoring reports what is visible from outside; it says nothing about how a vendor handles data once a request is past the front door. It cannot see access-management practices, encryption key management, employee security training, backup and recovery procedures, or what a vendor's own subprocessors are doing on its behalf. A vendor can run a spotless external footprint and still have weak internal access controls - and a vendor with one flagged finding may have compensating controls that make the finding immaterial. That gap is exactly why attack surface monitoring functions as one input to a program, not a substitute for the evidence-based assessment covered in security ratings vs evidence-based TPRM.
There is a second, more structural blind spot: shared infrastructure. When many vendors sit behind the same CDN, cloud region, or DNS provider, their external footprints start to look like each other, and a finding on the shared provider can appear to implicate every vendor sitting on top of it. Distinguishing a vendor-specific exposure from a symptom of concentration risk in the underlying provider takes judgment the raw scan output does not supply on its own.
Where it fits in the TPRM lifecycle
Attack surface monitoring earns its place at every stage, not just onboarding. During tiering, external footprint size and hygiene are a fast, no-cooperation-required input for the initial risk cut, before a full questionnaire ever goes out. During the life of the relationship, it is the backbone of continuous monitoring - it is specifically the "external attack surface" signal category that continuous monitoring correlates against vulnerability, breach, and business-change signals. And at offboarding, it is a genuine verification step rather than a formality: if a vendor's subdomains, certificates, or services attributed to your relationship are still resolving after access was supposedly revoked, that is direct external evidence the offboarding did not fully close.
Standards that anchor the practice
- Attack surface, defined. NIST's glossary describes it as the set of points on a system's boundary where an attacker can try to enter, cause an effect on, or extract data from that system - the definition this whole discipline operationalizes against a vendor instead of your own network.
- Continuous monitoring as a control, not a preference. NIST SP 800-53 Revision 5's CA-7 control requires an organization-wide continuous monitoring strategy, rather than point-in-time assessment, for exactly the reason a vendor's posture changes faster than an annual review cycle can track.
- ICT third-party monitoring under DORA. DORA requires in-scope financial entities to monitor ICT third-party arrangements on an ongoing basis, not solely at contract signing - external attack surface signal is one of the practical ways that ongoing obligation gets satisfied between formal reassessments.
Where this sits among TPRM platforms
Attack surface monitoring is the raw input most security-rating providers build their scores from - BitSight, SecurityScorecard, and UpGuard are all, at core, outside-in observers of exactly this signal set, aggregated through proprietary methodologies. Panorays pairs the same external monitoring with assessment workflow; OneTrust and ProcessUnity emphasize the evidence-and-workflow side more than the external-scanning side. Rescana runs continuous attack surface discovery as one input into an evidence-based score, correlated with the rest of a vendor's posture rather than reported as a standalone number - the evaluation question worth asking any platform is not whether it collects this signal, but whether it correlates the signal to the vendors that matter and turns a material change into a tracked action instead of another dashboard tile.
Frequently asked questions
What is vendor attack surface monitoring?
Vendor attack surface monitoring is the continuous discovery and observation of a vendor's internet-facing footprint - domains and subdomains, exposed services and ports, certificate and DNS hygiene, cloud storage exposure, and the technologies running on public-facing systems - gathered entirely from outside, without the vendor's cooperation. It updates continuously as the vendor's real footprint changes, rather than reflecting a single point in time the way a questionnaire does.
What does vendor attack surface monitoring actually detect?
It detects what is externally observable about a vendor: its full domain and subdomain inventory (via passive DNS and certificate-transparency logs), open ports and exposed services such as an unintended admin panel or public database, expired certificates and weak email-authentication records, publicly accessible cloud storage, outdated or vulnerable software versions fingerprinted on internet-facing hosts, and vendor credentials that have surfaced in breach data. It does not detect anything about the vendor's internal controls, since none of those signals require or involve access inside the vendor's environment.
Does attack surface monitoring replace vendor security questionnaires or assessments?
No. Attack surface monitoring is an outside-in signal about what a vendor exposes to the internet; it cannot see access management, encryption key handling, employee training, backup practices, or subprocessor arrangements, which is precisely what evidence-based assessment - questionnaires, SOC 2 and ISO 27001 reports, contractual controls - is built to cover. The two are complementary: attack surface monitoring is well suited to continuous, no-cooperation-required coverage across an entire portfolio, while evidence-based assessment covers the internal-control questions that matter most for critical and regulated vendors.
How is vendor attack surface monitoring different from a security rating?
Attack surface monitoring is the raw signal - the discovered domains, exposed services, certificate state, and vulnerable software versions themselves. A security rating is one layer above that: a provider such as BitSight, SecurityScorecard, or UpGuard takes attack-surface (and other) signals and compresses them into a single proprietary score using its own weighting. Attack surface monitoring on its own gives you the underlying facts and lets you decide what they mean for a given vendor; a rating gives you a faster answer at the cost of transparency into how it was calculated.