Owners
Menu path: Observe → Application Governance → Owners
URL: /en/insights/dashboard/appGov/app-owners
Purpose
The Application & Service Principal Owners page identifies who owns - or more accurately, who has been designated as an "Owner" of - each application registration and service principal in your Entra ID tenants. Application ownership is a critical governance concept: an owner is responsible for the application's security posture, credential rotation, permission review, and eventual decommissioning.
This page surfaces the good (applications with clear, appropriate ownership), the bad (applications owned by other applications rather than human users - a pattern that can create circular ownership dependencies), and the ugly (applications where a user owner carries critical-level permissions - creating a situation where a single compromised user account could be used to manage a high-risk application).
The page has filters for Application type, Data Source, Owner Type, Parent Resource Type, and Service Principal type.
Observation Cards
Who Owns Your Service Principals?
Chart type: add example --> Donut chart
What it shows: The distribution of service principal owners by type: Service Principal (one app owns another) vs User (a human user is an owner).
In the example: 5 total service principal owners - a mix of Service Principal and User types.
Why it matters: Service principals owning other service principals creates management complexity and potential security risks. If Application A owns Application B, and Application A is compromised, the attacker gains management control over Application B as well. The preferred pattern for production applications is either: no owner (for Microsoft-managed applications), or individual named user owners with appropriate job roles.
Who Owns Your Application Registrations?
Chart type: add example --> Donut chart
What it shows: The distribution of application registration owners by type: Service Principal vs User.
In the example: 9 total application owners - again a mix of Service Principal and User types.
Why it matters: Application registrations that are owned by service principals (rather than humans) have no human accountability. If the application needs to be decommissioned, updated, or investigated, there is no named person responsible. Organisations should ensure every application registration has at least one human user as an owner.
User-Owned Apps by Highest Risk
Chart type: add example --> Donut chart
What it shows: Applications that have at least one user owner, grouped by the highest risk level of the permissions held by that application: Low, High, Critical.
In the example: 6 total applications with user owners, distributed across Low, High, and Critical risk levels.
Why it matters: This is the key risk metric for ownership governance. An application with Critical-risk permissions (e.g., the ability to read/write all users, manage app role assignments) owned by a user means that if that user account is compromised, an attacker could potentially use the application ownership to modify the application's permissions or redirect its credentials. The "Critical" segment of this chart represents the highest-priority ownership governance issue.
What to investigate: Click on the Critical and High segments to see the specific applications and their owners. Assess whether:
- Are the owners appropriate (senior engineers, application owners with genuine need)?
- Are the owner accounts adequately protected (MFA, Privileged Identity Management, Conditional Access)?
- Should some of these applications use a service account or managed identity instead of a user owner?
The Owners Table
The table lists all owner relationships with:
- Application - The application being owned (link to application details)
- Owner - The name of the owner (a user or a service principal)
- Object Type - ServicePrincipal or Application (the type of the resource being owned)
- Owner Type - servicePrincipal or user (the type of the owner)
- Owner UPN - The user principal name of the owner (for user owners)
- App Risk Level - The overall risk level of the application (Low, High, Critical)
- Last Client Sign-In - When the application last authenticated
Key patterns to look for in the table
Critical-risk applications owned by users: From the example data, several Apporetum production applications (apporetum-prod-iwcum4x, Apporetum-prod-nmdakbh, etc.) are owned by named users including system admin accounts. These are critical-risk applications that need careful ownership governance.
Application-owned applications: The Apporetum marketplace applications own each other (e.g., Apporetum Marketplace Deployer owns Apporetum-prod-ftp22pi). This circular service principal ownership pattern means that if the marketplace deployer application credentials are compromised, an attacker gains control of the production applications it owns.
No UPN shown for service principal owners: When the Owner Type is "servicePrincipal", the Owner UPN column shows "-" because service principals don't have UPNs. This is a governance gap - there is no human email address to contact for ownership queries.
Recommendations for ownership governance
- Every application should have a named human owner who is accountable for its governance
- Critical and High risk applications should have more than one owner to prevent single points of failure
- Owner accounts should be protected with MFA and strong Conditional Access policies
- Service principal ownership should be avoided for governance-critical applications
- Review ownership annually - users leave organisations, change roles, and ownership becomes stale