Most organisations already have something they call an internet-facing asset inventory. It is usually a CMDB populated from procurement records, plus a spreadsheet of public IP ranges maintained by whoever last renewed the firewall. Both are honest efforts. Neither survives contact with an auditor who asks a simple question: for this hostname, who owns it, when did you last confirm that, and what did you decide to do about it?
That question is about record design, not scanning. You cannot answer it by buying a better scanner. You answer it by deciding what a single inventory record must contain before it is allowed to count as an asset at all. This piece sets out seven fields, why each one exists, and which specific failure each one prevents.
Why most internet-facing asset inventories fail an audit
An IP-range inventory made sense when your exposure sat behind your own firewall on addresses you had been allocated. It misses most modern exposure. A SaaS platform hosting your careers portal on a subdomain of your domain does not appear in your ranges. Neither does a CDN-fronted application, a marketing automation platform with a CNAME pointing at it, a static site on shared hosting, or a cloud load balancer in an account opened with a corporate card in 2021. Scanning your ranges tells you about the part of your estate you already knew about.
There is also a difference between a list and an inventory, and it is not pedantry. A list of hostnames records existence. An inventory records existence, ownership, provenance, time and a decision. Strip the decisions out and you have a document that proves you can run a scan, which is not what anyone is asking you to prove.
What an auditor or a cyber insurer is actually testing is whether you have a repeatable process that produces a defensible answer. “We scan our published ranges quarterly”is weak on both counts: the scope is self-selected, and the cadence is a calendar convenience rather than a response to your rate of change. ISO/IEC 27001:2022 Annex A control 5.9 expects an inventory of information and associated assets with ownership assigned, and expects externally accessible systems to be distinguishable within it. That is an argument for an exposure field on every record, not for one undifferentiated asset table.
Where the candidates come from: external discovery as your feed
Start from seed domains and expand outwards, the way an attacker does: from the outside. Three sources do most of the work, and each is good at something different.
Certificate transparency logs are the most productive source for exactly the assets no internal register holds. Every publicly trusted TLS certificate is logged to public append-only logs under the Certificate Transparency framework, whether or not anyone told IT the host existed. Search a single seed domain and you will typically get hostnames the register has never seen: patterns like vpn-test, uat, legacy-mail, and project names inherited from an acquisition. The weakness is coverage in the other direction: a host without a public certificate, or one behind a wildcard, will not show up.
DNS gives you the resolution picture: A and AAAA records, CNAME chains, MX and TXT records including SPF and DMARC policies, and NS delegations that sometimes point at a provider nobody remembers choosing. WHOIS and registration data help with the boundary question of which domains are even yours, which matters more after a merger than most people expect. Registration data has become patchier since GDPR-driven redaction, so treat it as corroboration rather than a source of truth.
Now the part that competing guides skip. Discovery produces candidates, not confirmed assets. A hostname that resolves into your cloud tenancy may belong to a supplier operating on your behalf, to a brand you sold three years ago, or to a project that was cancelled before launch. Recording it as yours without confirmation does not fix an incomplete register; it makes the register wrong in a new direction, which is worse, because it gives false confidence.
The same caution applies to technology. Passive observation reads banners, headers, certificate fields and response behaviour, and from those it infers that a host is likely running a given version of a given service. It has not tested the flaw. That distinction has to survive into the record, because a team that cannot tell inference from confirmation will either raise change requests off guesswork or dismiss real findings as noise. Our note on likely versus definitely works through where the line sits.
The 7 fields every asset record needs
1. Canonical identity, plus every alias that reaches it
Pick one canonical entry per asset, usually the hostname, and attach every alias that resolves to it. This matters because takeover risk lives in the alias, not the origin. A record that only says “web01 in eu-west-2, patched, monitored”tells you nothing about the six marketing subdomains pointing at it, one of which points at something that no longer exists.
2. Resolution path and the provider at the end of it
Store the full chain: the CNAME hops, the final A record, and the hosting provider or service that answers. A dangling record is a pointer to nothing, and you can only see it if you recorded where the pointer goes. The classic case: a marketing agency creates campaign.brand.co.uk as a CNAME to a cloud storage bucket, the campaign ends, the bucket is deleted, the DNS record survives. The name becomes claimable by whoever registers that bucket name next, and no internal register ever held it because the agency raised the change at the registrar directly. The mechanics are set out in more detail in our piece on the dangling DNS problem.
3. A named owner, with a date
“IT”is not an owner. “Marketing”is not an owner. A person or a named team with an on-call alias is an owner, and the field needs a companion date recording when that ownership was last confirmed by the owner rather than assumed by you. Ownership rots quietly. People change roles and nothing in DNS notices.
4. Hosting and contractual context
Record whose tenancy the asset sits in, which contract covers it, and separately, who can actually change the DNS record. Those are frequently three different parties. An asset you are responsible for, hosted by a supplier, with DNS controlled by an agency, is a common and genuinely awkward arrangement, and the record should say so plainly so that nobody wastes a week discovering it during an incident.
5. First seen and last seen
Two timestamps turn a static list into change detection. First seen tells you whether a host appeared last Tuesday, which is the single most useful signal you have for catching things deployed outside the change process. Last seen tells you whether something has quietly gone away, which is how decommissioning gets evidenced rather than assumed.
6. Confidence and evidence
Three things belong here: how the asset was found (certificate log, DNS enumeration, supplier declaration), whether a human has confirmed it is yours, and whether the service fingerprint is inferred or verified. Keep the evidence itself where you can, such as the certificate serial or the observed banner. This field is what allows you to hold an uncertain entry in the register honestly, rather than choosing between overstating it and deleting it.
7. Disposition, with a review date
Every record carries a decision: in scope and monitored, decommission requested, transferred to supplier, unclaimed and parked, or accepted and documented. A review date sits alongside it. Without this field you have no register, only a scan result that argues with you weekly.
Turning candidates into confirmed records without drowning the team
Triage in one order: ownership first, technology second. Ownership is the expensive question and almost everything else waits on its answer. Patching, decommissioning, scope decisions, penetration test authorisation, none of them can proceed until somebody accepts the asset.
You will hit hosts nobody claims. Park them explicitly. An unclaimed disposition with a review date and a note of who was asked is a defensible position; silence is not. The important thing is that the record exists, because the alternative is the host reappearing as a brand-new finding every cycle.
Which brings up something the tooling market rarely admits: alert fatigue in external monitoring is usually a data-model problem, not a tuning problem. If a finding has nowhere to record “reviewed, unowned, decommission requested with the agency on 14 March”, it must reappear, because from the tool’s point of view nothing has changed. A disposition field suppresses the repeat honestly. Muting the alert hides it. The outcomes look identical for about four months, and then they differ sharply.
Escalate from inference to an authorised active check only when the decision genuinely depends on it, and get permission in writing before you touch anything hosted by a supplier. Observing what a supplier publishes is one thing; probing their infrastructure is another, and your contract probably has an opinion about it.
Keeping the inventory current: what changes and how fast
A developer deploys a new service. A DNS record is added for a launch. A certificate expires. A cloud resource is deleted while its DNS record survives. Against a surface that moves like that, a quarterly refresh is a snapshot of a river.
Four change signals are worth wiring into the register directly: a hostname appearing for the first time, a new open port on a known host, a changed certificate issuer, and a changed hosting provider at the end of a resolution chain. The last two are undervalued. A hosting provider change on a record you thought was static usually means somebody migrated something and told nobody.
Set cadence by rate of change rather than by the calendar. A cloud-heavy estate with weekly deployments needs daily or near-daily discovery; a static on-premise estate can sit on longer intervals without much risk. The reasoning is unpacked further in our piece on why point-in-time scanning falls short.
One practical trick for the unclaimed pile: an expiring TLS certificate is an ownership clue as much as a risk. The renewal notice goes somewhere, and somebody has been renewing it. Tracing that inbox, or watching who renews it next, frequently identifies the owner that DNS and procurement records could not.
Fitting the inventory alongside vulnerability scanning and internal tooling
The inventory is a feed, not a report. It supplies the target list for authenticated scanning, the scope statement for penetration testing, and the externally accessible portion of your Annex A 5.9 asset register. The NCSC’s guidance on asset management makes much the same point: knowing what you have is the precondition for every other control, not a parallel activity.
It also catches a category of exposure that scanners structurally miss, because these things never receive a CVE: an admin interface reachable from the internet, an open storage container, default credentials on a forgotten appliance, an expired or misissued certificate, a subdomain pointing at a deleted service. No vulnerability identifier will ever be issued for a door left unlocked.
Expect the external view and the internal register to disagree. Treat the disagreement as the most useful output you get, rather than as a data quality problem to be reconciled away. Every host present externally and absent internally is an unknown asset security risk with a name attached; every host present internally and absent externally is either properly decommissioned or a record you can finally close.
One recurring worry, dealt with plainly: external discovery reads what is already public, in certificate logs, DNS and ordinary HTTP responses. It does not exploit systems, and looking at your own published data does not make you a target. If you want the discovery mechanics rather than the record design, our explainer on how forgotten assets get found covers the sources, and the discovery and inventory coverage follows the topic more broadly.
The Short Version
- An inventory is a data structure, not a scan result. Seven fields: canonical identity with aliases, resolution path and end provider, named owner with a confirmation date, hosting and contractual context, first seen and last seen, confidence and evidence, and disposition with a review date.
- External discovery gives you candidates. A human confirms ownership before a candidate becomes a record.
- Record the full alias chain. Takeover happens on the dangling CNAME, not on the live origin.
- Certificate transparency logs surface the staging, UAT and acquisition-era hostnames your register has never held.
- Disposition fields, not mute buttons, are the honest cure for repeat alerts.
- Set your refresh cadence to your rate of change, and treat a mismatch between the external and internal views as a finding rather than an error.
Frequently Asked Questions
What counts as an internet-facing asset?
Anything reachable from the public internet that carries your name, your data or your brand. That includes hosts on your own IP ranges, cloud resources in your tenancies, SaaS platforms served on your subdomains, supplier-hosted applications, mail and DNS infrastructure, and API endpoints. Ownership of the underlying server is not the test; exposure and accountability are.
How do you build an internet-facing asset inventory from scratch?
Begin with your domain portfolio, expand it using certificate transparency logs and DNS enumeration, then merge in whatever your CMDB and IP-range spreadsheet already hold. Load the result as candidates, not assets. Work the ownership question record by record, and record a disposition and a review date against every entry, including the ones nobody claims.
How often should an internet-facing asset inventory be updated?
Match the interval to how fast your estate changes. Frequent cloud deployments and active marketing activity justify daily or near-daily discovery; a largely static on-premise estate can run on longer cycles. Quarterly is a calendar habit rather than a risk decision, and it will miss anything that appeared and was exploited between passes.
What is the difference between an asset inventory and a vulnerability scan?
The inventory answers what you have, who owns it and what you decided about it. A scan answers what is wrong with the things you pointed it at. A scan inherits the blind spots of its target list, so an incomplete inventory quietly caps the value of every scan you run afterwards.
Who should own an internet-facing asset that nobody claims?
Temporarily, the security function should own the record while the ownership question is investigated, with an explicit unclaimed disposition and a review date. If nobody accepts it after a reasonable effort, the default should be decommissioning rather than indefinite monitoring. An asset with no owner has nobody to patch it, and that is the condition attackers rely on.