Article

Vetting Third-Party Apps Before They Cost You

·By Mathew Chewing

Every app someone connects to your Microsoft 365 tenant inherits a slice of your access. Here is the checklist for approving integrations without opening a side door.

The Hidden Risk of Integrations: A Checklist for Vetting Third-Party Apps (API Security)

Nobody breaks into a well-defended network any more if they can simply be invited in. And every time a staff member clicks "Accept" on an app that wants to read your mail, you have issued an invitation — one that does not expire, does not appear in any inventory, and keeps working long after the person who granted it has left.

This is the quiet risk in modern business IT. You can have perfect passwords, phishing-resistant MFA and a locked-down firewall, and still hand a third party standing access to everything, because the access was granted rather than stolen.

How an integration actually gets its access

When an app asks to connect to your Microsoft 365 tenant, it requests a set of permissions called scopes. The consent screen summarises them in friendly language, which is where the trouble starts, because two very different things look nearly identical.

Delegated permissions let the app act as the signed-in user. It can see what they can see, and no more. If that person leaves and the account is disabled, the access dies with it.

Application permissions let the app act as itself, across the whole tenant, with no user involved. Mail.Read as a delegated permission means one mailbox. Mail.Read as an application permission means every mailbox in the business, forever, whether or not anyone is logged in.

The consent dialog does not shout about this distinction. It is the single most important thing to check, and it is one line in a list.

The tokens that outlive everything

Once consent is granted, the app receives an OAuth refresh token. That token is the real credential from then on, and it has properties that surprise people:

  • It does not care that you later changed the user password.
  • It does not prompt for MFA — authentication already happened, once.
  • It keeps refreshing itself indefinitely until consent is explicitly revoked.

So the standard incident response of "reset the password and force MFA" does not remove a malicious or compromised integration. You have to revoke the consent and kill the token. If you do not know the integration exists, you will not do either.

The checklist: before you approve anything

1. Read the permissions, not the description

Ignore the marketing. Look at the actual scopes. Ask the only question that matters: if this vendor were breached tomorrow, what would the attacker inherit? An app that wants Files.Read.All and Mail.ReadWrite to do calendar scheduling is asking for far more than its job requires.

2. Insist on least privilege

Many vendors request broad scopes because it is easier than scoping properly, and most customers never push back. Ask whether the app can work with narrower permissions. Reputable vendors will have an answer. A vendor that cannot explain why it needs tenant-wide mail access has told you something useful.

3. Find out where the data goes

Does the app store a copy of your data, or just read it in transit? Which country is it stored in? If personal information about Australians leaves the country, the Privacy Act and the Australian Privacy Principles follow it — including your obligation to take reasonable steps to ensure the overseas recipient handles it properly. That obligation does not transfer away just because you clicked accept.

4. Check the vendor is a real, durable business

A two-person startup with a great product may be gone or acquired in eighteen months, along with your data. Look for a published security page, a named data protection contact, a documented breach notification process, and ideally an independent assessment such as SOC 2 or ISO 27001. Absence of all four is a signal.

5. Decide who is allowed to say yes

By default, Microsoft 365 lets ordinary users consent to apps on their own behalf. That means any staff member can connect an unvetted tool to their mailbox without telling anyone. Turning on admin consent workflow changes this: the user requests, an administrator reviews, and the request is recorded. It adds a small amount of friction and removes an entire category of surprise.

Auditing the integrations you already have

Most businesses have never looked. The first audit is usually uncomfortable and always worth doing.

  1. List every enterprise application and every OAuth consent granted in your tenant.
  2. For each, record what it is, who approved it, when, and which permissions it holds.
  3. Flag anything with tenant-wide application permissions for immediate review.
  4. Revoke anything nobody can identify, anything whose owner has left, and anything for a trial that ended.
  5. Put a calendar reminder to repeat this quarterly.

Expect to find a handful of tools someone trialled in 2023 and forgot. Each of those still holds a live token.

The attack this actually prevents

Consent phishing looks nothing like normal phishing, which is why it works. There is no fake login page and no stolen password. The victim receives a link to what appears to be a legitimate document-signing or file-sharing tool, is taken to a genuine Microsoft consent screen — the real domain, real certificate, real everything — and approves an app that wants to read mail and files.

No credentials change hands. MFA is satisfied, because the user really did authenticate. Every control you bought works exactly as designed, and the attacker walks out with a token that reads the mailbox indefinitely.

The defences are the boring ones above: restrict who can consent, review what is connected, and watch for new grants. Managed detection and response can alert on a new application consent the moment it happens, which turns a silent compromise into a ten-minute investigation.

Keeping it manageable

None of this requires banning integrations. Integrations are why modern business software is useful. It requires knowing which ones exist, what they can reach, and having a way to turn one off.

An IT audit will produce the inventory, and ongoing managed IT keeps the quarterly review from quietly becoming an annual one and then never.

Local IT and cyber security support across NSW

Chewing IT runs managed IT and cyber security for small and mid-sized businesses from our Wyong and Hornsby offices, covering the Central Coast, Newcastle, Lake Macquarie and Hornsby.

Not sure what is already connected to your Microsoft 365 tenant? Ask us for an integration audit — the first one usually turns up something worth revoking.

Want this handled for you?

Chewing IT looks after IT, cloud and cyber security for businesses across the Central Coast, Newcastle and Sydney. Free, no-pressure consultation — no contracts, no jargon.