Imagine your team stopped using a meeting tool months ago. Nobody pays for it now, but someone once clicked “Accept” when it asked to read their calendar. Has that access actually ended?
It’s easy to forget about an app once you stop using it. When you review Microsoft 365 security, check which software can use your data as well as which people can sign in.
This guide is for business owners working with an authorised Microsoft 365 administrator or IT provider. You can help establish which tools the business still needs. Let someone who understands the service handle changes to its permissions.
Understand what the app was allowed to do
Microsoft describes two types of permission. Delegated permissions let an application act on a user’s behalf, within the access allowed to both. Application permissions let it operate as its own identity without a signed-in user.
That means a background integration won’t necessarily stop when the person who introduced it leaves the business. An administrator may have granted permissions for a task that still runs automatically.
You’ll also come across the term “administrator consent”. This describes who approved the access. It isn’t another name for application permissions, because an administrator can approve delegated permissions for users too. Microsoft’s consent guidance explains the difference. Ask your IT provider to record both the permission type and who it applies to.
Ask them to translate the technical names into plain language. Reading calendar entries, sending mail and reading files give an app quite different abilities. You need to know whether it needs that access to do its job.
Make a list of the apps and their owners
Ask your administrator to review the enterprise applications in Microsoft Entra and the permissions granted to them. Microsoft’s review procedure includes separate views for admin consent and user consent.
For each relevant application, record:
- its name, identifier and publisher
- the team and named person responsible for it
- the job it does for the business
- its permissions and the people or resources affected
- the date and outcome of your review
- whether you’ll keep, reduce, investigate or remove its access
Add information about recent activity where your tools provide it. A lack of visible activity doesn’t prove an app is unused. Your logs may not cover enough time, or it could run a job that’s only needed occasionally.
Start with applications that can access sensitive files, read mail, send messages or make changes across the organisation. Remember tools introduced for a short trial and integrations set up by people who’ve since left.
Ask the owner to justify the permission
Ask each owner whether the team still uses the application. If they do, find out what data it needs and whether its access can be reduced.
Suppose a sales team uses a calendar tool to arrange appointments. Calendar access may fit that task, but permission to read all the user’s files needs an explanation. If the answer is simply “the app needs it”, check the supplier’s documentation and settings to find out why.
Some tools have a good reason to need broad access. Backup and automation tools may operate without a signed-in user, as Microsoft’s permissions overview explains. Record why they need the access and who will review it again.
If nobody recognises an application, give someone the job of finding out what it does. An unfamiliar display name doesn’t prove it’s malicious. It does leave you with a question to resolve before you can decide whether to keep it.
Remove access through the correct controls
Plan routine removals with the team that uses the application. It might run an overnight export, update customer records or support another process that people rely on. Record the change and test that process afterwards.
Your administrator will need to choose the right control for the permission involved. Microsoft documents portal controls for revoking admin consent, while user-consent grants may require Microsoft Graph or PowerShell in the administrator workflow. Follow the current permission review and revocation instructions. There isn’t one remove button that handles every kind of grant.
Removing an app icon from somebody’s desktop doesn’t show that its cloud permissions have ended. A password reset doesn’t replace an app-permission review either. Ask your administrator to check the actual grants and record what was removed.
If access looks suspicious, involve your IT responder straight away. Microsoft’s app-consent investigation guide explains how attackers can misuse consent to maintain access and gives investigation and recovery steps. Your responder should preserve the relevant records and contain the access promptly. Don’t leave it until the next scheduled review.
Give new applications an approval route
Microsoft’s user-consent settings let administrators control when users can approve applications and which policies apply. Ask IT to check how yours are configured. A setting someone remembers choosing years ago may no longer describe what’s in place.
Keep the approval process short enough for staff to use. Ask the requester what they need the app for, have a reviewer check the publisher and permissions, and record an owner before approving it. Agree how quickly requests will get a response so people aren’t left chasing for an answer.
For a temporary tool, set a review date when you approve it. Check the list again when a contract ends, a team changes tools or an app asks for more access. Include connected apps in your regular security review alongside sign-in protections such as MFA and passkeys. That gives you a chance to catch the old meeting tool before everyone forgets it’s there.