Access risk
An explanation of access risk and how it's determined.
Trelica will assign an 'access risk' level to any application in your inventory that your users are accessing via OAuth (e.g. 'Sign in with Google', if you're using Google Workspace). You can find this access risk in the list view of your inventory, in the Permissions risk report, and on individual application profiles.
Access risk is just one way of looking at the risk in your SaaS inventory and can help you make decisions about the apps Trelica is discovering. For instance, an app that is predominantly for home use and that has high access risk might be something you want to address.

How we're defining risk

Our access risk grading is based on OAuth Scopes i.e. the permissions your users are granting to third party apps. Google and Microsoft support hundreds of OAuth Scopes, ranging from basic, low risk permissions that grant the user access to an app, through to permissions that give a third party app complete access to a user’s email account or cloud file storage.
You can find a much more detailed review of the technology behind these OAuth Scopes here.

Google’s sensitive OAuth Scope list

Google flags 46 OAuth Scopes as being sensitive and requires vendors of apps using these scopes to undergo additional verification when registering for Google Sign-in . Our ‘high risk’ category is based on these sensitive scopes i.e. any app using any one of these scopes is categorised as high risk.
Occasionally an app might provide multiple routes of access via OAuth, so a simple login vs an add-on that integrates data from a Google Sheet. One route of access may be categorised as low risk, with the other high risk. In this situation, if any single user has authenticated with the high risk scopes the whole app is categorised as high risk.
There isn't a direct equivalent for Microsoft's OAuth scopes. To grade access risk for Azure AD based OAuth we've mapped Google's sensitive scopes list to Microsoft's.

Inherent vs contextual risk

The high risk category addresses the inherent risk that comes with users granting broad permissions to third party apps. Access risk doesn't address the contextual risk that comes from user behaviour within an application e.g. a user uploading PII to an unmanaged app. Irrespective of the risk categorisation for that app, this user behaviour represents risk by virtue of the fact that a user is making decisions about which third parties are holding your organisation’s sensitive data.

Why don't I see an Access Risk for an application?

Trelica detects applications from different sources, for example:
  • Single Sign On to applications through your Identity Provider (Google, Okta, Azure etc)
  • Spend data from a finance or expense system
  • Manually entered applications
Access Risk only applies to applications detected from your Identity Provider, and only to a very specific form of Single Sign On called "OpenID Connect". OpenID Connect is most commonly seen as "Sign in with Google" buttons on some web applications, although it's also available on some apps for Microsoft 365.
If a user is connecting to an application by clicking on an icon in a "My apps" dashboard, or logging in without using a "Sign in with Google" button, then they're likely connecting using SAML2 Single Sign On which doesn't represent any access risk.
Finally, if someone did log in with OpenID Connect, but a very long time ago, then the so-called "access token" that lets the application interact with your Identity Provider might have expired. Since this no longer represents an active risk, the access risk will not be shown for that user against an application.
Copy link
Outline
How we're defining risk
Inherent vs contextual risk
Why don't I see an Access Risk for an application?