Shadow IT: Usage-Based Tiering for Vendor Risk

‍Last updated October 2026

The 2026 UpGuard Shadow Supply Chain Report found that 72.9% of an organization's active vendor supply chain sits outside formal IT oversight. Your app discovery or single sign-on (SSO) gap analysis surfaces those apps, but no rule decides which ones enter the vendor risk management program. Without a rule that sets both entry and tier, detection leaves a growing list that nobody owns.

Shadow IT is any technology your teams use without IT approval. This guide focuses on the application layer, and our shadow SaaS guide covers the cloud-app subset in depth.

Here, we walk you through how shadow IT spreads across your attack surface. We explore how this human element of risk intersects with UpGuard Vendor Risk and how a tiering framework can support, and be supported by, User Risk discovery.

What is shadow IT tiering?

Shadow IT usage-based tiering assigns each discovered app a vendor tier based on what it does in your environment: how often people log in, what data it exports, and how much access it holds.

You match each discovered app to a vendor, then tier it on actual exposure rather than a declared questionnaire.

The table below maps each usage signal to the exposure it suggests and the default tier it should trigger in your program.

Below you’ll learn how to read each signal and convert it into a repeatable tier rule that hands qualifying apps to formal vendor assessment.

Reading usage signals

URL and domain lists tell you which apps get traffic. Usage signals show what each app can reach and how deeply it sits in daily work, which a tier decision needs.

Usage-based discovery reads three signals, and each one points to a different kind of exposure:

• Login frequency: Daily use means the app sits in a workflow and is harder to remove, raising the impact of a failure or leak.
• Data-export integrations: A customer relationship management sync or file-share connector extracts records from a sanctioned system, so your data now lives with the vendor.
• OAuth scope breadth: “Sign in with Google” grants basic identity scopes, but an app can request more, and mail or Drive write access extends reach past its purpose.

Under OAuth 2.0, each access token covers only the scopes the user approved. That limit makes the grant record a precise map of what the app can touch, so scope breadth carries heavy weight in the tier.

Corporate credentials add another layer, since signing in with a corporate account makes a personal tool an organizational one. Sensitive data tends to follow that login into tools nobody has reviewed. Signing in with a personal account does the opposite: it keeps work usage out of SSO logs and off your inventory entirely.

UpGuard User Risk reads that telemetry alongside OAuth grants, showing which apps employees use, how many people use each one, and what permissions each holds. It also catches sign-ins that never touch your identity provider, and it checks each app’s vendor against your Vendor Risk portfolio.

The same Shadow Supply Chain Report found that unmonitored vendors are three times more likely to have poor security scores. They enter through employee adoption, so they skip the formal security review your sanctioned vendors undergo.

A single strong signal, such as write access to mail or a data-export integration, sets High on its own. Weaker signals need a second one.

Logic-driven tiering and management

Tiers help only when you write down and can repeat the assignment rule. Without one, every discovered app becomes a judgment call, and two reviewers can tier the same app differently.

Supply chain guidance from NIST SP 800-161 ties supplier oversight to criticality. Usage signals give that criticality a concrete, measurable input.

Apply this rule set in order, since an early step can settle the tier before the next one runs:

1. Match the app to a vendor record: If no record exists, assign Critical, pending review, until someone confirms who the vendor is.
2. Check data reach: A scope or export integration touching regulated data means Critical. One touching personally identifiable information (PII) or intellectual property means High.
3. Weight usage depth: For apps with limited reach, login frequency and user count decide between Medium and Low.
4. Allow manual overrides: A business owner can justify raising or lowering the default, and you log the reason on the vendor record.

Behavior-tracking tiers keep your inventory current as employee habits change. When someone grants a new scope that reaches PII or adds an export integration, the tier should change too. Wider adoption across teams should trigger the same review.

The same logic runs in reverse. An app that loses its integration and falls to occasional use can drop one tier at the next review. 

For the full model behind these labels, the vendor tiering guide covers how each tier sets assessment depth and review cadence.

Closing the loop with Vendor Risk

A shadow IT app crosses the intake threshold when its usage signals reach your tier rule's trigger, such as sustained logins and a data-export integration. It also crosses when evidence shows the app holds organizational data. At that point, the app moves off the discovery list and into formal vendor assessment.

Discovery without a next step only documents risk. Once an app crosses the threshold, route it through the Vendor Risk onboarding portal and ask the business owner to justify it. The portal captures the business context upfront and routes the vendor to security for review. An app with no clear purpose becomes a candidate for removal.

In the third-party risk management lifecycle, this handoff moves the app from discovery into onboarding and assessment. From there, assessment depth follows the tier:

• Critical and High: Send a full questionnaire, request evidence, and add the vendor to continuous monitoring.
• Medium: Send a lighter questionnaire covering only the data the app touches, and add the vendor to continuous monitoring.
• Low: Register the vendor and monitor it without a questionnaire.

Your vendor onboarding policy sets the rules for each step, including who approves exceptions. After assessment, the vendor moves into ongoing risk management and continuous monitoring, where its tier can shift as its signals change.

UpGuard Vendor Risk onboards each vendor and runs assessments at the depth its tier requires. With User Risk alongside it, you can see which discovered apps come from vendors you don't monitor yet and decide which ones enter formal assessment.

Why usage signals beat declared data

Apps arrive through sign-in prompts and free tiers faster than procurement intake can record them. By the time intake hears about an app, it may already have active users and connected data.

Declared questionnaire data describes what a vendor says it does, and that answer can sit unchanged for months as the app gains scopes. Usage signals describe what the app can reach in your environment today, making them a stronger input for shadow IT tiering.

Some teams argue that SSO blind spots make a better tiering input for unknown vendors. SSO gaps are a strong discovery signal, but they show that an app exists, not how deep it reaches. Use those gaps to find apps, then let usage signals set the tier.

How UpGuard helps with shadow IT tiering

Discovery and tiering work best as one connected flow, where the signals that surface an app also inform its tier:

• User Risk: The browser extension finds the SaaS and AI apps your workforce uses, including non-SSO apps and personal account sign-ins. It also shows the OAuth permissions employees have granted to connected apps, and cross-references each discovered app with your Vendor Risk portfolio, so you can see whether its vendor is already monitored.
• Vendor Risk: Handles the second half of the flow, from onboarding and tiering through assessment and continuous monitoring, bringing every vendor into one portfolio.

Start a free trial of Vendor Risk to see how discovered apps move into onboarding and assessment.