Internet-exposed assets: inventory is not visibility

A CMDB can say a firewall exists, a controller belongs to Plant 2 and a remote-access appliance is due for renewal. It cannot prove what an unauthenticated observer can reach from the internet today. That difference matters because public exposure changes without waiting for the next inventory review: a contractor installs a cellular modem, a cloud migration leaves an old endpoint alive, a temporary management interface becomes permanent, or a DNS record points to an abandoned service.

Internet-exposed asset monitoring tests the organisation's internal account from the outside. It does not replace the inventory. It finds observations that must be reconciled with an owner, business function, data flow, authentication method, support status, vulnerability state and a decision to keep, restrict or remove the exposure. A scanner can discover an IP address and a service. It cannot decide whether production still depends on them.

The alert is about UK and OT risk; the lesson travels further

On 27 August 2026, the UK's National Cyber Security Centre (NCSC) said it had seen increased targeting of operational technology across multiple sectors globally, including the UK, with some limited real-world disruption. It warned organisations not to assume that OT is inaccessible from the internet without verifying it, because misconfiguration, legacy connections and unmanaged assets can create unintended exposure.

The alert recommends a definitive view of OT assets, communications paths and external connections; removal of direct public access to PLCs and HMIs; stronger credentials and access controls; supported boundary devices; secure protocols; monitoring; network separation; and tested recovery. It also says the broader pattern reaches internet-exposed systems and edge devices outside OT, and advises non-OT organisations to understand the function and data flows of edge devices, apply updates, retire end-of-life equipment and watch for unexpected changes or outbound connections.

Those are facts from a UK government alert, with a particular OT and national-resilience context. The rest of this article is Enclave Guard's broader operational analysis. The alert does not say that every exposed service is compromised, and it provides no basis for claiming that Enclave Guard customers are being targeted.

A CMDB records an internal claim

An inventory is necessary. CISA's joint 2025 OT guidance defines an asset inventory as an organised, regularly updated list of systems, hardware and software. For OT, it recommends a taxonomy that classifies assets by function and criticality, and a process covering scope, identification, attributes, data management and the asset lifecycle. The guidance was written for OT owners and operators and includes input from US and international agencies. Its examples should not be treated as a universal regulatory mandate.

A useful CMDB or OT inventory answers internal questions:

• What did we buy or deploy?
• Where should it be, and which service or process depends on it?
• Who owns it, who supports it and when does support end?
• Which network relationships and change records should exist?

That is the organisation's declared state. It is often assembled from procurement, configuration management, cloud accounts, network management, engineering records and conversations with suppliers. Each source has blind spots. An acquired company may never have been imported. A managed service provider may hold the account. An integrator may know about a modem that central IT does not. The CMDB may list the current VPN concentrator while the previous one still answers on a public address.

None of this makes the inventory pointless. It makes provenance and validation part of inventory quality.

External observation tests the claim

Cyber exposure monitoring starts with a different question: what can someone outside the organisation observe or reach? Depending on scope and lawful authorisation, discovery may use organisational IP ranges, domains and subdomains, DNS, certificates, cloud endpoints, internet-wide indexes, safe service identification and other externally available evidence.

CISA's Internet Exposure Reduction Guidance, revised on 21 August 2026, tells organisations to identify internet-accessible assets, account for remote access held by integrators, MSSPs and vendors, verify third-party connections, remove unnecessary access, protect what remains and reassess routinely. It specifically notes that an open port does not by itself prove a vulnerability or compromise. That caveat should shape the whole programme.

External discovery can expose a disagreement:

• the inventory says "retired", but the address still responds;
• the owner says "internal only", but the administration interface is public;
• procurement says "supported", but the observed version or device family appears end of life;
• the service is approved, but its certificate, hostname or response discloses a forgotten environment;
• a supplier says access is brokered through a gateway, but a device also has a direct cellular path.

These are leads, not verdicts. Shared hosting, carrier NAT, stale DNS, honeypots, reused addresses and imperfect service fingerprints can all produce false attribution. The team must validate before escalating a finding or contacting a provider.

Discovery, validation, ownership and remediation are separate jobs

Calling the whole workflow "visibility" hides where it fails. Four stages need different evidence and different people.

1. Discovery

Discovery builds a candidate set. The goal is coverage, not certainty. Record the observation time, source, IP or hostname, protocol, port, certificate and any non-intrusive service evidence. Include known corporate ranges, cloud tenants and domains, but leave room for supplier-hosted, acquired and legacy infrastructure that does not match the expected namespace.

