How to Audit Third-Party App Access to Your Healthcare SaaS
Edward StrattonThe Access You Granted and Forgot
Every small practice has a drawer full of keys nobody remembers cutting. In the digital world, those keys are connected apps. Someone on your team tried a scheduling tool and clicked “Allow” so it could read the calendar. A front-desk lead connected a texting service to send appointment reminders. A provider tested an AI note-taker that asked to access email and documents “to work properly.” Each of those clicks handed a third party standing permission to reach into your Microsoft 365 or Google Workspace — and, in many cases, into data that counts as electronic protected health information (ePHI).
Most of those apps are fine. Some are not. And almost none of them are ever reviewed again. That is the gap this guide closes. Learning how to audit third-party app access to your healthcare SaaS is one of the highest-value, lowest-cost security habits a small practice can build, and it directly supports your obligations under the HIPAA Security Rule. You do not need enterprise software or a security team. You need an afternoon, an admin login, and a checklist.
The dangerous app is rarely the one you are watching. It is the one you approved eighteen months ago, that still has access, that nobody remembers, and that you would never notice misbehaving.
What “Third-Party App Access” Actually Means
When you sign in to a website by clicking “Continue with Google” or “Sign in with Microsoft,” you are using a protocol called OAuth. Instead of giving the app your password, your identity provider — Google or Microsoft — hands the app a token: a scoped, revocable permission slip that says “this app may read this person’s calendar,” or “this app may send email as this person,” or, more alarmingly, “this app may read all files in the organization.”
What is OAuth access in medical software
Two things make OAuth access easy to overlook. First, it survives password changes. Rotating a staff member’s password does not revoke the tokens apps already hold — those keep working until someone explicitly revokes them. Second, it operates as a machine, not a human. Multi-factor authentication protects a person logging in. It does nothing to govern what a connected app does after it has been approved, because the app is not “logging in” in the way a human does — it is presenting a token you already granted. This is exactly why the attacks documented in our companion post on OAuth app attacks that skip MFA were so effective: the intruders were not defeating your login controls, they were riding permissions that were already trusted.
For a healthcare practice, the stakes are specific. If a connected app can read a mailbox that contains patient messages, referral PDFs, or billing correspondence, then that app can reach ePHI — and under HIPAA, the vendor behind it is very likely a business associate who must have a signed agreement on file. An unreviewed app inventory is therefore not just a security gap; it is a compliance gap hiding in plain sight.
Why MFA Is Not Enough Here
Does MFA stop OAuth token theft
It is worth stating plainly because so many practices assume otherwise: multi-factor authentication does not stop OAuth token theft or connected-app abuse. MFA is essential — it is one of the single most effective controls a practice can deploy, and nothing here argues against it. But MFA and connected-app governance protect against different threats.
MFA answers the question “is this really the right human at the login screen?” Connected-app governance answers a different question entirely: “what are the non-human integrations allowed to do, and should they still be allowed to do it?” A token stolen from a compromised vendor, or a malicious app a staff member was tricked into approving, sails past MFA because the human login already happened — legitimately — at the moment consent was granted. You can have flawless MFA and still be wide open on this axis. The two controls sit side by side; neither substitutes for the other. If MFA is the deadbolt on the front door, app governance is knowing which contractors still have a copy of the key.
The Third-Party App Access Audit — Step by Step
Here is the core citable asset of this guide: a repeatable audit any small practice can run quarterly. Work through it in order. It is written to be tool-agnostic, with notes for the two platforms most practices use.
1. Find the app inventory. In Microsoft 365, an administrator opens the Microsoft Entra admin center and looks under Enterprise applications, then “Consent and permissions,” to see every app users have approved. In Google Workspace, the admin console has “Security → API controls → App access control → Manage third-party app access.” This single list is the thing most practices have never opened.
2. Sort by permission, not by name. Do not read the list alphabetically. Sort or scan for the apps holding the broadest permissions — anything that can read all mailboxes, read all files, read directory data, or act across the whole organization rather than for one user. Breadth of access, not familiarity of name, is what tells you where the risk concentrates.
3. For each app, ask four questions. Who approved it and when? Is it still in active use? What can it actually reach — and does that include ePHI? Is there a signed business associate agreement with the vendor if it touches PHI? Write the answers down. The act of writing turns a vague unease into a decision list.
4. Revoke ruthlessly. Every app that is unused, unrecognized, redundant, or over-permissioned gets its access revoked. In both Microsoft and Google, revoking is a single action per app, and it takes effect immediately — the token stops working. If revoking something breaks a workflow, you will find out quickly and can re-approve it deliberately, this time with a record of why it exists. Apps inactive for 90 days or more are prime candidates.
5. Scope survivors to least privilege. For the apps you keep, check whether they were granted more than they need — a reminder-texting tool almost certainly does not need to read every file in the organization. Where the platform allows it, tighten the scope. Where it does not, that over-reach is itself a reason to reconsider the vendor.
6. Turn on and review the logs. Both Microsoft 365 and Google Workspace record app and API activity. Turn that logging on if it is off, and build a habit of glancing at it — you are looking for an integration suddenly pulling far more data than usual, which is the earliest sign something has gone wrong.
7. Lock down consent going forward. The most durable fix is to stop the problem at the source. In Microsoft 365, admins can restrict user consent so that staff can only approve low-risk apps and anything sensitive routes to an admin for review. Google Workspace offers similar controls to allow-list trusted apps and block the rest. This converts app sprawl from an ongoing leak into a deliberate, reviewed process.
8. Record it and schedule the next one. Save the inventory, the decisions, and the date. Put the next audit on the calendar for one quarter out. An audit you run once is a snapshot; an audit you run quarterly is a control.
An OAuth-Scope Risk Decision Table
Not every permission carries the same weight. When you are triaging the list in step 2, this table helps you decide fast. It maps common consent scopes to a risk tier and a default action for a healthcare practice.
| Permission the app was granted | Risk tier | Default action for a practice |
|---|---|---|
| Read/write all mailboxes or all files org-wide | Critical | Revoke unless business-critical with a signed BAA and a named owner |
| Send email as a user; read a shared clinical inbox | High | Keep only with a BAA; confirm the vendor and the active use case |
| Read directory / all users’ profiles | High | Revoke unless it is a known identity or security tool |
| Read one user’s calendar or contacts | Medium | Keep if in active use; revoke if unrecognized |
| Basic profile / “sign in” only (name, email) | Low | Generally safe; still revoke if the app is unused |
| Any scope on an app nobody can identify | Critical | Revoke now; investigate later |
The rule of thumb: the broader the scope and the closer it sits to ePHI, the less benefit of the doubt the app earns. When in doubt, revoke — re-approving a legitimate app takes seconds, while cleaning up after a bad one can take months.
Where This Fits in HIPAA
This audit is not a nice-to-have bolted onto compliance; it lands squarely inside three things the HIPAA Security Rule already expects of you. Access management — knowing who and what can reach ePHI — is an access-control expectation. Knowing your environment, including the asset and data inventory that maps where ePHI lives, is foundational to a defensible risk analysis. And the business associate relationship — ensuring every vendor that touches PHI has a signed agreement — runs directly through your app inventory, because a connected app with mailbox access is a vendor touching PHI whether or not anyone signed anything. Running this audit is one of the clearest ways to demonstrate that your practice is actively managing, not just documenting, its ePHI exposure.
Framed that way, the app audit is a small piece of a much larger discipline: understanding your real attack surface. Once a platform hands you the keys, the connections you approve are yours to govern — which is exactly the settings-are-your-job lesson at the heart of the SaaS shared-responsibility model.
Making It a Habit, Not a Heroic Event
The practices that stay ahead of this are not the ones that do a dramatic one-time cleanup. They are the ones that make the audit boring. A quarterly calendar reminder, a shared document that records each decision, and a standing rule that new apps route through an owner rather than a spontaneous “Allow” click — that is the whole program. It does not require a budget line. It requires a habit and someone accountable for it, and for most small practices that someone is a partnership between the office and its IT provider.
If you have never opened the connected-apps page in your admin console, that is the single most useful thing you can do this week. Most practices are genuinely surprised by what they find there — and pleasantly surprised by how quickly the list gets shorter once someone finally looks.
Byzantine takeaway: The apps connected to your practice’s cloud are a set of standing permissions you granted and then forgot. Auditing them is not exotic security work — it is housekeeping that happens to close one of the most-exploited doors in modern breaches. Open the list, ask the four questions, revoke what you cannot justify, and put the next review on the calendar.