Consent Debt: The Microsoft 365 App Register UK SMEs Rarely Keep

Most Microsoft 365 estates do not have a third-party app problem in the obvious sense. There is no rogue server in the comms room and no unfamiliar box on the network rack. The risk sits in the admin centre: a list of applications that someone, at some point, allowed to read mail, open files, or touch calendar data. The approval may have taken ten seconds. The permission can last for years.

This is consent debt. It accumulates quietly because OAuth is designed to make integration easy. A user clicks Accept, the application receives a token, and the business gains a useful connection to a scheduling tool, a CRM, a document-signing service, or a reporting add-on. Nothing appears broken. That is precisely why the register is rarely written down.

For UK SMEs, the governance question is not whether third-party apps should exist. They should, where they support a clear outcome. The question is whether the business can name each integration, explain its purpose, identify its owner, and justify the data it can reach.

OAuth consent is a business decision, not a click

Microsoft 365 permissions are not the same as a password. A password can be reset. A consent grant creates an ongoing trust relationship between an application and the tenant. Depending on the permission model, the app may act as the signed-in user or, in the case of application permissions, as itself across the organisation.

Delegated permissions are often requested for profile access, mail read, calendar access, or file access. Application permissions can be broader and are usually granted by an administrator. The presence of offline_access matters too: it allows refresh tokens to persist, so an integration can continue working long after the person who approved it has changed role or left.

That is why a simple list of installed software is insufficient. The register must record the consent, not just the vendor.

Start with a register, not a cleanup

A cleanup exercise that begins with deletion is difficult to defend. A register gives the business evidence before it makes changes. In the Microsoft Entra admin centre, review enterprise applications and their consented permissions. Check app registrations for internally built tools. Review user consent settings and any admin consent requests. Sign-in logs can show which applications are actually being used, while audit logs help trace consent events.

A workable register has columns for the application name, vendor, business purpose, owner, permission scope, consent type, first seen date, last reviewed date, last sign-in, data classification, and decision. The last two columns are the ones that turn a technical inventory into governance.

Keep the register in the same place as other IT assets, not in a personal spreadsheet. If it cannot be reviewed by finance, operations, and the IT lead together, it will not survive a busy quarter.

Rank access by consequence

Not every app deserves the same scrutiny. A meeting-room booking tool that reads basic profile data is not equivalent to an application that can read all mailboxes or write to every SharePoint site. A simple tiering model keeps the conversation proportionate.

• Low: basic profile or directory read access with no persistent offline access.
• Moderate: read access to mail, calendar, files, or Teams content for named users.
• High: write access to mail, files, or sites, or access to sensitive business data.
• Critical: tenant-wide application permissions, full mailbox or file access, or the ability to grant further consent.

Ranking by consequence makes the approval route easier to design. It also gives the board a language for risk that does not depend on technical jargon.

Make the approval route boring

A controlled approval route should be unremarkable. Staff submit a request with the business outcome, the data involved, the named owner, and the expected review date. The data owner confirms that the access is proportionate. IT checks the permission scope and confirms whether admin consent is required. The request is approved, approved with reduced scope, or declined.

Microsoft 365 supports admin consent workflows and user consent settings. For many SMEs, restricting user consent to verified publishers or selected permissions is sensible. The aim is not to block useful tools. It is to ensure that the first click is not the only decision.

Record the approval in the register. Add a review date. If the app requests additional permissions later, treat that as a new decision rather than an extension of the old one.

Remove what no longer earns its place

Removal should be based on evidence. An application with no owner, no documented outcome, no sign-in for ninety days, or permissions broader than its purpose is a candidate for retirement. Revoke the consent, remove the service principal where appropriate, and notify the owner. For custom applications, check dependencies before deleting anything that might be part of a business process.

UK GDPR adds a practical reason for this discipline. If an integration processes personal data, the business should be able to explain the lawful basis, the data categories, and the retention position. The ICO does not expect every SME to produce a perfect data map, but it does expect accountability. A consent register is a useful part of that evidence.

Put the register on a rhythm

Review the register quarterly and after any major project closure. Add third-party app review to procurement, new-starter, and leaver processes. When a project ends, ask which integrations were created and who now owns them. When a supplier changes, check whether its app still needs access.

Report three numbers to the leadership team: total integrations, high or critical permissions, and overdue reviews. That is enough to show whether consent debt is being managed or merely counted.

For ResultIT readers, the outcome is not a perfectly clean tenant. It is a tenant where every integration has a reason, an owner, and a review date. That is a more durable result than a one-off cleanup.