Understanding the 'shadow IT' challenge, supply chains, and the scope of TPCRM

As is evident from the name, a Third-Party Cyber Risk Management (TPCRM) program must strive to understand and mitigate the risks stemming from third parties. Picking the right tools, processes, and people to achieve this objective is a challenge in itself, but there is a somewhat hidden yet unavoidable catch: defining what constitutes a "third party," the scope of the program, and our understanding of the cyber (or digital) supply chain.

Even before cybersecurity becomes a concern for third-party risk management (TPRM), it can be quite useful to split vendors into categories. After all, only some vendors are critical to business operations. For more specific services or products, the vendor might present a business risk rather than (or in addition to) a potential security risk, with the danger related to the lack of alternative suppliers, even if that supply being cut does not represent an immediate risk.

Once we start caring about cyber risk, however, the complexities go up a notch. Business partners might hold sensitive data even when the corporate networks do not have a permanent connection. Under normal operation, customers don't generally have access to any data outside of their own, but the access privileges that they are granted could warrant a mitigation plan for a scenario where their account is compromised or deliberately misused by a malicious insider.

As we have all become used to relying on connected experiences, it sounds old-fashioned to mention "cyberspace." Yet, we must not forget that IT systems lack the "physicality" of traditional products and services. In practice, a business can be leaning on dozens of third parties that it does not see, each carrying a number of intangible risks. Formally, these entities are not vendors, suppliers, partners, or customers, yet they are still third parties to the business.

This is called the "shadow IT" problem.

Shadow IT and the 'digital' supply chain

If someone brings a new object or contractor to the office building, it's not very difficult to see what is going on. On the other hand, if a staff member types a search query containing confidential data into a search engine or sends sensitive documents to an external platform, it's unclear whether there will be anything for others to see. In fact, since personal computers and smartphones are now ubiquitous, employees can easily perform these tasks on personal devices.

When this happens, there is a third party (and perhaps unsanctioned devices) handling business data.

Unfortunately, these are only basic examples, since more extreme cases tend to be different in each business sector. At technology companies, staff may have permission to deploy cloud computing resources or pipeline changes, allowing them to leave test environments online by mistake, or to create links between environments that were not supposed to exist.

At universities and research labs, IT systems might be repurposed for different projects, perhaps even exposing parts of the infrastructure to the internet unintentionally. As an example, a server that had received a firewall exception for a previous project could be reused for an entirely new system, exposing services that were never meant to be reachable by the outside world.

More broadly, we must keep in mind that software is made up of many components (or "dependencies"). Vulnerabilities present in those components can often be exploited to compromise applications built with them. In some cases, businesses might not be aware that they are vulnerable to attack, especially when they rely on bespoke systems and are unaware of every single component they include.

Moreover, software can be updated throughout its lifetime in ways that make previous risk assessments obsolete. When networking, cloud or AI features are added, for example, the business might find that some of its data is in a remote system even when there was no expectation that this was the case.

In certain scenarios, users themselves add new components. Browser extensions are one such example. Though their reach is theoretically restricted to the web browser itself, this boundary hardly makes a difference when so much work is done through web-based platforms and systems.

These issues compound each other. When we do not know every component inside the software that has been deployed, and we do not have an exhaustive list of other software and the services being used by the individuals inside an organization, the unknowns will be multiplied.

If there's no one else trying to solve the visibility problem yet, this challenge might have to fall under the scope of the TPCRM/TPRM program.

AI enters the fold

While the "shadow IT" issue already existed before the widespread adoption of Artificial Intelligence systems and applications, AI nonetheless brought along a few challenges. One of them stems from the rate of adoption: businesses often did not devise AI policies fast enough, and many have not been able to gracefully integrate AI into corporate systems.

While some companies actively encouraged users to come up with use cases for AI themselves, other businesses instead banned AI use or left employees totally in the dark, leading them to try the tools out without being offered any alternative or guidance. Since AI was a new technology to nearly everyone, even success stories could hide risks that were not addressed by corporate policy.

In our post about the Verizon 2026 Data Breach Investigations Report, we noted that 67% of users are signing up for AI services using non-corporate accounts.

Even when employees do use their corporate account, this may not be desirable. AI is very much a modern, connected product. AI solutions may request continuous access to corporate data, dramatically increasing the risk of exposure.

The incident at Vercel, which we discussed in our newsletter, is an example of this. An employee allowed an AI service to access data in such a way that, when the AI infrastructure was compromised, the intruders were able to use this pathway to obtain authentication tokens and other data that the employee had access to. As some of the data belonged to Vercel customers, the third-party breach that started on the AI provider became an incident for Vercel customers.

Even if a business has previously opted for services that do not have AI features, many platforms and software products are adding this functionality through updates. If policy and procedures do not reflect this change, the risks will remain unmitigated.

IT systems are highly complex, but service providers strive to mask that complexity and make them usable without friction. This lack of friction also means that users may not be fully aware of the risks, or that they are introducing a "third party" that is not going to be monitored like other vendors. 

This is a problem for everyone

Businesses certainly face an uphill battle to ensure that they know who their third parties are, and it's one that's becoming more complex by the day. But the scale of the issue only becomes clear when we realize that everyone has this problem, including third parties themselves.

Leveraging several solutions in tandem might be necessary. Risk awareness training, better policies, and perhaps even redesigned business processes. Third-Party Cyber Risk Management programs are more likely to be successful if they are allowed to expand beyond vendor onboarding and contracts.

Businesses must stay on top of ongoing changes in their ecosystem, including new features in the software (traditional or as a service) that they use. Because point-in-time risk assessments quickly become outdated in fast-moving IT environments, businesses should prefer strategies that have a better chance of maintaining visibility of new risks.

Third parties face the same challenges with their IT environment. That's why inside-out monitoring, which offers accurate and continuous assessments for effective security outcomes, can be invaluable for third-party cyber risk management 

When it comes to business applications and their components, it's worthwhile to integrate Software Bill of Materials (SBOMs) into your asset catalog. An SBOM is a machine-readable inventory of the libraries and dependencies used to build a complete software product. Because it is machine-readable, it can be leveraged by tools to compile this data and offer risk management insights.

As for how to mitigate the risks from AI usage by third parties, we'll talk more about that in an upcoming blog post dedicated to this exact question. Stay tuned!