Changing or removing the Microsoft 365 connection

Four things people want to do to an existing Microsoft 365 connection: add a permission it was missing, find out what it currently has, stop it temporarily, and remove it for good. They have quite different consequences and only one of them deletes anything, so it is worth knowing which is which before you start.

One fact underpins all four, and if you take nothing else from this article take this: the permissions live on the app registration in your own tenant, not on the connection record in Qorionix. We store your directory identifier, your application identifier and an encrypted client secret. We store no permission state at all. Every time we ask Microsoft for a token we ask for whatever that app registration currently holds, and Microsoft resolves the answer afresh.

Adding a permission after the fact

This is the most common change, usually because a coverage gap in your report named a dataset we were not allowed to read. The procedure is entirely in your tenant.

1. 1

   Find the permission the gap needs

   Every permission is tied to a named Graph call and to the specific checks that depend on it in Every permission we ask for, and why. Match the dataset named in the gap — mailbox rules, sign-in logs, application consents — to its row.

2. 2

   Add it as an application permission, not a delegated one

   In the Microsoft Entra admin centre, open your Qorionix app registration and go to API permissions → Add a permission → Microsoft Graph → Application permissions. A delegated permission describes what an app may do on behalf of a signed-in user, and there is no signed-in user in this flow, so a delegated grant is never exercised.

3. 3

   Grant admin consent

   Adding the permission requests it; granting consent is what makes it effective, and the status column on that page says which state each one is in. It is recorded in your own tenant's audit log with your name against it.

4. 4

   Change nothing in Qorionix

   There is genuinely nothing to reconfigure. The connection record holds identifiers and a secret; it does not hold a list of permissions. Our next token request asks Microsoft for whatever the registration now holds, so the new permission is in force from the next token onward without any action on this side.

The same applies to the throttling gap, which says We will retry automatically. No action needed. Within a single run we do back off and retry; across runs, nothing reschedules. If a run finished with throttling gaps, start another one when your tenant is quieter — a second run started while one is still in flight is refused rather than queued, so wait for the first to finish.

Checking what is currently granted

The honest answer is that Qorionix cannot tell you, and the reason is the design decision at the top of this article. Because permission state is never persisted on our side, we have no inventory to show you. What we have is evidence of what worked and what did not.

The distinction between the second and third rows is worth internalising. A connection can report healthy while several checks in your report are skipped for want of a permission, because the health probe only exercises one of them. Health tells you the connection is alive; the coverage gaps tell you how much of your estate it could actually see. See When a check cannot run for the five classified causes and what each one asks of you.

Stopping the connection without removing it

If you want assessments to stop but do not want to rebuild the connection later — during a migration, an audit, or a change freeze — switch the integration off rather than deleting it. The stored credential and the configuration stay where they are, and a posture run attempted against it is refused:

This is reversible in one click and costs nothing. It is the right choice in almost every case where the answer is not right now rather than never again.

Deleting the connection for good

Deleting the connection record removes our ability to reach your tenant and destroys the credential we held. It is not the same act as withdrawing consent, and confusing the two is the mistake this section exists to prevent.

Doing only your own side is the stronger of the two halves, and it is entirely in your gift: removing consent removes our access on the next token, without our involvement. That is a deliberate property of doing the setup the long way round rather than through a pre-filled consent link.

What you will see if consent is withdrawn

If somebody removes the consent or deletes the secret without telling you, the failure is loud rather than silent. The health check moves the connection to degraded or unreachable within fifteen minutes, and a posture run started afterwards is refused before the run row is even created. If you attempt to undo a previously applied change while access is gone, the platform says so exactly:

Microsoft 365 is refusing our sign-in, which almost always means the
permission you granted Qorionix has been withdrawn or the app
registration changed. We have not changed anything. Re-grant consent
and try again, or use the manual steps below.

The sentence We have not changed anything is the load-bearing part. A failed undo that leaves you unsure whether the change was half-applied is worse than a refused one, so the platform reports a clean refusal and offers the manual steps rather than guessing.

Rebuilding a connection you removed

There is no penalty for reconnecting. Create the app registration again — or reuse the one you kept — grant the permissions, generate a secret and paste the three values back in. Your historical runs are still there and the new runs sit alongside them.

One thing to avoid: ending up with two enabled Microsoft 365 connections. We refuse to guess between them, because discovering the wrong estate produces a report about the wrong company and no amount of later correction undoes the customer having read it.

If you are supplying configuration through the API rather than the form, one further refusal is worth knowing, because the cause is not obvious from the symptom: a field supplied both as ordinary configuration and as a credential is rejected outright with field "…" is present in both the configuration and the credentials of this Microsoft 365 connection; remove it from one of them. Two sources for the same value is how a stale secret gets used in preference to the current one.

A note on retention

Your licence carries a retention period — 30, 90, 365 or 730 days by tier — and people assume it governs more than it does. It is applied as a floor on how far back a log search may reach: a query for an older window is clamped to the period rather than refused. It does not govern your posture reports, and it has no relationship to how long Microsoft keeps data in your own tenant. Disconnecting changes none of it.

What to do next

1. Every permission we ask for, and why — the table to consult before adding or removing anything.
2. When a check cannot run — the five classified causes of a coverage gap, and which two are yours to act on.
3. Connect Microsoft 365 — the full setup procedure, including rotating the client secret before it expires.