External attack surface management products can automate much of this collection. They are useful, but they inherit data latency, attribution errors and fingerprint limits. A result that says "possible industrial protocol" is a prompt to investigate, not permission to interact with a production controller.

2. Validation

Validation asks whether the asset is really associated with the organisation, whether it is still reachable and what the observation actually proves. Compare independent signals. Check DNS and certificate history, cloud or firewall records, supplier documentation and the internal inventory. Use a safe verification procedure agreed with operations. In OT, availability and safety constraints take priority over curiosity.

CISA's primary OT mitigations say critical-infrastructure entities should identify public-facing assets and remove unintentional exposure. They also recommend securing essential remote access, segmenting IT and OT and maintaining the ability to operate manually. The document is US critical-infrastructure guidance from May 2025, not a licence to scan third-party or operational systems without authority.

3. Ownership

A validated exposure with no owner becomes a recurring ticket. Ownership should name both the technical custodian and the business decision-maker. A hosting provider may administer an appliance, but the customer still needs someone who can explain why the connection exists and accept the risk of keeping it.

CISA's joint inventory guidance recommends governance, assigned roles, asset owners, regular review and lifecycle updates, including additions and removals made under emergency change authority. The NCSC's definitive-view guidance similarly covers asset categorisation, connectivity and third-party risk. Both point toward a living operating record rather than a one-off spreadsheet.

4. Remediation

Remediation is a decision, not a scan result. The preferred outcome is usually to remove public access that has no documented operational need. Necessary exposure may need a centrally managed gateway, access restrictions, unique identities, phishing-resistant MFA where supported, patching, replacement of unsupported equipment, ingress and egress monitoring, and segmentation.

Some fixes need an outage, vendor involvement or a redesign. For a legacy production system, abruptly closing a route can be unsafe. Record an interim control, a responsible owner and a dated removal or migration plan. "Accepted" without an expiry date is often another word for forgotten.

The reconciliation record that teams can operate

For every confirmed external service, maintain one record that connects the observation to operational context:

This record should not become a second CMDB. Feed confirmed facts back into the authoritative inventory and change process. Keep the external evidence and observation history in the exposure workflow. The useful output is the resolved disagreement between them.

Prioritise by consequence, not by what scans cleanly

A public admin page with weak authentication deserves attention, but context determines order. A manufacturer should bring production impact, safety, remote engineering access and recovery capability into triage. An MSP should account for management-plane reach, customer concentration and who can authorise a change. Infrastructure and security managers should consider data sensitivity, privilege, exploitability, business dependency, support status and whether the exposure is expected.

This is where a raw severity score falls short. An unsupported edge device controlling many downstream connections may deserve action even without a confirmed CVE. A fully patched service can still be unnecessary. Conversely, a vulnerable version string may be a false fingerprint or sit behind a compensating control. Validate both the technical condition and the business path.

Enclave Guard's CTI and CEM service can support recurring external discovery and analyst review. Infrastructure penetration testing is a separate, authorised exercise for validating weaknesses within a defined scope; it should not be confused with continuous discovery. Once an exposure and affected product are confirmed, vulnerability management helps prioritise and track the fix. These services cover different stages because no single tool can discover, interpret, own and remediate an exposure by itself.

A workable first cycle

Start with a bounded scope: corporate domains, known public ranges, cloud accounts and the edge or OT connections that matter most. Take a baseline from outside. Reconcile each credible finding with the internal inventory and name an owner. Close or restrict obvious unnecessary access after change approval. Put supported, necessary services into a patching and monitoring path. Give unsupported or hard-to-change assets a dated migration decision.

Then repeat the observation. The second pass is where monitoring starts to earn its name. It should show whether a removal worked, whether a new exposure appeared and whether ownership data stayed current. Track time to validate, percentage with an accountable owner, age of unresolved exposure and the ratio of keep/remove decisions completed. Counting discovered hosts alone rewards noise.

Inventory and external monitoring answer different questions. The inventory says what the organisation believes it operates. External monitoring tests which parts of that belief are visible to everyone else. Security improves when the team resolves the difference and changes the system, not when it buys a more attractive map.

This article provides general cybersecurity information, not legal, safety or engineering advice. The NCSC material concerns a UK alert and the CISA material reflects US and joint OT guidance; duties vary by jurisdiction, sector, contract and system safety case. Perform discovery and testing only with explicit authority and an agreed scope. Source status and external exposure can change after 2 September 2026, so re-check current advisories, vendor support and observed services before acting.