An application can read everyone's email

Most findings in your report describe a way somebody could get in. This one describes something that is already inside, holding a key you gave it, and reading mail across the whole organisation right now.

Depending on how many applications are involved, the report opens with either "An outside application can read everyone's email in your business" or "4 outside applications can read everyone's email in your business", followed by their names. If you recognise all of them and you know why each has that access, this finding takes you five minutes. If you do not recognise one, stop reading and look at that one.

The finding as the product records it

Consent phishing: nothing is stolen, it is granted

This is the attack the whole application category exists for, and it is worth understanding properly because every instinct built up around passwords fails against it.

The victim receives a link. The page it opens is a genuine Microsoft sign-in and consent page, on a genuine Microsoft domain, with a genuine certificate. It is not a fake. What it asks for is not a password — the victim may already be signed in — but a click on Accept next to a list of permissions requested by an application with a plausible name and a plausible logo.

The victim accepts. Nothing has been stolen, so nothing looks wrong. There is no impossible-travel sign-in to alert on, no failed password attempts, no new device. There is a new application in the tenant with standing permission to read mail, and it will use that permission from the attacker's own infrastructure using the application's identity rather than the victim's.

It also does not expire on its own, it survives every staff change, there is no phone to lose, and there is no leaver process that catches it. An application permission is access that nobody watches.

What the check actually looked at

The check reads the consent grants in your tenant and keeps only those that are tenant-wide — granted on behalf of everyone in the business rather than by one individual for their own mailbox. Of those, it keeps the ones holding at least one high-risk permission relating to mail. Each surviving application is named as a subject, and the exact permission list it holds is recorded as a fact alongside it, so the report shows you what each one can reach rather than a category label.

The check needs to be able to read application consents. If it cannot, ZQ-M365-APP-007 fires at info level and states plainly that this section has not been assessed and that consent-phishing findings would not have been detected. That is the honest outcome; it is never reported as a pass. See When a check cannot run.

The permissions we treat as high-risk

Not every permission an application asks for matters. These families do, because each one reaches company data across the organisation or changes who can do what. They are grouped below by what an attacker gets from them.

ZQ-M365-APP-001 is specifically the mail story, because it is the sharpest one to tell. Applications holding the other families tenant-wide are reported by ZQ-M365-APP-002 instead, so you do not read the same application described twice in different words.

The change, and why it asks first

The generated change is revoke_app_consent, and it sits in the approve pile. It is reversible and its reversal path is recorded, but it is marked disruptive, and the classifier keeps anything disruptive out of the pile that gets applied without asking.

That caution is not theatre. Tenant-wide mail access is exactly what a legitimate mail archiving product, a shared-inbox helpdesk, a CRM that logs correspondence, or a signature-management tool needs in order to work. Revoking the wrong one on a Tuesday morning stops your support queue. So the platform tells you what each application can reach, and you tell it which to withdraw.

The recorded reversal path reads: "Re-grant the same permissions in one tap; we record the exact scope list before withdrawing it." The second half of that sentence is the part that makes the first half true — the permission list is captured before anything is removed, so restoring means restoring exactly what was there rather than approximately what somebody remembers.

How to work through the list

Take the applications one at a time. For each one, you are answering two questions: do I know what this is, and does it need access to everybody's mail rather than one mailbox.

1. 1

   Start with anything you do not recognise

   An unrecognised application with tenant-wide mail access is the single most urgent item in your report. Do not spend time working out what it might be. Withdraw the access, then investigate — restoring it takes one tap and the exact permission list is kept.

2. 2

   Check the publisher on the ones you do recognise

   Attackers register applications with names resembling well-known tools, and an unverified publisher is the clearest available signal that an application is not what its name suggests. ZQ-M365-APP-004 lists these separately at medium severity. Verification is straightforward for a genuine software company, so its absence on an application with real access is worth a question.

3. 3

   Ask who approved each one, and when

   If your audit log was switched on, this is answerable. If it was not, that is why enable_unified_audit_log is on the short list of things the platform turns on for you without asking — an incident nobody can reconstruct is an incident nobody can answer questions about.

4. 4

   For the legitimate ones, reduce rather than remove

   A tool that only needs to read one shared mailbox does not need tenant-wide mail access. Most vendors document a narrower permission set and would rather you used it. This is slower than revoking, and it is the change that actually lowers your exposure without costing you a working tool.

5. 5

   Check what else these applications can do

   ZQ-M365-APP-005 flags applications that can send mail as your staff, and ZQ-M365-APP-006 flags applications that can write to your directory. An application appearing in more than one of these findings deserves the same scrutiny you would give a new administrator.

Stopping it happening again

Withdrawing today's grants does nothing about next month's. The durable fix is to require administrator approval before staff can grant applications access to company data, which is the change restrict_user_consent generated by ZQ-M365-APP-003.

It is worth being clear about what that does to your people, because the report is: staff who try to add an application are asked to request approval rather than being blocked outright. They can still get the tool they want; somebody looks first. That change is marked disruptive with a blast radius of everyone enabled in your tenant, which is why it asks rather than acting.

One last note on ZQ-M365-APP-006. An application that can write to your directory can create itself a new administrator account, which is a complete tenant takeover from a single leaked application secret — and application secrets leak into source control, build logs and laptops routinely. The change offered there is rotate_service_principal_credential rather than revocation, because rotation keeps the tool working. The previous secret stays valid for 24 hours so reverting is immediate within that window, and if the secret is configured somewhere by hand it will need updating there too, which is why that one asks first as well.

For how the piles are decided and enforced, see Done, approve, decide. For the permissions Qorionix itself asks of your tenant — and why each one is read-only where it can be — see The permissions we request.