What Permissions Does a Read-Only Microsoft 365 Audit App Ask For, and Why?

The short version: A read-only Microsoft 365 audit app asks for Microsoft Graph application permissions that end in .Read or .Read.All, never ReadWrite, so it can read configuration but not change it. Only a Global Administrator or Privileged Role Administrator can consent, and you can see exactly what was granted in Entra and remove it afterwards. This guide explains how to read that list, which permissions should make you stop, and what to ask any provider before you click Accept.

If you have been asked to approve a security audit, the consent screen is the moment most administrators hesitate. A read-only Microsoft 365 audit app with Graph permissions sounds safe, but the screen lists a string of technical names and asks you to grant them for your whole organisation. It is reasonable to want to know what you are agreeing to.

This guide is written for the person holding the Global Administrator account. It explains what "read-only" means in Microsoft Graph, why an audit app needs application permissions rather than a signed-in user, which permissions to question, and how to check and remove access yourself. It also says what Brocent's own audit app does. The documentation points below were checked against Microsoft Learn on 4 November 2026.

What does "read-only" mean for a Microsoft 365 audit app?

In Microsoft Graph, "read-only" is not a marketing claim; it is part of the permission name. Microsoft's documentation describes a naming pattern of resource, operation and constraint, written Resource.Operation.Constraint. The operation Read allows read operations only, while ReadWrite allows read, create, update and delete. The constraint All means the permission applies across the whole directory, not just to data the app owns.

So Policy.Read.All reads policies across the tenant, and Policy.ReadWrite.ConditionalAccess would be able to change them. An app that only ever needs to look should only hold permissions whose operation is Read or ReadBasic.

Two points follow from that.

• Read-only is about operations, not about sensitivity. A permission can be read-only and still expose a lot. Microsoft itself describes Directory.Read.All as the highest-privileged read-only permission for Entra ID resources. A configuration audit often does need broad read access to the directory, because the thing being audited is the whole tenant.
• Read-only is not the same as "narrow". The useful question is not only "can it write?" but also "what can it read?". Reading the configuration of your Conditional Access policies is very different from reading the contents of your mailboxes.

Why does an audit app need application permissions instead of a user sign-in?

Graph has two access models. In *delegated* access, the app acts on behalf of a signed-in user and can only reach what that user can reach. In *app-only* access, the app uses its own identity with no user present, and the permissions are called *application permissions* or app roles.

An audit that has to read the settings of many parts of a tenant in one pass is normally built as an app-only tool, for three practical reasons.

1. It needs a consistent view. A delegated tool sees whatever the person running it can see. Different administrators see different things, so results would depend on who signed in.
2. It runs without a person watching. Collecting configuration across Entra ID, Exchange Online, SharePoint and the rest takes many calls, and the report should not depend on an administrator keeping a session open.
3. It can be revoked cleanly. Because the access belongs to the app's identity, you remove the app and the access goes with it. You do not have to untangle which user tokens are still active.

Microsoft is direct about the trade-off: application permissions are highly privileged because they allow an app to access resources without a signed-in user, and from a least-privilege perspective delegated permissions are the recommended model wherever they meet the need. That is exactly why consent for application permissions is restricted. Per Microsoft, only a Privileged Role Administrator or a Global Administrator can consent to them.

This is also why you should not let a provider talk you into a vague answer. If an app is going to hold app-only access to your tenant, you are entitled to know the exact list.

What does Brocent's audit app do, and what does it never read?

Brocent's Microsoft 365 audit uses a read-only Microsoft Graph app. It is consented once by a Global Administrator, which takes about 15 minutes, and it can be removed again in Entra ID at any time. It reads configuration. It never reads mail or document content.

That last sentence is the design boundary, so it is worth being precise about what it means in practice:

• What the audit looks at: how your tenant is set up, including identity and sign-in settings in Entra ID, protection settings in Defender, retention and labelling settings in Purview, mail flow and authentication settings in Exchange Online, sharing settings in SharePoint, and meeting and external-access settings in Teams.
• What the audit does not touch: the text of your emails, the contents of your files, or chat messages. Configuration tells us whether external forwarding is blocked; it does not require us to read anyone's forwarded mail.
• What you get back: a report that measures those settings against the CIS Microsoft 365 Benchmark at Level 1 and Level 2, including the manual controls, with a prioritised roadmap and effort estimates. The scope is the same in every price band; the price depends only on headcount. See the Microsoft 365 Security Audit pricing page for the current list.

We do not paste a permission list into this article, because a list that is correct today can be out of date after the next change to the app. Instead, ask any provider, Brocent included, for the exact list in writing before anyone clicks Accept, and check it against the next two sections. A provider who cannot produce it has told you something.

Which Graph permissions should make you stop and ask?

Use these as a quick screen when you receive a permission list. None of them is automatically wrong for every product, but none belongs in a *read-only configuration audit* without a clear explanation.

• Anything ending in ReadWrite, Manage, Create, Send or FullControl. A review does not need to change, create or send anything. If it does, you are buying a remediation tool, not an audit. One common exception to ask about is Exchange.ManageAsApp, which Microsoft's documentation uses for app-only access to Exchange Online PowerShell; what the app can do with it is set by the Entra role assigned to the app (for example Global Reader), so ask which role it holds.
• Content permissions such as mail, files and chat reads. Microsoft's own example is that an application holding the Files.Read.All application permission can read any file in the organisation. The same pattern applies to the equivalent mail and chat permissions. A tool that needs these is reading your data, not auditing your configuration.
• A permission that lets the app grant itself or others more access. Permissions that manage application registrations, role assignments or consent grants can be used to escalate. They should not appear on a read-only list at all.
• A very long list with no explanation. Microsoft's guidance is to grant the minimum permission needed for the operation. Ask for each permission to be matched to the report section that uses it.
• Delegated permissions requesting offline access for a tool that is described as one-off. A one-off review should not leave a standing refresh token behind.

