See your organisation exactly the way an attacker does.
Continuous, outside-in discovery of every domain, IP, certificate, cloud bucket, API and exposed credential connected to your brand — including the assets no one told you about.
You cannot defend what nobody wrote down.
Every inside-out security tool answers the question 'is this asset safe?' None of them answer the question that actually decides whether you get breached: 'what do we have out there?'
of the perimeter is undocumented
Marketing microsites, an acquired company's mail server, a proof-of-concept someone deployed in 2022 on a personal cloud account. None are in the CMDB, all resolve to your brand.
from exposure to scanning
Opportunistic scanners sweep the entire IPv4 space continuously. A misconfigured bucket or an exposed admin panel is typically found by someone within hours of going live.
inherits an unknown perimeter
Acquisitions arrive with infrastructure, domains and certificates that were never in your scope. Diligence covers financials far more thoroughly than it covers DNS.
in a public repository is enough
A single cloud credential committed to a public repo, or an employee password in a breach corpus, bypasses every perimeter control you have invested in.
The only security control you can switch on before procurement finishes.
Every other tool in your stack needs credentials, an agent or a network change before it produces a single insight. Zenxecure ASM needs a brand name and a domain, because it looks at you from where the attacker stands.
- Certificate TransparencySubdomains you never published
- Passive & active DNSDangling records open to takeover
- WHOIS / RDAPDomains registered by other teams
- BGP & ASN registriesNetblocks routed to you
- Cloud IP fingerprintingShadow cloud accounts
- Public code & pastesLeaked keys and internal hostnames
- Breach corporaEmployee credentials in circulation
- Registry namespacesTyposquat and confusion packages
Representative of a first pass against a mid-size Indian enterprise.
Know the real perimeter, continuously
This is the one security control that requires nothing from your environment to start working. Give us a brand name, and the value arrives before any procurement conversation about access has even started.
Close the inventory gap
Discovery is seeded from your brand rather than your records, so it finds what your records missed. Most organisations see their known asset count rise materially in the first week.
Cut exposure dwell time
Continuous monitoring means a newly exposed service is detected in the same window an opportunistic scanner would find it — not at the next quarterly assessment.
De-risk acquisitions before you sign
Run outside-in discovery against a target company during diligence. No access, no NDA-bound credentials, no cooperation required — just the public reality of their security posture.
Protect the brand, not just the network
Typosquat and lookalike-domain detection surfaces phishing infrastructure while it is being staged, so takedowns start before the campaign reaches your customers.
Find the leaks nobody reported
Public code, paste sites and breach corpora are monitored for credentials and keys tied to your domains, catching the exposures that never generate an internal alert.
Evidence for regulators and insurers
A documented, continuously maintained external asset inventory is increasingly requested by cyber insurers and expected by CERT-In, RBI and SEBI supervisory reviews.
What Zenxecure ASM does
The complete external attack surface management surface — built as one product, not assembled from acquisitions.
Attributed asset discovery
Seeded from your brand, domains and ASNs, then expanded through DNS, certificate transparency, WHOIS and cloud fingerprints.
Shadow IT and subsidiary mapping
Surfaces forgotten marketing sites, dev environments, acquired-company estate and third-party hosted properties.
Exposure and misconfiguration checks
Open ports, expiring or weak TLS, exposed admin panels, default credentials, public buckets and leaking API endpoints.
Leaked credential and data monitoring
Monitors public code, paste sites and breach corpora for keys, tokens and employee credentials tied to your domains.
Brand and typosquat surveillance
Detects lookalike domains and phishing infrastructure registered against your brand before campaigns launch.
Third-party exposure view
Extends the same outside-in lens to critical vendors so supply-chain risk is measured, not assumed.
Six situations this actually changes
Not feature descriptions — the specific moments where the difference between having this product and not having it shows up in someone's week.
The first scan finds what the CMDB never had
Your asset register lists 400 internet-facing systems. You suspect the real number is higher but have no way to prove it without asking every team to self-report.
Day-one discovery returns 574 attributed assets. 174 were unknown: three staging environments with default credentials, a decommissioned campaign site still serving, and a subsidiary's mail gateway running an unpatched stack.
How it works
Each discovered asset carries an attribution confidence score and the evidence chain that produced it — which certificate, which DNS record, which WHOIS registrant — so you can verify a claim rather than take it on trust.
Security diligence before the term sheet
Technical diligence depends entirely on what the target chooses to disclose, and happens too late in the process to change the price.
An outside-in assessment of the target runs in 48 hours with no access and no cooperation, producing an evidenced view of their exposed estate, credential leaks and TLS hygiene.
How it works
Because discovery uses only public data sources, nothing in the process is intrusive or requires authorisation from the target. The output is a report you can attach to the diligence pack.
A phishing campaign caught during staging
You find out about a lookalike domain when a customer forwards the phishing email, by which point the campaign has already run.
A newly registered typosquat is detected the day it appears. When an MX record and a TLS certificate are added — the staging signature of a live campaign — it escalates, and the abuse submission is pre-drafted.
How it works
Detection combines registration monitoring, homoglyph and keyboard-distance permutation, and content similarity once the domain begins serving. Escalation is driven by behaviour, not by registration alone, which keeps the alert volume manageable.
A storage bucket opened by a config change
A Terraform change makes a bucket publicly readable. Your cloud posture tool flags it eventually, if that account is in scope and the integration is healthy.
The bucket is detected from the outside within the monitoring cycle, exactly as an opportunistic scanner would find it, with a sample of the exposed object listing as evidence.
How it works
Outside-in detection covers accounts you did not know existed and therefore never connected to a posture tool — the shadow cloud problem that inside-out tooling is structurally unable to see.
Supply-chain posture without a questionnaire
You assess 60 critical vendors with an annual questionnaire. Responses are self-reported, a year out of date, and impossible to verify.
The same outside-in lens runs continuously against each vendor's public estate, producing an observed posture score you can put next to their self-assessment.
How it works
Only public, non-intrusive observation is used, so no vendor authorisation is required. Material posture changes at a critical vendor raise an alert between assessment cycles.
An attack path nobody had joined up
Three findings sit in three places: an exposed Jenkins instance, a leaked service-account token in a public gist, and an over-permissive IAM role. Each is medium severity on its own.
Attack-path narration chains them into one critical finding: the token authenticates to the Jenkins instance, which assumes the role, which reaches production data.
How it works
Paths are ranked by feasibility and each hop cites the evidence supporting it, so the finding can be validated or dismissed on its merits rather than accepted because a tool said 'critical'.
Where the AI actually earns its place in Zenxecure ASM
Four concrete jobs the model does on your data — each logged, each explainable, none of it guesswork.
Ownership attribution
Confidence-scored reasoning about whether a discovered asset genuinely belongs to you, cutting false attribution.
Attack-path narration
Chains individual exposures into the plausible route an attacker would take, ranked by feasibility.
Change intelligence
Learns your normal deployment rhythm and alerts only on genuinely anomalous new exposure.
Takedown drafting
Prepares registrar and host abuse submissions for confirmed typosquats and phishing infrastructure.
What this satisfies, clause by clause
External asset inventory has moved from good practice to an explicit expectation — in ISO 27001's asset management controls, in CERT-In's directions, and increasingly in what cyber insurers ask at renewal.
| Framework | Requirement | How Zenxecure ASM addresses it |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.9 Inventory of information assets · A.8.8 Technical vulnerabilities | Continuously maintained inventory of externally exposed assets with evidenced attribution, plus identification and treatment of exposures. |
| CERT-In Directions, 2022 | Asset visibility and 6-hour incident reporting | Confirmed external exposures raise an incident candidate with the evidence bundle and timeline pre-assembled for reporting. |
| RBI Cyber Security Framework | Annex I — Inventory Management; Anti-Phishing | Externally observed asset register maintained continuously, plus lookalike-domain detection and takedown workflow. |
| SEBI CSCRF | Identification of critical assets and periodic assessment | Ongoing outside-in assessment of the regulated entity's internet-facing estate with change history retained. |
| NIST CSF 2.0 | ID.AM-01 through ID.AM-04 · ID.RA-01 | Hardware, software, service and external-provider inventories maintained from observation rather than self-report. |
| PCI DSS 4.0 | 11.3.2 External vulnerability scanning · 12.5.1 Scope confirmation | External scope discovery that surfaces in-scope systems missing from the documented CDE boundary. |
| Cyber insurance underwriting | External posture attestation | Point-in-time and trend reports of external exposure, increasingly requested at renewal and to support claims. |
This mapping is provided to help scope an assessment. It is not legal advice and does not certify compliance — your auditor, assessor or counsel makes that determination.
Everything below this line is for the person who has to make it work.
Which public sources discovery draws on, exactly how attribution confidence is scored, what our scanners will and will not do to your infrastructure, and the egress ranges you may want to allow-list.
How the data actually flows
Five stages from a single seed domain to a monitored, attributed estate. Steps one to three require nothing from you; step four is deliberately conservative about what it touches.
Seed
You provide a brand name and one or more root domains. That is the entire input — no credentials, no network access, no agents.
- Root domains, known brand names and trading names
- Optional: known ASNs, IP ranges, subsidiary names and acquisition history
- Optional: read-only cloud roles, which improve attribution but are never required
- Explicit exclusion list for assets you do not want monitored
Expand
Discovery walks outward from the seed across independent public data sources, each of which surfaces assets the others miss.
- Certificate Transparency logs — every TLS certificate ever issued for your names
- Passive DNS and active resolution, including wildcard and takeover-candidate detection
- WHOIS and RDAP registrant correlation across domains and IP allocations
- BGP and ASN data for netblocks announced by or routed to you
- Cloud provider IP range fingerprinting and bucket namespace enumeration
- Public code hosts, package registries and paste sites for references to your infrastructure
- Breach corpora and credential dumps matched against your email domains
Attribute
Every candidate asset is scored for whether it genuinely belongs to you. This is the step that separates a useful ASM product from a noisy one.
- Multi-signal attribution: registrant, certificate subject, hosting, content and linkage
- Confidence score from 0 to 100 with the full evidence chain attached
- Above 85: auto-attributed. 50–85: queued for one-click human confirmation. Below 50: discarded
- Confirmations train your tenant's attribution profile without affecting other tenants
Assess
Confirmed assets are checked for exposure using safe, non-intrusive techniques. We never exploit, never brute-force and never degrade a service.
- Service and version fingerprinting on responsive ports
- TLS configuration, certificate validity, expiry and weak cipher detection
- Exposed management interfaces, default landing pages and directory listings
- Public object storage enumeration and readable-listing detection
- Security header and cookie configuration on web properties
- Rate-limited, politely scheduled, and honours your exclusion list absolutely
Correlate and act
Individual exposures are chained into attack paths, pushed to your workflow tools and tracked until the exposure is gone.
- Attack-path construction across assets, credentials and trust relationships
- Change intelligence that learns your normal deployment rhythm to suppress routine churn
- Ticket creation with owner inference, and takedown drafting for confirmed typosquats
- Regression monitoring: a closed exposure that reappears reopens with its history
How attribution confidence is calculated
The hardest problem in external ASM is not finding assets — it is deciding which of them are actually yours. A tool that over-attributes wastes your time; one that under-attributes misses the asset that gets you breached. Each signal below contributes to a 0–100 confidence score.
WHOIS / RDAP registrant match
Registrant organisation, email domain or registrant ID matching a confirmed entity of yours is the single strongest signal.
Certificate subject linkage
A TLS certificate covering both a confirmed asset and the candidate is strong evidence of shared control.
DNS and infrastructure adjacency
Shared nameservers, MX records, CNAME chains into your estate, or residence in a netblock you announce.
Content and brand signal
Your logo, favicon hash, analytics identifiers, copyright line or privacy-policy link appearing on the asset.
Cloud account provenance
Where an optional read-only cloud role is connected, resources are confirmed directly against your accounts.
Shared-hosting ambiguity
An asset on shared hosting or a CDN edge shared with thousands of unrelated tenants loses most of its adjacency weight.
Contradictory registrant
A registrant that clearly belongs to another organisation overrides weaker positive signals and pushes the candidate below threshold.
Thresholds are per-tenant and adjustable. Every confirmation or rejection you make refines attribution for your tenant only — your estate is never used to train attribution for anyone else.
Every connector, and exactly what it reads
The first two groups need no configuration at all — they are public data sources we already monitor. The third group is optional and exists only to sharpen attribution. The fourth is where findings go once they are confirmed.
Discovery sources (no configuration required)
| System | Method | What we read |
|---|---|---|
| Certificate Transparency | Continuous log ingestion | Every certificate issued for names matching your seeds |
| Passive & active DNS | Resolver + passive feeds | Subdomains, record types, dangling CNAME takeover candidates |
| WHOIS / RDAP | Registry query | Registrant identity, registration and expiry dates, nameservers |
| BGP / ASN registries | Routing table analysis | Netblocks announced by or routed to your organisation |
Leak monitoring
| System | Method | What we read |
|---|---|---|
| Public code hosts | Search API + pattern matching | Committed keys, tokens and internal hostnames |
| Paste and dump sites | Continuous monitoring | Credentials and configuration referencing your domains |
| Breach corpora | Hashed domain matching | Employee credentials appearing in third-party breaches |
| Package registries | Namespace monitoring | Dependency-confusion and typosquat package candidates |
Optional enrichment (improves attribution)
| System | Method | What we read |
|---|---|---|
| AWS | Cross-account IAM role, read-only | Route 53 zones, ELB and CloudFront endpoints, public IPs |
| Microsoft Azure | Entra ID app, Reader role | Public IPs, Front Door and App Service hostnames, DNS zones |
| Google Cloud | Service account, viewer | Cloud DNS, external load balancers, public bucket inventory |
| Registrar APIs | Read-only token | Authoritative domain portfolio and renewal status |
Workflow and response
| System | Method | What we read |
|---|---|---|
| Jira / ServiceNow | OAuth 2.0, two-way | Exposure tickets with owner routing and status sync |
| Slack / Microsoft Teams | App install | New-exposure and critical-path alerting |
| SIEM (Splunk, Sentinel, Elastic) | Webhook or syslog | Exposure events forwarded for correlation |
| Registrar & host abuse desks | Generated submission | Pre-drafted takedown requests for confirmed typosquats |
Not listed? A documented REST API and signed webhooks cover the rest, and we build priority connectors with design partners. Tell us what you run.
The answers your architecture review will ask for
Written down here so you do not have to raise a ticket to get them. Anything not covered, ask us and we will put it in writing.
Deployment
- Models
- Multi-tenant SaaS · single-tenant dedicated
- Primary region
- India (ap-south-1 / Central India) by default
- Time to first results
- Initial discovery pass typically completes within 24 hours
- Prerequisites
- A brand name and one root domain. Nothing else is required.
Scanning behaviour
- Technique
- Non-intrusive only — no exploitation, no brute force, no fuzzing
- Rate limiting
- Per-host politeness limits; configurable scan windows
- Source addresses
- Published static egress ranges for allow-listing and attribution
- Exclusions
- Honoured absolutely; excluded assets are never probed
- Re-assessment cadence
- Discovery continuous; exposure checks every 6–24h by asset criticality
Data and retention
- Asset history
- Full change timeline retained for 24 months
- Evidence artefacts
- Response headers, certificates and screenshots retained 90 days
- Credential findings
- Only match metadata stored — never the plaintext secret
- Encryption
- TLS 1.3 in transit; AES-256 at rest with per-tenant keys
Interfaces
- API
- REST, JSON, OpenAPI 3.1 specification published
- Rate limit
- 600 requests/minute per tenant
- Webhooks
- Signed events on asset discovered, exposure opened, path detected, takedown filed
- Export
- CSV, JSON Lines and scheduled PDF reporting for boards and insurers
Pull your perimeter into your own tooling
Newly discovered assets and open exposures are available over REST and as signed webhooks, which makes it straightforward to reconcile external discovery against your CMDB on a schedule.
OpenAPI 3.1 specification published
Signed webhooks with delivery receipts
Scoped API keys and OAuth 2.0 client credentials
A common pattern is a nightly job that diffs this endpoint against the CMDB and opens a ticket for any attributed asset with no corresponding record.
curl -s https://api.zenxecure.com/v1/assets \ -H "Authorization: Bearer $ZX_API_KEY" \ -G \ --data-urlencode "filter[first_seen_after]=2026-09-01" \ --data-urlencode "filter[attribution_confidence_min]=85" \ --data-urlencode "filter[has_open_exposure]=true" \ --data-urlencode "sort=-max_severity" # {# "data": [# {# "id": "ast_01JQ9F4X2C",# "hostname": "staging-portal.acme-subsidiary.in",# "ip": "13.234.x.x",# "first_seen": "2026-09-11T04:22:11Z",# "attribution": {# "confidence": 92,# "evidence": ["ct_log_san_match", "shared_nameserver", "favicon_hash"]# },# "exposures": [# { "type": "exposed_admin_interface", "severity": "critical", "port": 8080 },# { "type": "tls_expired", "severity": "medium", "expired_at": "2026-08-02" }# ],# "attack_paths": 1# }# ],# "meta": { "total": 3 }# }What the first month actually looks like
Including the parts that need your people, and roughly how much of their time it takes. We would rather set the expectation now than discover it in week three.
Seed
Give us your brand name and root domains through the onboarding form. There is nothing to install, no credential to issue and no change request to raise.
First discovery pass
Expansion runs across every public source. You receive an initial attributed inventory with confidence scores and the evidence behind each attribution.
Confirm attribution
Work through the medium-confidence queue with one-click confirm or reject. This is the only manual step, and it sharpens attribution permanently.
Triage the first exposures
Exposure assessment completes across the confirmed estate. Critical items — exposed interfaces, leaked credentials, takeover-candidate DNS — are actioned first.
Continuous monitoring
New assets and exposures are detected as they appear, filtered through change intelligence so you are alerted to the genuinely anomalous rather than routine deployment churn.
The things buyers actually ask
Including the awkward ones. If your question is not here, ask it — we will answer it directly rather than route you to a brochure.
Is any of this intrusive? Do we need authorisation to run it?
No. Discovery uses only publicly available data — certificate transparency logs, DNS, WHOIS, routing registries. Exposure assessment is limited to the kind of interaction any ordinary web client performs: connecting to a responsive port, reading a banner, checking a TLS configuration. We never exploit a vulnerability, never brute-force a credential and never fuzz an endpoint. Because of that, running ASM against your own estate, or against an acquisition target during diligence, does not require special authorisation.
How do you avoid attributing assets that are not ours?
Attribution is scored, not assumed. Each candidate is evaluated across registrant data, certificate linkage, DNS adjacency, content signals and — where you connect optional cloud roles — direct account confirmation. Above 85 confidence an asset is auto-attributed; between 50 and 85 it goes to a confirmation queue for a human; below 50 it is discarded. Every attribution carries its evidence chain, so you can always see why a claim was made.
Will this overlap with our cloud security posture tool?
It overlaps deliberately and usefully. A CSPM tool sees the accounts you connected it to, from the inside. ASM sees everything that resolves to your brand, from the outside — including accounts nobody told the CSPM about. Where they agree you get confirmation; where ASM finds something CSPM cannot see, you have found shadow cloud.
What happens with leaked credentials you find?
We store only the match metadata — where it was found, which domain it relates to, when it appeared and a partial fingerprint sufficient to identify it. We never store the plaintext secret, and we do not attempt to authenticate with it to validate the finding. The alert gives your team what they need to rotate the credential and investigate.
How noisy is it? We already have alert fatigue.
Change intelligence learns your normal deployment rhythm, so a team that spins up ten preview environments a day does not generate ten alerts a day. Alerting is driven by genuinely anomalous exposure and by behaviour — a typosquat domain is logged on registration but only escalates when it adds an MX record and a certificate, which is the staging signature of a live campaign.
Can we run this against our vendors?
Yes. Because the method is entirely non-intrusive and uses public data, third-party monitoring works the same way as monitoring your own estate. Customers commonly track their most critical vendors continuously and use the observed posture alongside — or instead of — an annual questionnaire.
How does ASM relate to Zenxecure VM?
They solve the two halves of the same problem and share one asset graph. ASM answers 'what do we expose?' from the outside with no access required. VM answers 'what is wrong with what we run?' from the inside using your scanners. Run together, an externally discovered asset that no scanner covers shows up explicitly as a coverage gap rather than being silently assumed clean.
Do you support IPv6 and non-web services?
Yes. Discovery covers IPv6 where it is announced or resolvable, and assessment is not limited to HTTP — mail, DNS, VPN, database and management protocols are fingerprinted on responsive ports. Web properties simply attract the most checks because they carry the most exposure types.
The rest of the platform
Every Zenxecure product writes to the same asset graph, so adding the next one compounds what you already have.
Zenxecure VM
AI Vulnerability Management
Zenxecure VM unifies every scanner, cloud account and asset inventory you already own, then uses AI to decide what actually threatens your business — and drives the fix to closure.
Explore Zenxecure VMZenxecure Consent
Consent & Privacy Management
A Consent Management Platform engineered for India's Digital Personal Data Protection Act, 2023 — and flexible enough for GDPR, CPRA and every market you expand into.
Explore Zenxecure ConsentGive us a domain. We will show you what we find.
A no-obligation outside-in scan of your public perimeter, walked through with an engineer. Nothing to install, no credentials to issue, and you keep the report either way.
No agents to install · Read-only connectors · Data residency in India