What the first thirty minutes of Microsoft 365 monitoring actually look like

01 / 11

Consider a 35-person law firm with one admin password

Consider a fictional 35-person law firm, the kind with one partner who has held the Microsoft 365 admin password since the firm's first tenant was set up a decade ago, and an outsourced IT contractor who handles the servers, the printers and the occasional locked-out associate. The partner is weighing a read-only monitoring service and has one real question, and it is not about price: how much of somebody's day does turning this on actually cost.

The honest answer is that it is mostly a reading exercise, done once, by one person, and it does not take a day. What it does take is the right person doing the right fifteen minutes of it, and working out who that person is turns out to be less obvious than it looks.

02 / 11

The role that actually has to click

Microsoft 365 monitoring of this kind runs through a Microsoft Entra application registration: a piece of software the vendor built, registered with Microsoft, and made available for any tenant to connect to. Connecting it requires exactly one deliberate action from your side, called tenant-wide admin consent. Someone holding the right role reviews the permissions the application is requesting and grants them once, for the whole organisation.

Who that someone has to be is where most admins' assumptions turn out to be wrong, and it is wrong in a specific, checkable direction.

03 / 11

Why Global Administrator is not the answer Microsoft gives

Microsoft's own documentation on granting tenant-wide admin consent lists exactly four ways to qualify. A Privileged Role Administrator can consent to an app requesting any permission, for any API. A Cloud Application Administrator, an AI Administrator, or an Application Administrator can also consent to an app requesting any permission for any API, except Microsoft Graph app roles -- known outside the documentation as application permissions. The fourth path is a custom directory role built specifically to include that consent permission.

Read that exception again, because it is the detail that decides everything here. A read-only monitoring app that asks for Read.All application scopes is asking for Microsoft Graph application permissions -- exactly the category three of the four named roles are carved out of. For an app in that category, Microsoft's own list narrows to Privileged Role Administrator, or a custom role purpose-built for it.

Global Administrator does not appear on that list at all. We checked the full page for the exact phrase and it is not there. In our reading, a Global Administrator can still do it in practice -- the role's own description is manage all aspects of Microsoft Entra ID, about as broad as a role gets -- but that is our inference, not a sentence Microsoft wrote about this specific screen.

This matters for the law firm above in a concrete way. If the outsourced contractor has been handed Application Administrator, a common and sensibly scoped role for day-to-day app management, they cannot personally grant this consent -- not because anyone withheld it, but because that role is explicitly excluded from consenting to Graph application permissions. The partner, or whoever holds Privileged Role Administrator, has to be the one who clicks.

04 / 11

What the consent screen is actually asking

Practically, the flow is Microsoft's own admin-consent endpoint, not anything the vendor built. The address is a Microsoft one: login.microsoftonline.com, then your tenant ID, then v2.0/adminconsent, followed by the application's client ID and the exact permissions requested. Microsoft Entra ID requires a qualifying administrator to sign in there before anything is granted.

What loads next is a screen listing every requested permission, one line per scope, nothing else. No tenant data appears yet, because nothing has been read yet. The administrator's job is to read the list line by line and decide whether each one is something a read-only security tool has a legitimate reason to ask for.

If the administrator approves, Microsoft's response returns the tenant ID, the exact set of scopes granted, and a flag confirming consent was given. That response is the whole transaction. There is no second step, no follow-up call, and no software that arrives afterward.

05 / 11

What tenant-wide consent grants, and does not grant

Tenant-wide admin consent answers one question only: is this application allowed to read the data in the scopes it requested. It does not, by itself, decide who inside the organisation can open the application or sign into it.

Microsoft states it plainly: by default, granting tenant-wide admin consent to an application allows all users to access the application unless otherwise restricted, and access can be narrowed afterward by requiring user assignment. For a monitoring tool nobody but the partner and the contractor will ever sign into, this rarely changes anything in practice -- but consent and access are two separate settings.

One more detail worth flagging before the click, not after: Microsoft's own documentation warns that granting tenant-wide admin consent may revoke permissions that have already been granted tenant-wide for that application, though permissions users granted on their own behalf are unaffected. For a first-time consent this changes nothing; it matters the next time the application's permission list changes and needs re-consenting.

06 / 11

The thirty minutes, minute by minute

