Third-Party Enterprise Applications
© 2026 Sonrai Security. All rights reserved.
Overview
A third-party enterprise application is a service principal in your Microsoft Azure tenant that belongs to someone else — a vendor, a partner, or a contractor. When you consent to one of these applications, it gains the ability to request tokens against your tenant, and with them it can hold Azure role-based access control (RBAC) role assignments, admin-consented Microsoft Graph permissions, or both.
Cloud Permissions Firewall (CPF) inventories every one of these applications, shows you exactly how far each one reaches into your environment, and lets you shut one off without removing its role assignments or consent.
This page covers Azure only. Third-party access into AWS accounts works differently — it is governed through Resource Control Policies (RCPs) rather than by disabling an application. See Hero Card: Third Parties With Access for the AWS equivalent.
To work with third-party enterprise applications, your tenant must already be onboarded. See the Azure Configuration Guide to onboard your tenant first.
The Enterprise Applications Table
The Third-Party Enterprise Applications page lists the third-party service principals consented in your tenant. Beneath the table, a count tells you how many applications are shown out of the total, followed by the exclusion note:
Microsoft first-party apps and registrations owned by your own tenant are excluded.
Both exclusions are deliberate. Microsoft's own applications are not third parties, and an application registered in your own tenant is yours to manage directly — neither belongs in a list of outside parties with reach into your environment.
Columns
| Column | What it shows |
|---|---|
| Enterprise Application | The application's display name. A Verified marker beside the name means Microsoft has verified this publisher. |
| RBAC Assignments | How many Azure RBAC role assignments the application holds across your tenant. |
| Last Used | When the application last signed in. See Last Used below. |
| Labels | What kind of reach the application has. See Labels below. |
| Status | Whether the application can currently request tokens. See Status below. |
| Action | The control for blocking or granting the application. |
Labels
Labels summarise an application's reach at a glance, ordered by how loudly they should be read:
| Label | What it means |
|---|---|
| ADMIN | The application holds Owner, Contributor, or User Access Administrator. This is the one to look at first — these roles can change your environment, not just read it. |
| PRIVILEGED | The application holds some other Azure RBAC assignment, or admin-consented application permissions in Microsoft Graph. |
| SSO | The application is federating users into your tenant, rather than only reaching into Azure resources. |
Labels are supplied by CPF rather than calculated in the table, and this column is not limited to the three above — identity labels such as AI-AGENT can appear alongside them.
Status
| Status | Meaning |
|---|---|
| Granted | The application can sign in and request tokens. |
| Blocked | CPF has disabled the application. Its role assignments and consent are preserved. |
| Disabled in Azure | The application is disabled in Azure by something other than Sonrai, so it cannot be granted access from here. |
| Unknown | The access state of this application is not available. |
| Pending | A block or grant is staged, and applied when you deploy your pending changes. |
Last Used
Two values in this column look similar and mean quite different things:
- Never — no sign-in on record for this application.
- No data — no sign-in activity covering this application, so CPF cannot say whether it has been used.
No data is an absence of evidence, not evidence of absence. Do not read it as an idle application.
Searching and exporting
Search filters the table by application name. When nothing matches, the table reports No enterprise applications match that search. When the tenant has no third-party applications at all, it reports No third-party enterprise applications have been consented in this tenant. If the list cannot be retrieved, CPF reports Could not load enterprise applications for this tenant. Please try again.
Export produces the visible table as azure-enterprise-applications, with three columns that are not shown on screen: Publisher, Publisher Verified, and Change Pending.
Application Details
Select an application to open the Third Party Details panel.
The panel header links out to Open in Azure portal so you can inspect the application directly in Azure. Beneath it, CPF reports the application's identity:
| Field | What it shows |
|---|---|
| Publisher verified / Not verified | Whether Microsoft has verified the application's publisher. |
| Owner in your tenant | Who owns the application on your side. Reads None assigned when nobody does, and marks an owner who is not a member of your tenant as an external guest. |
| First seen in your tenant | When CPF first observed the application. |
| Last used | When the application last signed in. |
The panel also states the application's access in plain language, matching its status:
- Sign-in is enabled. The application can request tokens.
- Sign-in is disabled. Role assignments and consent are preserved.
- Sign-in is disabled in Azure by something other than Sonrai, so it cannot be granted access from here.
- The access state of this application is not available.
Access
The Access section shows everything the application can reach, as a tree of Scope and Role pairs running from the tenant root down to individual resources.
Microsoft Entra ID sits at the root of the tree and carries the application's Graph permissions, classified as:
- Application — app-only permissions, which the application uses on its own behalf without a signed-in user. These are what make an application PRIVILEGED.
- Delegated — permissions the application uses on behalf of a signed-in user.
- Sign-in — the application's ability to sign users in.
- Permission — a consented permission that does not fall into the categories above.
Below the root, each tier of your Azure hierarchy that carries an RBAC assignment appears with the role attached. Tiers that exist only as a path to something deeper show None rather than a role. The tree closes with a count of the Azure RBAC assignments across the scopes above it, and for an application with no RBAC at all, reports No Azure RBAC assignments — access is limited to Microsoft Entra ID.
For an application with a large number of assignments, the tree shows a subset and tells you how many of the total you are seeing.
Blocking and Granting Access
Blocking a third-party enterprise application disables its service principal. The application stops receiving tokens, and everything else about it stays exactly where it was — its RBAC role assignments and its consented Graph permissions are preserved, untouched. Granting access re-enables the service principal and the application resumes working.
This is the whole point of the design: blocking is a switch, not a teardown. The vendor's configuration stays intact, so you do not have to rebuild anything to let them back in.
An Azure service principal has a single enabled state for the entire tenant. An application cannot be blocked in one subscription and left running in another, and there is no scope selection on either action. Blocking stops the application everywhere it is used.
Block an application
- Find the application in the table.
- Select in the Action column.
- CPF asks Block Access? and confirms what will happen: Block [application] across this tenant? Sign-in is disabled everywhere it is used, and role assignments and consent are preserved. The change is staged until you deploy your pending changes.
- Confirm. The application's status becomes Pending.
Grant an application
- Find the blocked application in the table.
- Select in the Action column.
- CPF asks Grant Access? and confirms: Grant [application] access across this tenant? The change is staged until you deploy your pending changes.
- Confirm. The application's status becomes Pending.
Changes are staged, not immediate
Neither action takes effect when you confirm it. Both are staged alongside your other controls and applied when you deploy. After confirming a block, CPF tells you the change is staged, that role assignments and consent are preserved, and that you need to deploy your pending changes to apply it.
Until you deploy, the application keeps working and its status reads Pending. See Intro: Pending Changes for how to review and deploy staged changes.
Authorizing the change at deploy
Disabling a service principal is a write into your Microsoft Entra directory, and CPF does not hold standing permission to make it. Instead, you authorize each deploy yourself, as the administrator performing it.
When you submit pending changes and the set includes a third-party change, CPF sends you to Microsoft to sign in and authorize the write. Microsoft returns you to CPF, and the deploy runs using that authorization. Nothing is retained afterwards — the authorization covers that single deploy and is never stored.
This is a deliberate trade. Granting CPF a standing permission to disable applications would mean it could disable any application in your directory at any time, with no person involved. Authorizing per deploy keeps that authority with you.
Because you are authorizing the write personally, Microsoft requires you to be able to manage enterprise applications in your own Entra directory — Cloud Application Administrator or higher.
This is independent of your CPF permissions, and your CPF role does not substitute for it. If you lack the directory role, Microsoft refuses the authorization, nothing is deployed, and your staged changes are left exactly as they were.
The first administrator in a tenant to deploy one of these changes sees a Microsoft consent screen, and can either consent for themselves or consent on behalf of the organization. Consenting for the organization stops later administrators being prompted — it does not remove the role requirement, which Microsoft enforces on every deploy.
Because you authorize each change personally, it is attributable to you. The change appears under your name in your own Entra audit logs, not as an opaque action by a third-party service.
An application showing Disabled in Azure was switched off by something other than Sonrai. CPF cannot grant it access, because it did not block it — restore it in Azure instead.
Applications Managed by Sonrai
Sonrai's own enterprise application appears in the list like any other third party, marked Managed by Sonrai with a padlock. Its Action column is empty — there is no control to select.
This is intentional. Blocking the application CPF uses to read your tenant would cut off the service that is showing you the list, and the block could not be undone from the product. The application stays visible so you can audit its reach exactly as you would any vendor's, but it is never actionable.