Your Enterprise Applications Are on the Internet.
You just have not looked.

Every organisation we assess believes it knows what it publishes. Almost none of them do.

The gap is rarely negligence. It is entropy. A subdomain is created for a 2019 migration and never retired. A vendor stands up a staging environment on a certificate that names the client. An integration endpoint is opened for a project that finished two years ago, and the change request that would have closed it was never raised because nobody remembered it existed. Individually, each is a footnote. Collectively, they are the map an attacker works from.

The lesson of the Environment Management Hub

In June 2026, attackers took data from more than a hundred organisations by reaching a component of Oracle PeopleSoft called the Environment Management Hub. It is an administrative function. It exists to coordinate patching and environment configuration between PeopleSoft servers. It has no business being reachable from the public internet, and in a correctly configured deployment it is not.

It was reachable in roughly three hundred deployments, and the organisations concerned were, in the main, unaware. Not because they were careless — because nobody had ever asked the question from the outside. Internal architecture diagrams showed the hub sitting behind the perimeter. The internet disagreed.

Where enterprise applications leak onto the public internet

Across our assessment work, exposed enterprise application surface tends to arrive through a small number of repeating paths.

Management and administration interfaces

Environment hubs, integration gateways, admin consoles, health-check endpoints, API documentation portals. These are frequently bound to all interfaces by default and placed behind a load balancer that was configured to forward everything. The application is doing exactly what it was told. Nobody told it anything different.

Non-production environments carrying production data

UAT, staging and training instances are routinely stood up quickly, secured lightly, and populated with a copy of production because a realistic dataset makes testing meaningful. They are then excluded from the patching schedule, because they are “not production.” They contain the same records and answer the same requests.

Vendor and integration endpoints

Payroll bureaux, benefits administrators, single sign-on brokers, reporting connectors. Each needs a path in. Each path is documented in a project artefact rather than in the asset register, and each outlives the project. The 2026 record is unambiguous that this is where the compromises are coming from.

Certificate transparency as an unintentional publication channel

Every publicly trusted TLS certificate issued for any hostname is logged to public certificate transparency logs. This is a security feature, and it works. It also means that issuing a certificate for peoplesoft-uat.internal.example.com.au publishes that hostname to the world, permanently, whether or not the host is intended to be public. Certificate transparency is one of the richest passive sources available, and it is available to anyone.

Why the asset register is usually wrong

CPS 234 requires an APRA-regulated entity to maintain classified information assets. ISO/IEC 27001 Annex A requires an inventory of assets. The ASD Essential Eight and the ISM both assume you know what is internet-facing before you can minimise or patch it. Every framework starts from the register.

The register is almost always assembled from the inside — from CMDB exports, procurement records and system owner interviews. Each of those sources records intent. None records reality. The failure mode is consistent: assets that were decommissioned on paper but never actually turned off, assets created outside the change process, and assets belonging to a supplier that carry your name in the certificate but appear in nobody’s inventory.

What a passive assessment establishes

All of the following is determinable without sending a single unsolicited request to a target system, using publicly available data only:

• Hostname inventory from certificate transparency logs, passive DNS, and public source aggregation — including hosts that were never intended to be public
• Technology and version fingerprinting of what those hosts present, mapped against published vulnerability data
• Exploitability triage using the CISA Known Exploited Vulnerabilities catalogue for confirmed in-the-wild exploitation, the Exploit Prediction Scoring System for probability, and CISA’s SSVC decision points for a defensible act-or-defer position
• Credential exposure where corporate identities appear in published breach and infostealer corpora
• Email authentication posture — SPF, DKIM and DMARC enforcement, and whether your domain can be spoofed today
• Third-party surface carrying your organisation’s name, which no internal inventory will ever capture

The finding that changes the conversation

In most assessments, the technically severe finding is not the one that moves a board. The finding that moves a board is ownership: a live, internet-reachable host, presenting an outdated application, carrying the organisation’s certificate — and no one in the room can say who is responsible for it.

That is not a technology problem. It is a governance problem with a technical symptom, and it is precisely the kind of thing an assurance function exists to surface. It is also, awkwardly, the kind of thing an internal team is structurally poorly placed to find, because the search has to start from outside the organisation’s own conception of itself.