Before You Connect That App: Five Questions Worth Asking

Somebody in your office found a tool that fixes a real annoyance. A scheduler that syncs with everyone’s calendar. A transcription app for meetings. A signature service. A form builder. They signed up with their work email, clicked Sign in with Microsoft, saw a screen with a list of permissions on it, clicked Accept, and went back to work.

That took about eleven seconds and it did something more consequential than most contracts your business signs. It did not just create a login. Depending on what the app asked for, it may have granted a company you have never heard of standing, background access to read mail, read files, or act on behalf of the person who clicked.

I am not going to tell you to ban these tools. Half of them are genuinely good and the ones that get banned just reappear on personal accounts where nobody can see them at all. But five questions, asked before the click, will keep you out of most of the trouble.

What “Sign in with Microsoft” Actually Does

Behind that button is OAuth, and the important thing to understand about it is that it produces a token the vendor keeps. Unlike a password, that token is refreshed automatically in the background, so access continues without anyone logging in again. A password reset is not the remedy — the grant survives it, and revoking the app’s consent is what actually cuts the access. In many cases the grant survives multi-factor authentication prompts too, because the trust was granted once, up front, on the consent screen.

What varies enormously is what the token is good for. Some apps ask only to read your name and email address, which is fine. Others ask to read and send mail on your behalf, to read all files you have access to, or — if an administrator clicks the button — to read data across the entire organization. All of those requests look about the same on screen: a list of bullet points and a blue Accept button.

Attackers know this. Consent phishing is now a standard technique: a convincing email leads to a real Microsoft login page and a real consent screen for a malicious app with an innocuous name, and the victim approves it. No password is stolen, so a password reset fixes nothing. It is a variation on the same theme we covered in why attackers target small business email, and the defense is the same one: pay attention to what you are approving.

Question 1: What Data Does It Touch?

Read the permission list on the consent screen, not the marketing page. The phrasing is dull but precise, and the words that should make you stop are all, on your behalf, read and write, and without a signed-in user. A meeting transcription tool that wants to read your calendar is asking for something proportionate. The same tool asking to read and send mail is not.

Then ask the human version of the question: what would be in there? For a hospice, a clinic, or a billing office, “read all files you have access to” may mean patient information — and if a vendor stores or processes protected health information on your behalf, you need a Business Associate Agreement with them before they touch it, not after. That is a hard stop, not a preference.

The proportionality test is simple. If the permissions requested are broader than the job the app is doing, that is the whole finding. Plenty of well-built products request narrow, specific scopes; a product asking for everything is telling you how it was built.

Question 2: Who at the Vendor Can See It?

Every SaaS vendor’s support team can see more than customers assume, and that is not sinister — it is how support works. What you want to know is whether it is controlled. Reasonable answers sound like: access is limited to named staff, it requires approval and is logged, it is time-limited, and personnel are background-checked and trained. Unreasonable answers sound like a pause.

Two follow-ups worth asking. Where is the data hosted, and does the vendor use subprocessors — the other companies they hand your data to for hosting, analytics, or support? A good vendor publishes a subprocessor list on their website. And if the product includes AI features, ask directly whether your content is used to train models, whether that is on by default, and how to turn it off. Get the answer in writing rather than from a chat widget.

Question 3: Do They Have a Current SOC 2 Type II Report?

This is the one question that separates vendors who have done the work from vendors who have a nice website.

SOC 2 is an attestation report, not a certification. An independent CPA firm examines the vendor’s controls and issues a report with an opinion. Nobody hands out a SOC 2 certificate, and a vendor who says they are “SOC 2 certified” is telling you something about how closely they read their own report. Ask for a current SOC 2 Type II report. Type I describes controls at a single point in time — a photograph. Type II tests whether those controls actually operated over a period, usually somewhere between three months and a year — a video. Type II is the one worth having.

You will normally sign a non-disclosure agreement to receive it, which is fine and expected. Then read three things, in this order: the scope, to confirm the report covers the actual product and environment you are buying rather than a sibling service; the period covered, and whether there is a bridge letter covering the months since it ended; and the exceptions, which is where the auditor lists what did not work as described. A report with a few noted exceptions and clear management responses is more reassuring than a spotless one with a narrow scope.

Not every small vendor will have one, and that alone is not disqualifying for a low-risk tool. It becomes disqualifying in proportion to what the app can reach. No SOC 2 and read access to all your mail is a no.

Question 4: What Happens to Your Data If You Leave?

Settle this before you sign, because your leverage disappears the moment you give notice. Four specifics:

• Can you export everything yourself, without asking the vendor to run it for you, and in what format? An export that is really a PDF of a report is not your data in any usable sense.
• How long does the account stay accessible after you cancel, and does it become read-only or simply vanish at renewal?
• How long does the vendor keep your data afterwards, including in backups, and will they confirm deletion in writing?
• What happens if they are acquired or shut down? Small SaaS companies change hands routinely and the new owner’s policies come with them.

Then do the thing almost nobody does: run the export in the first month, while you still care, and file it. That single test tells you more than any answer in a sales call.

Question 5: Who at Your Company Owns the Account?

The most common failure I see is not a breach. It is a subscription in a former employee’s name, tied to their personal phone for MFA, billed to a card that expired, holding data the business needs and nobody can reach.

Every application needs a named internal owner — and the account of record should be a shared, company-controlled mailbox rather than one person’s address, with the credential in the company password manager and billing on a company card. Write down who the owner is, who the backup is, and what the renewal date is. When that person leaves, the app goes on the offboarding list, which is precisely where these things get missed.

How to Review Third-Party App Consents in Microsoft 365

You can see exactly what has already been approved in your tenant. Menu names move around, so treat these as directions rather than a map:

• See what is connected. In the Microsoft Entra admin center, go to Identity → Applications → Enterprise applications. This is the list of every third-party app with a foothold in your tenant. Open one and look at Permissions to see what it was granted, and whether the grant was made by a single user or on behalf of the whole organization.
• Revoke what you do not recognize. Deleting the enterprise application, or removing the permission grant, cuts off the access, though a token already issued can remain valid for up to an hour. Do this for anything tied to a departed employee, anything nobody can identify, and any trial that ended years ago.
• Control who can approve new ones. Under Enterprise applications → Consent and permissions, you can restrict user consent to apps from verified publishers requesting low-risk permissions, and turn on the admin consent workflow so anything larger becomes a request that lands with a named reviewer. This is the setting that matters most, and it is off by default in a lot of tenants.
• Check individual accounts too. Users can review and revoke their own app permissions from their account’s privacy settings at myaccount.microsoft.com. Worth walking staff through once.
• Watch for new grants. Consent events are recorded in the audit log, and unusual consent activity is one of the signals worth alerting on. If Google Workspace is your platform instead, the equivalent lives under app access control in the admin console — the concepts translate directly, as we noted comparing Microsoft 365 and Google Workspace.

A Policy a 20-Person Office Can Actually Follow

One paragraph, not a manual: Any application that connects to company email, files, or calendars is requested through the office manager before it is connected. Requests get a decision within two business days. Every approved app has a named owner, a company-controlled account, and its credential in the password manager. Twice a year we review the connected app list and remove what is no longer used.

That is it. It is enough to catch the genuinely bad ideas, fast enough that people do not route around it, and it produces the one artifact you will want later: a list of every vendor with a key to your building.

Related Questions