Skip to main content

Sonar Apps: controlling connected third-party applications

This allows SMB customers to deal with the same point of contact and, if, for example, you missed the opportunity to sell Sonar last time, an incoming enquiry for Slash might be the chance to close both deals.

Your employees sign in to dozens of applications with their Google or Microsoft account. Each of those connections grants permissions over your data — sometimes very broad ones, often forgotten. Sonar Apps gives you the list, the detail of the permissions, and the means to act.

👍 Good to know: Sonar Apps is included in Sonar at no additional cost, and available to all customers. There is no dedicated configuration: it uses the same activation journey as the rest of Sonar. See Configure Sonar (Microsoft and Google).

1️⃣ How applications are detected

Sonar queries the Google and Microsoft APIs to identify the applications your employees have signed in to through single sign-on — the "Sign in with Google" or "Sign in with Microsoft" buttons.

Synchronisation runs every two hours.

2️⃣ Permissions and their access level

For each application, Sonar doesn't just tell you who uses it: it details the permissions granted. And for each one:

  • a plain-language description, rather than a technical label;

  • an access level, from "low" to "very high", showing how sensitive the permission is.

For example, a permission granting the right to read, compose, send and permanently delete every email in a mailbox is flagged as high access — which stands to reason given what it allows.

3️⃣ High access doesn't necessarily mean risk

This is the point to grasp before looking at the list. A legitimate business tool, rolled out and approved by your teams, can have a very high access level without being a problem at all. Access level alone isn't enough to judge.

That is why applications are ranked by risk, which combines four factors:

  • Access level: the higher it is, the higher the risk.

  • Category: some families of tools are notoriously riskier — automatic AI note-takers, PDF converters.

  • Riot's trust score: we assess applications and rank them from low to high. The better known and more established an application is, the lower the risk.

  • Adoption: an application used by very few employees points to unmanaged usage. This is often the most telling signal for an IT team.

💡 The right reflex: start with applications that combine high access and low adoption. That is where you find tools installed by a handful of people, with extensive permissions, that nobody has approved.

4️⃣ The four statuses of an application

  • Unclassified: the default status. The application is neither approved nor blocked.

  • Approved: either manually by you, to mark the application as legitimate; or automatically by Sonar, when the application is used by more than 50% of your employees, or by more than 25% without any high-access permission having been granted.

  • Blocked: you have cut the permissions and prevented future usage. See section 5️⃣.

  • Revoked: you haven't done anything, but Sonar sees that no employee grants access to this application any more. It has faded out on its own.

5️⃣ Blocking an application

Blocking an application has three effects.

  • Every permission granted is revoked. You can also block the application for only some of your employees.

  • Albert notifies the employees concerned. You decide whether to send that notification, and you can adjust the message before confirming — for instance to say which tool to use instead, and why.

  • Any new connection is revoked automatically within two hours, and the employee is notified again.

⚠️ Important: the notification is currently sent in the administrator's language, not in each employee's. Worth bearing in mind if your teams are multilingual: write the message in the most widely understood language, or switch the notification off and communicate through your own channels.

💡 Our recommendation: don't block without explaining. An employee who loses access to a tool they were using to do their job will look for a workaround. The accompanying message, with the approved alternative, makes all the difference between a rule that is accepted and one that is circumvented.

6️⃣ Launching a targeted simulation campaign

Since Sonar knows which employees use which application, you can use that to target a phishing campaign. From an application's page, you create a campaign that Riot pre-fills with:

  • the title;

  • the audience, meaning the employees who use the application;

  • the templates, if templates matching that application exist.

This is targeting at its most realistic: you are testing employees on a tool they genuinely use. See Create a phishing campaign.

Key takeaways

  • Included in Sonar, with no dedicated configuration, and synchronisation every two hours.

  • Risk combines access level, category, trust score and adoption — high access alone doesn't mean danger.

  • Four statuses: unclassified, approved, blocked, revoked. Approval can be automatic beyond certain adoption thresholds.

  • Blocking revokes permissions, notifies employees and applies to future connections.

  • The blocking notification goes out in the administrator's language.

Did this answer your question?