Poxek Research · easm
An EASM private preview should begin with evidence, not a dashboard promise
A private-preview approach for external attack-surface work that keeps discovery, review, and ownership boundaries explicit.
The product boundary matters before automation
External attack-surface management is often presented as a simple sequence: point a platform at a company name, receive a list of internet-facing assets, and route the result to remediation. That sequence hides the decisions that determine whether the output will be trusted. Which organization identifiers are in scope? Which public signals are collected? How is a proposed relationship distinguished from a confirmed one? Who can reject an incorrect association? What happens when an observation changes or disappears?
Poxek EASM is in private preview for teams that need a continuously updated, evidence-backed model of their externally visible perimeter. The approach is deliberately narrower than a promise of complete internet coverage or automatic ownership attribution. Its starting point is a defined set of known organization identifiers and a reviewable record of how an external observation relates to them.
That boundary follows a practical lesson from asset-management guidance. CISA's BOD 23-01 treats discovery as a building block of visibility and separates it from vulnerability enumeration. NIST CSF 2.0 places asset management alongside risk assessment and continuous monitoring rather than reducing it to a scan result. An EASM workflow can help create a common starting point for those activities, but it cannot replace the internal systems and accountable people that determine business ownership.
A private preview is a joint operating exercise
The private-preview model uses a bounded operating flow with a small group of participants. The first work is scoping. A participating organization identifies the domains, brands, address ranges, subsidiaries, or other seed identifiers that it is authorized to include. It also identifies exclusions: third parties, merger targets, research environments, or any network range that should not be contacted.
The next work is defining what counts as evidence. Externally observable DNS data, certificate information, host and service observations, and related public signals can support a proposed asset relationship. The evidence must remain tied to the observation time and collection method. Certificate Transparency, for example, publicly logs certificates and precertificates so that certificate-authority activity can be audited; RFC 6962 does not say that an entry proves a current, reachable application or organizational ownership. A preview workflow should retain that distinction rather than turn every name in a log into a confirmed asset.
Participants then need a review protocol. A proposed asset may be confirmed, marked as a third-party dependency, rejected as unrelated, or left unresolved pending more evidence. The decision should carry an owner or a review status and should not overwrite the underlying collection record. That separation avoids a common failure mode: a later analyst sees only a polished asset label and cannot tell whether it came from public evidence, an internal confirmation, or an earlier guess.
This is product discovery as much as security discovery. It reveals the systems of record a team already relies on, the identifiers that create the most ambiguity, and the handoffs that cause delay. Those constraints shape a usable perimeter model more than the number of rows displayed in an early dashboard.
The proposed Poxek EASM workflow
The current Poxek EASM brief describes four stages: seed known organization identifiers, discover externally observable assets, correlate relationships and changes, and surface review-ready context. In a private preview, each stage should remain inspectable.
Seed known identifiers. A participant supplies approved anchors and their scope. Seeds provide a starting hypothesis; they do not grant permission to expand into any similarly named organization or network. The preview should document who supplied each seed and when its scope was approved.
Discover externally observable assets. The approach examines public signals associated with the agreed scope. Discovery should be designed to minimize impact and respect the participant's authorization, collection policies, and rate limits. An observation is retained with its source and timestamp. It remains an observation even if it looks familiar.
Correlate relationships and changes. The model links related identifiers where the supporting evidence justifies it: domain to subdomain, hostname to address, endpoint to certificate, or a sequence of observations over time. Correlation should express confidence and provenance. It should not collapse all links into a single unqualified "owned" state.
Surface review-ready context. A reviewer needs the record behind a decision: what was observed, when, why it was connected to a seed, what changed, and which team can validate it. The intended output is a navigable context for validation and remediation routing, not a replacement for an organization's CMDB, cloud inventory, or ticketing process.
Where the approach can help
The first use case is perimeter reconciliation. A security or infrastructure team can compare externally observed identifiers with its existing records and investigate meaningful differences. The result may be a confirmed new asset, a third-party service that needs documentation, a stale DNS record, or an incorrect correlation. Each outcome improves the record, even when no vulnerability is found.
The second is change review. A new hostname, changed certificate, or altered resolution path can be assessed in the context of its prior state and known relationships. The review question is specific: is this change expected, and does it require a responsible team to act? This is more useful than treating every change as an incident.
The third is preparation for exposure workflows. In private preview, Poxek connects EASM context to vulnerability-management and SOC workflows without claiming automated response. The contribution is a consistent external asset context that participating teams can use when they validate findings or investigate alerts.
Limits that should remain visible
Public data leaves blind spots. It does not reveal private services, authenticated application behavior, every ephemeral deployment, internal configuration, or a definitive business owner. It may be stale, incomplete, misleading, or reflect third-party infrastructure. A private preview should state those limits plainly in the operating model and in the UI language.
Nor should a preview imply a service-level commitment, certification, detection guarantee, or universal coverage. Poxek has not made those claims here. Production commitments require their own approved scope, architecture, security review, operating procedures, and contractual terms.
The useful test is whether a participant can trace a record from a known seed to the public evidence, relationship logic, change history, and reviewer decision. If that chain cannot be inspected, the product has produced a result but not reliable operating context.