If you see something unexpected, the correct response is a question, not an automatic refusal. Sometimes a permission has a legitimate, narrow purpose that the name does not make obvious. The test is whether the provider can explain it in one sentence that you can verify.

How do you check what an app was actually granted?

You do not have to rely on the provider's description. After consent, the grant is visible in your own tenant. Per Microsoft's documentation, to review the permissions granted to an application:

1. Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator.
2. Go to Entra ID, then Enterprise apps, then All applications.
3. Select the audit application.
4. Select Permissions.
5. Open the Admin consent tab to see what has been granted for your whole organisation. Select any entry to see its details.

Compare that list with what you were told before you consented. They should match. Keep a screenshot or export with the date; it is useful evidence of what you approved and when, and an internal reviewer or insurer may ask for it later.

For a deeper check, the same page of the documentation shows how to list an app's application permissions through Microsoft Graph, using the service principal's app role assignments. That is how you would script a recurring review of every third-party app in the tenant, which is a good habit regardless of audits.

How do you remove the audit app's access afterwards?

Because an audit is a point-in-time review, access should end when the work does. You have two clean options:

• Revoke the permissions. In the same Admin consent tab, choose a permission, open the actions menu and select Revoke permission. Microsoft notes that revoking a granted permission does not stop users from consenting to it again if the app still requests it, so this works best when the app is also no longer in use.
• Delete the enterprise application. Removing the app's enterprise application entry in Entra ID removes the identity that held the access. This is the simplest way to be certain nothing remains.

After removal, check two things. First, look at the sign-in logs for service principal sign-ins from that app, to confirm it is no longer authenticating. Second, confirm that user consent settings still prevent staff from approving apps on their own, so the app cannot quietly return through another route.

What can a read-only app not tell you?

It is worth being honest about the limits, because they shape what a provider should do besides running the app.

• Some controls cannot be read through an API. The CIS Microsoft 365 Benchmark includes manual controls, such as how break-glass accounts are held and used, or decisions that exist in policy documents rather than in settings. A good audit covers those through a short conversation with your administrator, not by guessing.
• Settings are a snapshot. The report describes your tenant on the day it was read. A change the following week is not in it, which is one reason some organisations re-audit quarterly.
• A setting being on does not mean it is right for your business. The report flags gaps against a baseline and ranks them by risk and effort. Deciding what to fix first is a judgement, and that is what the debrief call is for.

None of this is a weakness of the read-only approach. It is the reason the deliverable is a report with a person's interpretation, not a raw export.

Questions to ask any provider before you consent

Copy these into an email to every provider on your shortlist.

• Which Microsoft Graph permissions will the app request, listed by exact name?
• Are any of them ReadWrite, or able to read mail, files or chat content? If so, why?
• Is the access application-only or delegated, and does it use any standing refresh token?
• Who will hold the credentials for the app, and how are they stored?
• How do I see and revoke what you were granted, and how long does removal take?
• What does the report cover that the app cannot read, and how will you collect it?
• If we stop working together, what happens to the app and any data you collected?

A provider who answers these quickly and specifically is far easier to trust than one who tells you the app is "safe" and moves on.

Frequently asked questions

Is it safe to give a Microsoft 365 audit app access to my tenant?

It is as safe as the permission list and the provider's handling of the data. A configuration-only, read-only app, consented by your own Global Administrator, visible in Entra and removable at any time, carries far less risk than a tool that can write or read content. Ask for the exact list first and verify it after consent.

Who can approve an audit app's application permissions?

Per Microsoft's documentation, only a Privileged Role Administrator or a Global Administrator can consent to application permissions. The same documentation says a Cloud Application Administrator or Application Administrator can review and revoke what has been granted.

Does a read-only audit app read my email or documents?

It should not. A configuration audit checks settings such as forwarding rules being blocked, not the content of messages. Brocent's audit app reads configuration only and never reads mail or document content. If any provider's list includes mail, file or chat read permissions, treat that as a reason to ask why.

Can the audit app change anything in my tenant?

Not if it holds only read permissions. Permissions ending in ReadWrite are the ones that can change data. Check the Admin consent tab after approval to confirm there are none.

How long does consent take, and can I undo it?

For Brocent's audit, the one-off consent by a Global Administrator takes about 15 minutes. You can remove the app in Entra ID whenever you like. After removal, the access ends because the identity that held it is gone.

Will this audit make us compliant or certified?

No. The report and workbook are designed to be used as evidence for common cyber-insurance questionnaire and Cyber Essentials questions. They do not grant or guarantee certification, and what an insurer or assessor accepts is their decision.

Next steps

Write down your headcount, ask each provider for the exact permission list in writing, and check it against the screen in this guide before you consent. If Brocent is on your shortlist, the Microsoft 365 Security Audit pricing page shows the fixed price for your size, from US$450 for 1–10 users, one-time and excluding tax, with the report delivered 5–7 business days after read-only access is granted. The sample report (English page) shows what the output looks like.

For more context, read how the cost is built up in how much a Microsoft 365 security audit costs, what the review covers in the Microsoft 365 security audit checklist, and how the evidence maps to insurer questions in our guide to the cyber insurance questionnaire. If you would rather talk it through, contact us.