Shadow IT and your attack surface: what your IT inventory does not see

Between 30 and 60% of an organisation's internet-exposed assets are not listed in its IT inventory. Shadow IT is not an IT hygiene problem. It is an invisible attack surface that your current tools are not monitoring.

This guide explains what Shadow IT actually is, why it represents a concrete risk for CISOs and CIOs, and how to map it before attackers do. It includes documented breach examples (Twitch, Volkswagen, Dedalus) and a five-step operational guide.

All systems, applications, services and IT assets used within an organisation without the approval, knowledge or oversight of the IT department. It is not exclusively the result of deliberate workarounds: business teams often deploy tools to meet genuine operational needs, independently of established IT processes.

For a long time, Shadow IT was treated as an IT governance problem: teams bypassing the IT department, unregistered SaaS tools, off-process spending. An irritant, not a threat.

That is no longer the case. Today, every undeclared asset is an unmonitored asset. An unmonitored asset is a potential entry point for an attacker who does not need your inventory to find it.

The core problem. An attacker starts from your domain name and reconstructs everything that flows from it: subdomains, SSL certificates, exposed services, cloud storage, legacy APIs. They find what you have forgotten, before you have identified it yourself.

The IT department knows the assets it has officially deployed or registered, including in internally managed cloud infrastructure. It does not necessarily know:

• Development or staging environments never decommissioned after a project ended

• Cloud storage buckets created by a data team without going through IT

• Subdomains inherited from an acquisition or a supplier three years ago

• SaaS instances activated by a business unit with a personal or corporate credit card, without IT involvement

• Legacy APIs that no one thought to deactivate after a platform rebuild

• Third-party supplier systems connected to your environment

These assets respond to requests. They are reachable from the internet. Nobody on your security team is monitoring them.

Key figure. Across organisations that have deployed Patrowl, the first scan iteration detects on average 30 to 60% of exposed assets missing from the declared IT inventory. This is a structural blind spot, not an exception.

For a CISO, the perimeter to monitor goes well beyond unregistered SaaS tools. The categories below cover all asset types typically absent from declared IT inventories.

Forgotten infrastructure

• Development or staging environments never deprovisioned

• Build or test servers left running

• Cloud instances created for a project and abandoned

• Subdomains inherited from acquisitions or migrations

• Sites or apps created for a temporary campaign (promotion, event, product launch) and forgotten after it ended

Unregistered SaaS

• Tools activated via a personal or corporate card without IT approval

• Accounts not deactivated or deleted after an employee leaves

• API integrations with unvalidated third-party services

• Accounts created by former employees still active

Uncontrolled cloud

• S3 or Azure Blob buckets created outside IT processes

• Cloud accounts opened by data or marketing teams

• Permissive configurations left as default

• Unintentional public access on internal resources

Third parties & suppliers

• Supplier support or CRM systems connected to your environment

• Partner APIs not documented in your inventory

• VPN access granted to suppliers and never revoked

• Subsidiaries and acquired entities not yet integrated

Shadow IT vs declared inventory. The IT inventory covers what the IT department has deployed. The EASM inventory covers what is actually exposed on the internet, starting from your domain names and brand names, exactly as an attacker would. That is the difference between what you think you expose and what you actually expose.

ll three incidents are publicly documented. In each case, the compromised asset was outside the inventory, outside monitoring, and reachable from the internet.

01 — Twitch — server misconfiguration exposing internal repositories
October 2021 · 125 GB of data exfiltrated · source code exposed

A server configuration error at Twitch allowed an unauthorised third party to access internal Git repositories. Platform source code, internal security tools, and streamer payout data — 125 GB in total — were exfiltrated and published on 4chan in October 2021. The initial access resulted from a misconfiguration, not a sophisticated attack.

Shadow IT connection. The investigation revealed that the misconfigured servers were reachable from the internet. Continuous mapping of the exposed surface from Twitch's root domains would have identified the accessible servers — exactly what an attacker does during reconnaissance, and what EASM does continuously.

02 — Volkswagen / Cariad — S3 bucket left open for months
2024 · 800,000 records exposed · EV geolocation data

A cloud storage bucket belonging to Cariad, the Volkswagen Group's software entity, remained publicly accessible for several months. It contained geolocation data from 800,000 electric vehicles, including those of political figures and German military officers. The asset was monitored by no one after it was deployed.

Shadow IT connection. At the scale of an international group like Volkswagen, manually tracking every cloud service deployed by every entity is structurally impossible. Continuous monitoring of exposed cloud storage is a core EASM capability. This is precisely the type of asset that IT inventories fail to capture.

03 — Dedalus Biologie — health records of 500,000 patients left on a forgotten FTP server <
2021 · 500,000 patients exposed · CNIL fine of €1.5M · sensitive medical data

During a software migration, Dedalus Biologie transferred personal health data from 500,000 French patients to a temporary, unsecured and unencrypted FTP server. The server was not decommissioned after the migration ended. The data — social security numbers, medical treatments, HIV and pregnancy information — was exposed on the internet for several months before being discovered. The CNIL fined Dedalus €1.5 million in April 2022.