Laid out as a timeline, with the roles from above doing the actual clicking, the first half hour looks like this.

07 / 11

Nothing installed, and what that changes

The single biggest source of confusion in that timeline is the assumption that after consent, something still has to be deployed -- an agent, a scanning appliance, a piece of software waiting for the next patch cycle. There isn't one. The application reads the tenant through Microsoft Graph and, where Azure is in scope, through Azure's own resource management APIs -- both server to server, both nothing a device on anyone's desk ever sees or runs.

That is also what the Azure side of the same consent step is limited to. Microsoft's own role descriptions are blunt about it. Reader: view all resources, but does not allow you to make any changes. Security Reader: view permissions for Microsoft Defender for Cloud. Can view recommendations, alerts, a security policy, and security states, but cannot make changes. Cost Management Reader: can view cost data and configuration (e.g. budgets, exports). Three roles, three slices of read access, no write action named in any of them.

Because there is nothing to install, there is nothing to wait for either. The first scheduled read can run against the whole tenant as soon as consent exists -- there is no queue of devices that each need to check in first. That is our reading of the architecture, not a marketing promise about speed.

08 / 11

What to check afterward

A named administrator having clicked something once, unsupervised, is a reasonable thing to want to verify -- and Microsoft gives you a way to do it that has nothing to do with trusting the vendor's word for it.

In the Microsoft Entra admin center, under Enterprise applications, the app now appears in the list of all applications. Opening it and selecting Permissions, under Security, shows two tabs: Admin consent, for what was granted to the whole organisation, and User consent, for anything granted by individual users on their own. Selecting any permission in that list opens its own detail pane.

• Confirm the Admin consent tab lists only the scopes reviewed before clicking, nothing more.
• Open a permission's detail pane and check it names a read scope, not a write or full-access one.
• If Azure was included, check the IAM role assignments blade for exactly the Reader roles expected.
• Note who is recorded as having granted consent and when -- that is now part of your own change record, not just the vendor's claim.

09 / 11

What comes back, and what does not

What the customer gets back, once the first read completes, is a dashboard drawing on the same Graph and Azure scopes just granted -- Secure Score and its improvement actions, Defender alerts, identity risk, device compliance, licence assignment, and whatever else the granted scopes cover. Every area carries an explicit status of its own -- Healthy, Not licensed, Permission required, or Auth error -- rather than a blank chart standing in for one.

What does not come back is any change to the tenant. A read-only integration cannot reset a password, disable an account, or flip a Conditional Access policy, because it was never granted the scope to do any of those things. It can point at the exact screen where that change would be made, and flag that the change looks overdue. The doing stays with whoever holds the write access -- in this scenario, still the partner and the contractor, exactly as before onboarding.

That trade-off is the point of reading the permission list carefully in the first place. Consent narrow enough to verify is also narrow enough that nothing surprising happens with it later.

10 / 11

Back to the partner with the admin password

Back to the law firm. The realistic version of this story is that the partner spends under thirty minutes -- reading a permission screen, clicking once, checking Enterprise applications afterward -- and the outsourced contractor is not part of that half hour at all, because Application Administrator, the role contractors are commonly given, does not reach this specific button for a Graph-application-permissions app.

That is worth raising with a contractor before onboarding day: ask which Entra role they hold, and whether it is Privileged Role Administrator or something narrower. If narrower, the partner, or whoever else holds that role, has to be in the room for those thirty minutes -- worth knowing going in rather than discovering it mid-onboarding.

11 / 11

Where to start

Before onboarding anything, open Microsoft Entra ID and check Roles and administrators for Privileged Role Administrator to see who actually holds it today. That is a five-minute look, it costs nothing, and it answers the scheduling question that matters most.

Disclosure: this is a category we sell into. Avalon CloudSec is a read-only Microsoft 365 and Azure monitoring service operated by Avalon Web Services LLC, connected through the same tenant-wide admin consent process described above -- every Microsoft Graph permission it requests is a Read.All application permission, and its Azure access is limited to the Reader, Security Reader and Cost Management Reader roles covered here. Onboarding is this admin-consent flow, nothing is installed on any device, and first data typically appears the same day. One honest limitation: because it is read-only by architecture, it cannot fix anything it finds -- every change it surfaces still has to be made by your own team, in Microsoft's own screens. Questions about which role you would actually need for this step can go to support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.