Attack surface management: turn discovered assets into owned exposure

The platform discovers a forgotten hostname associated with the company’s brand. Security sees a useful lead; the infrastructure team says it has never operated the service. The asset count has increased, but the organisation still does not know who can change the exposure.

For a security operations lead evaluating attack surface management, that handoff is a crucial part of the product’s value. Discovery matters when a team can establish responsibility and take an appropriate action. A longer list of plausible associations can otherwise become another queue of unresolved work.

Start by distinguishing three jobs: discovering assets missing from the inventory, enriching known assets with exposure information and moving validated findings through remediation. A product may support several, but the evaluation should show which one improves your operating process.

Ownership uncertainty is part of the workload

Internet-facing estates can reflect acquisitions, agencies, former suppliers and projects whose sponsors have moved on. The security team needs a way to distinguish technical association from current operational control.

Build that distinction into the pilot. Include a known internal asset, a supplier-operated service and a disputed historical relationship. Ask the reviewers to explain why each appears, what evidence supports its status and which team can resolve the remaining uncertainty.

The commercial comparison should include the analyst effort this creates. A product that finds more candidates may still be valuable, but the buyer needs to understand the time required to validate and maintain those relationships. Asset volume alone cannot establish that the operating team will close more important exposure.

Write the scope in operational terms

Define the business units, internet-facing services and relevant third-party relationships in scope. Identify the existing records available for comparison and their known limitations. An incomplete inventory is still useful evidence; it is not a reliable denominator for claiming complete discovery.

Ask the supplier to explain what the discovery method can observe and what it cannot. For example, Microsoft describes Defender EASM as using connections from known assets to infer relationships and discover further infrastructure. That makes the basis for attribution an important part of the evaluation. It is not proof that every inferred relationship establishes ownership.

Put attribution before intrusive validation

Stage	Record	Acceptance question
Candidate	Asset, discovery time and reason for association.	Can a reviewer understand why it appeared?
Attribution	Supporting records, uncertainty and proposed owner.	Is responsibility confirmed, disputed or still unknown?
Exposure review	Observation, validation method and permitted scope.	Is the evidence relevant and collected within the agreed authority?
Remediation	Accountable owner, action and expected outcome.	Can the receiving team act without reconstructing the finding?
Closure	Retest or other agreed evidence, date and residual issue.	Did the exposure change, rather than only the ticket status?

Use passive evidence and authorised checks appropriate to the scope. A branded hostname or a technical association should not be treated as permission to test someone else’s infrastructure.

Include a disputed asset in the pilot

Consider an illustrative case: the platform identifies a domain using the organisation’s brand, but a former partner operates it. The record contains a plausible relationship and an incorrect assumption about control.

Ask the evaluation team to establish the current relationship, assign responsibility and correct the inventory. Then observe whether subsequent discovery preserves the decision or repeatedly reopens the same issue. The useful result may be a supplier action or an external relationship to monitor, rather than an internally owned server to patch.

A platform that supports uncertainty explicitly can be easier to operate than one that forces reviewers to choose between “ours” and “irrelevant” before the evidence is available. Treat this as an evaluation criterion to demonstrate, not a feature assumed to exist.

Test the handoff into real work

Choose a small set of known test assets and representative findings. Send the resulting records through the proposed operating workflow. Ask the receiving team whether the evidence explains the asset, observed issue, business context and requested action.

Record duplicate tickets, rejected ownership and cases where the source observation cannot be reproduced. These are useful pilot findings. Do not conceal them by reporting only the number of discovered assets.

Bring business-service priorities into the handoff so a receiving team can understand the consequence of the exposure. A technically similar finding may have a different operational importance on another service.

Choose measures with a defensible denominator

For a controlled pilot set, measure whether expected assets are discovered and how quickly confirmed findings reach the right owner. Separately track disputed attribution, time spent correcting records and closure supported by evidence.

Report pilot coverage alongside the asset classes still untested. That lets the security operations lead see where to extend discovery next and how much validation work the wider deployment may create.

Agree who maintains the process

Name the owners of discovery scope, disputed assets, supplier relationships and remediation escalation. Include the review workload in the commercial comparison. A platform can expose a missing ownership process; purchasing it does not supply that process automatically.

Once ownership is clear, apply a vulnerability prioritisation method that accounts for the service consequence. Discovery and remediation should be one connected workflow, with the uncertainty visible wherever the connection is not yet established.