Shadow IT connection. The FTP server did not appear in any security inventory after the migration. Continuous mapping of the exposed surface from Dedalus's root domains would have identified it as a reachable asset — exactly the type of forgotten asset that EASM detects continuously.

What these incidents have in common. In all three cases, the compromised assets were absent from security inventories and accessible from the internet. For Twitch, Volkswagen and Dedalus, continuous external mapping would have identified the unregistered exposed services before an attacker, a researcher or a journalist found them.

The right method for mapping Shadow IT is counter-intuitive: the starting point is not inside your organisation — your systems, your logs, your IT tickets — but outside, from the attacker's perspective.

The outside-in perspective. Starting from your root domain and automatically reconstructing everything that extends from it on the internet, without being limited to what you have declared. This is the principle behind External Attack Surface Management (EASM) — the only approach that finds what you do not know you have.

1. Start from the domain.
The process begins from the root domain (company.com), as well as from company, brand and product names. These data points are used to reconstruct the exposed surface — subdomains via SSL certificates and DNS records, associated IP ranges, ASN numbers, cloud identifiers — and to validate ownership of discovered assets. This step surfaces assets that were never declared: subsidiaries, acquisitions, test environments, suppliers.

2. Identify what is active and exposed.
Each discovered asset is probed across several hundred common protocols to determine whether it is active or simply reserved (parked domain, inactive service). Exposed technologies are identified, along with open ports. At this stage, accessible staging servers, unprotected administration panels and publicly accessible cloud storage are surfaced.

3. Qualify the risk of each asset.
Each asset is cross-referenced against known CVEs, the EPSS score, the CISA KEV catalogue and business context data. Misconfigurations and poor exposure practices are also identified. EASM does not replace penetration testing: it qualifies the exposure and criticality of each asset. A publicly accessible cloud storage bucket containing customer data carries a fundamentally different risk level from an expired subdomain with no active service.

4. Monitor new assets continuously.
Shadow IT is not static. Every deployment, every new integration, every acquisition can introduce new undeclared assets. Continuous monitoring detects changes as they occur, not at the next annual audit.

Not all Shadow IT assets carry the same level of risk. Remediation priority depends on two factors: internet exposure and the sensitivity of the data or access the asset controls.

An asset classified as internal can reach critical priority within hours if a misconfiguration makes it accessible from the internet. A point-in-time audit will not capture that change. Continuous monitoring detects it as it occurs and triggers an alert.

You do not need a team of penetration testers to start reducing your Shadow IT exposure. Here are five actionable steps, ordered by impact.

01 — Map your subdomains from the outside. Ask your security provider or EASM tool for a complete list of active subdomains associated with your root domains. Compare against your IT inventory. The gap reveals your unregistered exposed assets. Subdomains are often the most dangerous, as they are directly reachable from the internet.

02 — Audit your cloud storage assets. Ask your cloud teams for a complete list of all storage buckets (S3, Azure Blob, GCS) with their access policies. If your organisation does not have a centralised inventory, an external enumeration from your root domains is the fastest way to obtain one. Any bucket accessible publicly without documented justification is an immediate priority.

03 — Map active third-party access. List all suppliers with access to your environment: VPN, API, service accounts. Define and enforce onboarding and offboarding processes. Revoke access for suppliers whose engagement has ended. Verify that the systems of active suppliers are not exposed on the internet without monitoring.

04 — Include acquisitions in your security perimeter. Trigger an EASM mapping of any acquired entity before integrating it into the group's infrastructure. Assets inherited from an acquisition are often the highest risk: unknown, out of date, and directly exposed on the internet.

05 — Implement continuous monitoring. A Shadow IT audit provides a snapshot of the current state. Your infrastructure changes constantly. Continuous monitoring via an EASM tool or a PTaaS platform ensures every new asset is detected as it appears, not six months later.

Patrowl operates within a CTEM process by combining EASM and vulnerability validation in a unified platform. The first iteration detects on average 30 to 60% of exposed assets missing from the declared IT inventory. Continuous monitoring ensures every new asset is surfaced as it appears, with a contextualised risk level rather than a raw list of unranked results.

Customer deployment examples

MGEN (mutual insurer, 4 million members). Before Patrowl, the exposed attack surface was only assessed through point-in-time penetration tests, whose results were already partially outdated by the time the report was delivered. Continuous EASM mapping gave MGEN permanent visibility across all its exposed assets, including those that appeared in no declared IT inventory.

Colas (international construction group, 50+ countries). At that scale, manually inventorying the exposed attack surface is structurally impossible, particularly for subsidiaries and acquired entities that multiply domains, subdomains and inherited infrastructure. Patrowl enables Colas to regain control of security across all its entities from the group's root domains, including after each acquisition.

Brest Métropole. When CVE-2025-53770 was published (critical remote code execution vulnerability in SharePoint Server, CVSS 9.8), Patrowl developed the exploit, tested it against the métropole's exposed SharePoint assets, and delivered the alert to the Blue Team within 39 minutes. Notification at 15:57, alert after exploitability validation at 16:36. This case illustrates what continuous monitoring enables: not just detecting that a CVE exists, but confirming in production whether the asset is actually vulnerable, and alerting immediately.

Discover the exposed assets that your IT inventory misses—on average, 30% to 60% of your actual infrastructure—before attackers find them.